Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#209 closed defect (released)

Assertion failure in MultiAndPostlist

Reported by: Richard Boulton Owned by: Olly Betts
Priority: normal Milestone:
Component: Matcher Version: SVN trunk
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Operating System: All

Description

I'm getting an assertion failure in MultiAndPostlist, for a search with an ELITESET group filtered with an OR group.

My search is: Xapian::Query(((XAsecond ELITE_SET 10 XBin ELITE_SET 10 XBheaven ELITE_SET 10 XBcreated ELITE_SET 10 XBbeginning ELITE_SET 10 XBthe ELITE_SET 10 XBgod ELITE_SET 10 XBearth ELITE_SET 10 XBand ELITE_SET 10 XAour) FILTER (XBgod:(pos=1) OR ZXBmove:(pos=2) OR ZXBtext:(pos=3))))

And the error is: AssertionError: matcher/multiandpostlist.cc:143: plist[0]->get_termfreq_est() <= plist[1]->get_termfreq_est()

This is with my xappy python interface: to reproduce, compile a version of xapian with assertions enabled, install the python bindings, check out xappy, then run (from the xappy/trunk directory): python testsuite/runtests.py

This will produce several other test failures due to the matchspy stuff being missing from SVN HEAD, but the one I'm interested in is:


File "/data/home/richard/private/Working/xappy/trunk/docs/introduction.rst", line 546, in introduction.rst Failed example:

results = conn.search(combined, 0, 10)

Exception raised:

Traceback (most recent call last):

File "doctest.py", line 1248, in run

compileflags, 1) in test.globs

File "<doctest introduction.rst[82]>", line 1, in ?

results = conn.search(combined, 0, 10)

File "xappy/searchconnection.py", line 1317, in search

None, matchspy)

AssertionError: matcher/multiandpostlist.cc:143:

plist[0]->get_termfreq_est() <= plist[1]->get_termfreq_est()


I'm not sure whether the assertion is bogus, or whether there's actually a problem here.

Change History (5)

comment:1 by Olly Betts, 17 years ago

Owner: changed from New Bugs to Olly Betts

I'm pretty confident the assertion is incorrect - the value returned by get_termfreq_est() will change if the OR tree prunes, so while this may be true to start with, it won't necessarily remain so during the match.

Luckily this won't affect most users as assertions are off by default.

comment:2 by Olly Betts, 17 years ago

Blocking: 200 added
Status: newassigned

Marking for 1.0.5

comment:3 by Olly Betts, 17 years ago

Resolution: fixed
Status: assignedclosed

The assertion is bogus because get_termfreq_est() can decrease for an OrPostList, for example if one of its sublists ends. I've removed it from SVN HEAD.

comment:4 by Olly Betts, 17 years ago

Resolution: fixedreleased

comment:5 by Olly Betts, 17 years ago

Blocking: 200 removed
Operating System: All
Note: See TracTickets for help on using tickets.