Hi all,

I've tried building RPMs for RHEL5 and hit this problem in Search::Xapian:

make test fails on test 37:

ok 34 - check PositionIterator
ok 35 - create TermIterator
ok 36 - check TermIterator
dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 37-65
Failed 29/65 tests, 55.38% okay

$ xapian-config --version
xapian-config - xapian-core 1.0.4

$ cat /etc/redhat-release
Red Hat Enterprise Linux Client release 5 (Tikanga)

$ perl -v

This is perl, v5.8.8 built for i386-linux-thread-multi


Fails at the same point every time.

All the best,
Tim.

Search Discussions

  • Olly Betts at Nov 8, 2007 at 1:52 pm

    On Thu, Nov 08, 2007 at 01:21:19PM +0000, Tim Brody wrote:
    ok 34 - check PositionIterator
    ok 35 - create TermIterator
    ok 36 - check TermIterator
    dubious
    Test returned status 0 (wstat 11, 0xb)
    Assuming that's a signal number, it died with a segmentation fault.
    DIED. FAILED tests 37-65
    Failed 29/65 tests, 55.38% okay
    The next test is trying to create a valueiterator from a document, which
    was tested in 1.0.3.0 by document.t so it's not just that the wrapper
    there is wrong (and the XS code and typemap look OK anyway).

    The test script hasn't actually created any threads at that point, so I
    wonder if this is unrelated to threads.

    If you just comment out "use threads;" and the block of 4 lines lower
    down where the threads are created and joined, does it still fail?

    Do you get any problems reported if you run the test under valgrind?

    Or perhaps run under gdb to get a backtrace from where the seg fault
    happens.

    Cheers,
    Olly
  • Tim Brody at Nov 8, 2007 at 3:03 pm

    Olly Betts wrote:
    On Thu, Nov 08, 2007 at 01:21:19PM +0000, Tim Brody wrote:

    ok 34 - check PositionIterator
    ok 35 - create TermIterator
    ok 36 - check TermIterator
    dubious
    Test returned status 0 (wstat 11, 0xb)
    Assuming that's a signal number, it died with a segmentation fault.

    DIED. FAILED tests 37-65
    Failed 29/65 tests, 55.38% okay
    The next test is trying to create a valueiterator from a document, which
    was tested in 1.0.3.0 by document.t so it's not just that the wrapper
    there is wrong (and the XS code and typemap look OK anyway).

    The test script hasn't actually created any threads at that point, so I
    wonder if this is unrelated to threads.

    If you just comment out "use threads;" and the block of 4 lines lower
    down where the threads are created and joined, does it still fail?
    Correct, without 'use threads' it still fails. Here's a minimal test:
    ok( $db = Search::Xapian::Database->new('testdb'), 'create Database' );
    is( $db->get_doccount(), 2, 'check Database' );

    ok( $doc = $db->get_document(1), 'create Document' );
    is( $doc->get_data(), 'test one', 'check Document' );

    ok( $valueit = $doc->values_begin(), 'create ValueIterator' ); # dies
    is( $valueit->get_valueno(), 0, 'check ValueIterator' );
    Do you get any problems reported if you run the test under valgrind?

    Or perhaps run under gdb to get a backtrace from where the seg fault
    happens.
    I've never used gdb/valgrind properly ... so let me know if there's
    something else to ask them:

    $ gdb --args /usr/bin/perl t/thread.t

    ok 34 - check PositionIterator
    ok 35 - create TermIterator
    ok 36 - check TermIterator

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1208514880 (LWP 4054)]
    0x005354f4 in Xapian::ValueIterator::operator* (this=0x8a448e8)
    at api/omvalueiterator.cc:45
    45 }

    (gdb) backtrace
    #0 0x004514f4 in Xapian::ValueIterator::operator* (this=0x93aa8e8)
    at api/omvalueiterator.cc:45
    #1 0x00ee7f69 in XS_Search__Xapian__ValueIterator_get_value (
    my_perl=0x91da008, cv=0x936b190) at XS/ValueIterator.xs:47
    #2 0x0036a47d in Perl_pp_entersub ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #3 0x003638df in Perl_runops_standard ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #4 0x0030afc8 in Perl_amagic_call ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #5 0x0036e22b in Perl_sv_2bool ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #6 0x00365cd8 in Perl_pp_cond_expr ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #7 0x003638df in Perl_runops_standard ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #8 0x003090de in perl_run ()
    from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
    #9 0x080491ee in main ()

    $ valgrind /usr/bin/perl t/thread.t

    ok 34 - check PositionIterator
    ok 35 - create TermIterator
    ok 36 - check TermIterator
    =@73== Invalid read of size 4
    =@73== at 0x47D24F4: Xapian::ValueIterator::operator*() const
    (omvalueiterator.cc:45)
    =@73== by 0x4762F68:
    XS_Search__Xapian__ValueIterator_get_value(interpreter*, cv*)
    (ValueIterator.xs:47)
    =@73== by 0x36A47C: Perl_pp_entersub (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3638DE: Perl_runops_standard (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x30AFC7: Perl_amagic_call (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x36E22A: Perl_sv_2bool (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x365CD7: Perl_pp_cond_expr (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3638DE: Perl_runops_standard (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3090DD: perl_run (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x80491ED: main (in /usr/bin/perl)
    =@73== Address 0x0 is not stack'd, malloc'd or (recently) free'd
    =@73==@73== Process terminating with default action of signal 11 (SIGSEGV)
    =@73== Access not within mapped region at address 0x0
    =@73== at 0x47D24F4: Xapian::ValueIterator::operator*() const
    (omvalueiterator.cc:45)
    =@73== by 0x4762F68:
    XS_Search__Xapian__ValueIterator_get_value(interpreter*, cv*)
    (ValueIterator.xs:47)
    =@73== by 0x36A47C: Perl_pp_entersub (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3638DE: Perl_runops_standard (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x30AFC7: Perl_amagic_call (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x36E22A: Perl_sv_2bool (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x365CD7: Perl_pp_cond_expr (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3638DE: Perl_runops_standard (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x3090DD: perl_run (in
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so)
    =@73== by 0x80491ED: main (in /usr/bin/perl)
  • Olly Betts at Nov 8, 2007 at 3:23 pm

    On Thu, Nov 08, 2007 at 03:03:30PM +0000, Tim Brody wrote:
    I've never used gdb/valgrind properly ... so let me know if there's
    something else to ask them:
    You did well then!
    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1208514880 (LWP 4054)]
    0x005354f4 in Xapian::ValueIterator::operator* (this=0x8a448e8)
    at api/omvalueiterator.cc:45
    45 }

    (gdb) backtrace
    #0 0x004514f4 in Xapian::ValueIterator::operator* (this=0x93aa8e8)
    at api/omvalueiterator.cc:45
    #1 0x00ee7f69 in XS_Search__Xapian__ValueIterator_get_value (
    my_perl=0x91da008, cv=0x936b190) at XS/ValueIterator.xs:47
    Oh right, I realise what's going on here. I actually stumbled across
    this issue while writing the test, but I didn't think things through
    enough. Sorry for being dense.

    When a document is read from a database, we don't actually read the
    value, terms, or document data until they are first asked for or
    modified.

    There's a bug in Xapian 1.0.4 and earlier where values_begin() doesn't
    ensure that the values have been read. However both values_end() and
    values_count() do, so in real world code this is really unlikely to
    be an issue (and indeed nobody reported it despite it being like that
    for years).

    I spotted this when the new test failed for me, but xapian-core 1.0.4
    was already released when I was preparing the Search::Xapian release
    so the fix to xapian-core isn't in the release and this test is still
    failing.

    Either just ignore the test failure, or if you want the tests to pass
    patch it by removing the "ok()" from around the first $valueit line and
    decrement the number of tests after "plan tests" near the start of the
    file.

    Cheers,
    Olly
  • Damyan Ivanov at Nov 14, 2007 at 2:23 pm

    Olly Betts writes:
    There's a bug in Xapian 1.0.4 and earlier where values_begin() doesn't
    ensure that the values have been read. However both values_end() and
    values_count() do, so in real world code this is really unlikely to
    be an issue (and indeed nobody reported it despite it being like that
    for years).

    [snip]

    Either just ignore the test failure, or if you want the tests to pass
    patch it by removing the "ok()" from around the first $valueit line and
    decrement the number of tests after "plan tests" near the start of the
    file.
    Simply removing "ok()" did not work for me.
    From your description above, I decided to add a "$doc->values_count()" call
    before values_begin test to force reading of the values.

    I hope this is OK.

    Thanks,
    dam
  • Olly Betts at Nov 15, 2007 at 10:26 am

    On Wed, Nov 14, 2007 at 02:23:04PM +0000, Damyan Ivanov wrote:
    From your description above, I decided to add a "$doc->values_count()" call
    before values_begin test to force reading of the values.

    I hope this is OK.
    Yes, that's a better approach anyway.

    Cheers,
    Olly

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupxapian-discuss @
categoriesxapian
postedNov 8, '07 at 1:21p
activeNov 15, '07 at 10:26a
posts6
users3
websitexapian.org
irc#xapian

People

Translate

site design / logo © 2021 Grokbase