[Xapian-discuss] xapian + plpgsql crash? have backtrace...

[Olly Betts]

On Fri, Oct 29, 2004 at 03:17:34PM -0700, Eric Parusel wrote:
> Thanks for the instructions -- done, I've attached two files.

Looks like the list ate the message (probably over the size limit) but
I got the Cc:-ed copy.

> The query I used ('testa') return 0 "hits" (intended)
> First debug log is for the query that worked
> Second debug log is for the same query run right after, which crashes 
> the pgsql child process.
> 
> Hopefully this makes things a little more clear.. :s

Well, I think we can see what's happening, but I'm not quite sure why.

--- xapian-plperl-debug-1worked.log	Sat Oct 30 04:21:33 2004
+++ xapian-plperl-debug-2crashed.log	Sat Oct 30 04:21:31 2004
@@ -1,6 +1 @@
-{0}Xapian debug build initialised
-{7}Xapian 36476: [0x2871e67c] void Xapian::Query::Query() called
-{7}Xapian 36476: [0x2871e67c] void Xapian::Query::Query() returning 
-{7}Xapian 36476: [0x82896cc] void Xapian::Query::Query() called
-{7}Xapian 36476: [0x82896cc] void Xapian::Query::Query() returning 
 {7}Xapian 36476: [0x845c5f0] void Database::Database() called

Here the library debug logger is only initialised once, and 2 Query
objects are only constructed the first time.

The address of the first is at a very different address to most of the
objects, so I suspect it's the static Query object in QueryParser.  

I think the second is a Query which is a member of a static U object
in QueryParser.

Neither object is destroyed during either run so that's not the problem.

@@ -106,3 +101,3 @@
 {2}Xapian 36476: [0x8357018] void Btree::block_to_cursor(0x83570a0, 2, 1010) called
-{2}Xapian 36476: [0x8357018] void Btree::read_block(1010, ) called
+{2}Xapian 36476: [0x8357018] void Btree::read_block(1010, E) called
 {2}Xapian 36476: [0x8357018] void Btree::read_block() returning 

An irrelevant difference - the second parameter to read_block is the
address of the buffer to read the data into, so its contents on entry is
irrelevant (and shouldn't really be logged - I'll fix that).

@@ -132,4 +127,4 @@
 {7}Xapian 36476: [0x845c600] void Xapian::Stem::Stem() returning 
-{7}Xapian 36476: [0x845c6b0] void Xapian::Query::Query() called
-{7}Xapian 36476: [0x845c6b0] void Xapian::Query::Query() returning 
+{7}Xapian 36476: [0x845c6f0] void Xapian::Query::Query() called
+{7}Xapian 36476: [0x845c6f0] void Xapian::Query::Query() returning 
 {7}Xapian 36476: [0xbfbfc4b4] void Xapian::Query::Query() called

Looks like new returned a different address here for the second run.
Odd, but not actually a problem.  A quick grep for that address
suggest that the first block is allocated to an RSet object after
it stops being a Query object.

@@ -552,901 +547,3 @@
 {7}Xapian 36476: [0x82896cc] Xapian::Query & Xapian::Query::operator=() returning Xapian::Query(testa:(pos=1))
-{7}Xapian 36476: [0xbfbfb3c4] void Xapian::Query::~Query() called
-{7}Xapian 36476: [0xbfbfb3c4] void Xapian::Query::~Query() returning 
-{11}Xapian 36476: [0x82896cc] std::string Xapian::Query::get_description() called
[snip]
+{7}Xapian 36476: [0x0] void Xapian::Query::~Query() called
+{7}Xapian 36476: [0x0] void Xapian::Query::~Query() returning 

And here we destroy a Query object the first time, but the second time
the Query object is at address 0.  But if you grep for 0xbfbfb3c4 in the
logs it is allocated both times.

I'm a bit puzzled as to why though!

Is Xapian being used in a threaded way here?  QueryParser currently uses
a few global static objects (because it uses Bison) which means it's
currently not safely reentrant.

I plan to fix that, but it's probably rather involved and may even
require dropping Bison (but I hope we can solve it by moving to use
Bison's C++ skeleton).

QueryParser does play with Query objects a lot, so it's a plausible
explanation.  If that's the issue, a quick fix would be to add a mutex
to the XS wrapper for QueryParser and use it to marshal access.

If not, I'd suggest trying Search::Xapian 0.8.3.0 which Alex uploaded
a day or two ago (thanks Alex!)  It mostly adds wrappers for a load
of methods we weren't wrapping, but I fixed some miswrapped methods
too so it's conceivable it might help...

Cheers,
    Olly