[Xapian-tickets] [Xapian] #752: Segmentation fault in matcher/queryoptimiser

[Xapian]

#752: Segmentation fault in matcher/queryoptimiser
---------------------+-------------------------------
 Reporter:  rsto     |             Owner:  olly
     Type:  defect   |            Status:  assigned
 Priority:  normal   |         Milestone:  1.4.5
Component:  Matcher  |           Version:  git master
 Severity:  normal   |        Resolution:
 Keywords:           |        Blocked By:
 Blocking:           |  Operating System:  All
---------------------+-------------------------------

Comment (by olly):

 > I am not deep enough into the query optimiser code to know which
 approach is
 > better in term of performance.

 It's not obvious to me either.

 The saving when the hint is close could be quite substantial, and the
 bookkeeping overhead is probably small, so I'd guess it's better to not
 clear
 the hint, but I don't think I spotted it could just be NULL-ed out in
 these
 cases when I added the code to track ownership.

 I'll try some tests.

 > If taking ownership is preferred I could make
 > the context resetter aware which postlist member to skip during the
 free().

 I'm thinking it would be good for reset() to either clear or hand over
 ownership of the hint, as that avoids a whole slew of potential similar
 issues.  Your case is the second one, so empirically this seems a breeding
 ground for bugs - if we always leave the hint valid by default then we
 only
 need to be careful when removing some entries from Context.pls (and
 perhaps
 we can provide a helper for that too).

 Ideally we should have a regression test for this, but I've been trying to
 create one based on existing testcase `subdbwithoutpos1` in
 `tests/api_query.cc` and I haven't so far managed.

 What does the query which causes the valgrind error look like?  I'm
 interested in the entire Query object tree, not just a query string, in
 case the whole Query object isn't just built by parsing a query string in
 an obvious way.  The exact terms probably don't matter, so feel free to
 genericise anything which might invade end user privacy.

--
Ticket URL: <https://trac.xapian.org/ticket/752#comment:2>
Xapian <https://xapian.org/>
Xapian