[Xapian-discuss] Xapian core dumping on Solaris

[Tom]

On 1 February 2010 10:09, Richard Boulton <richard at tartarus.org> wrote:
> On 1 February 2010 10:06, Tom <banoffi at gmail.com> wrote:
>> The latter. The error message is caught and logged before the process dies.
>
> No (assuming you mean the Xapian Database).  You can't have any Xapian
> objects accessed concurrently, including the Database objects (or any
> objects derived from them, like iterator objects, since those will
> access the Database internally).

OK, I've fixed that - there are no shared Xapian objects at all. But
it's just crashed again, with a different backtrace:

#0  0xfe1196d0 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from
/usr/sfw/lib/libstdc++.so.6
#1  0xfe22e9a4 in Internal (this=0x3a1680, copyme=@0x7b4e00)
    at api/omqueryinternal.cc:654
#2  0xfe22e9f4 in Internal (this=0x5788ac, copyme=@0x7b0cc8)
    at /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/stl_iterator.h:614
#3  0xfe34b180 in LocalSubMatch (this=0x5788a0, db_=0x795f10, query=0x7b0cc8,
    qlen_=4, omrset=@0x56e4c0, wt_factory_=0x7e3608)
    at matcher/localmatch.cc:49
#4  0xfe360424 in MultiMatch (this=0xfdaf8770, db_=@0x57df5c,
    query_=0x7b0cc8, qlen=4, omrset=0x0, collapse_max_=0,
    collapse_key_=4256138712, percent_cutoff_=5694656, weight_cutoff_=0,
    order_=Xapian::Enquire::ASCENDING, sort_key_=1,
    sort_by_=Xapian::Enquire::Internal::REL, sort_value_forward_=true,
    sorter_=0x0, errorhandler_=0x0, stats=@0xfdaf8808, weight_=0xffffff00,
    matchspies_=@0xffffff00)
    at /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:462
#5  0xfe21c0e0 in Xapian::Enquire::Internal::get_mset (this=0x57df58,
    first=0, maxitems=21, check_at_least=1000, rset=0x0, mdecider=0x0,
    matchspy_legacy=0x0) at include/xapian/base.h:166
#6  0xfe21c850 in Xapian::Enquire::get_mset (this=0x7abcd0, first=0,
    maxitems=21, check_at_least=1000, rset=0x0, mdecider=0x0, matchspy=0x0)
    at include/xapian/base.h:154
#7  0xfe5793b4 in _wrap_Enquire_get_mset (self=0x0, args=0x15)
    at modern/xapian_wrap.cc:22630
#8  0x00117290 in PyCFunction_Call (func=0x60c7b0, arg=0x6bad80, kw=0x0)
    at Objects/methodobject.c:116
...

I guess that lets zlib off the hook anyway. =/

Tom