Opened 14 years ago

Closed 14 years ago

#476 closed defect (fixed)

OR decaying to AND_MAYBE sometimes skips a document

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

Description

When an OR postlist decays to an AND_MAYBE postlist in the next() method of the OR postlist, the next document which should be returned by the AND_MAYBE postlist sometimes isn't returned.

Consider the OR postlist with lhead=22, rhead=23 when it decays, such that the left subtree of the OR becomes the right subtree of the AND_MAYBE.

The code implementing this in OrPostList::next() is:

ret = new AndMaybePostList(r, l, matcher, dbsize, rhead, lhead);
next_handling_prune(ret, w_min, matcher);

The OR was at document 22, so the next document returned should have been 23. However, the AndMaybePostList is created pointing at document 23, so the call to next_handling_prune() moves past this document.

To fix this, I think we need to check whether rhead <= lhead before advancing. If rhead > lhead, we shouldn't call the "next_handling_prune()" method, but we do need to call check() on the LHS postlist of the OR to move it to match the position of the RHS.

I've seen this error happening in my "soaktest" testscript, but have no short testcase for it. I suspect this problem occurs in other places in the matcher, too.

Attachments (1)

andmaybe_skip_doc.patch (4.2 KB ) - added by Richard Boulton 14 years ago.
Patch containing potential fix

Download all attachments as: .zip

Change History (9)

comment:1 by Olly Betts, 14 years ago

Status: newassigned

I'll take a look.

by Richard Boulton, 14 years ago

Attachment: andmaybe_skip_doc.patch added

Patch containing potential fix

comment:2 by Richard Boulton, 14 years ago

I have attached a patch which seems to fix the problem with the examples I'm seeing from soaktest. I still don't have a short testcase for it, though.

comment:3 by Olly Betts, 14 years ago

Owner: changed from Olly Betts to Richard Boulton
Status: assignednew

The use of the temporary ret2 seems totally unnecessary...

Also, there's a superfluous set of brackets on various condition checks.

Not looked in detail yet, but seems plausible.

Assigning to you, since you seem to be working on it.

comment:4 by Richard Boulton, 14 years ago

The ret2 temporary was to avoid having to cast to the right type when calling the sync_rhs() method. I'll clean up the brackets.

I've got a working testcase now.

comment:5 by Richard Boulton, 14 years ago

Fixed in r14545.

comment:6 by Richard Boulton, 14 years ago

Resolution: fixed
Status: newclosed

comment:7 by Richard Boulton, 14 years ago

Milestone: 1.2.11.0.21
Resolution: fixed
Status: closedreopened

Actually, this wants backporting, so retargetting to 1.0.21, and reopening.

comment:8 by Olly Betts, 14 years ago

Resolution: fixed
Status: reopenedclosed

Backported for 1.0.21 in r14559, plus some related tweaks in other nearby revisions.

Note: See TracTickets for help on using tickets.