[Xapian-discuss] Perl make test fails on threads in rhel5

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

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' );
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)

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

before values_begin test to force reading of the values.

I hope this is OK.

Thanks,
dam

Yes, that's a better approach anyway.

Cheers,
Olly