[Xapian-discuss] Omega cgi question

[Olly Betts]

Replacing the expanded template mess with "STRING" makes the backtrace a
lot clearer:

On Wed, Sep 01, 2004 at 04:38:38PM -0400, Jim Lynch wrote:
> [4] Process 1659257 (omega.cgi) stopped at 
> STRING::_M_append_dispatch(const char*,const char*,__false_type):608 
> +0x4,0x1001391c]
> [4] Process 1659257 (omega.cgi) stopped at 
> STRING::append(const char*,const char*):565 +0x4,0x100138bc]
> [4] Process 1659257 (omega.cgi) stopped at [std::operator+(const 
> STRING &,const STRING &):1800 ,0x1000f580]
> [4] Process 1659257 (omega.cgi) stopped at 
> [STRING::append(const char*,const char*):436 ,0x10013884]
> [4] Process 1659257 (omega.cgi) stopped at 
> [STRING::append(const char*,const char*):564 ,0x1001388c]
> [4] Process 1659257 (omega.cgi) stopped at 
> [STRING::_M_append_dispatch(const char*,const char*,__false_type):607 
> ,0x100138e4]
> [4] Process 1659257 (omega.cgi) stopped at 
> [STRING::_M_append_dispatch(const char*,const char*,__false_type):608 
> +0x4,0x1001391c]
> [4] Process 1659257 (omega.cgi) stopped at 
> [STRING::append(const char*,const char*):565 +0x4,0x100138bc]
> [4] Process 1659257 (omega.cgi) stopped at [std::operator+(const 
> STRING &,const STRING &):1801 ,0x1000f598]
> More (n if no)?
> [4] Process 1659257 (omega.cgi) stopped at [::map_dbname_to_dir(const 
> STRING &):84 ,0x1000ca64]
> Caught unknown exception
> Process 1659257 (omega.cgi) terminated
> 
> 
> Also I trapped a couple of variables:
> 
> [4] Process 1660636 (omega.cgi) stopped at [::main:155 ,0x1000d094]
> 155  db.add_database(Xapian::Auto::open(map_dbname_to_dir(dbname)));

So it seems to not like trying to append dbname onto a temporary
currently holding a copy of database_dir.

It's possible (though seems unlikely) this could be an "out of memory"
condition.  Heap corruption is possible too I guess, but I tried running
examples like yours on Linux with valgrind and no bad accesses are
reported.  But perhaps the trampling stays within heap blocks on Linux
for some reason.  In either case, I'd probably expect to see heap
functions in the backtrace though.

> (dbx) s
> Process 1660636 (omega.cgi) stopped at [::map_dbname_to_dir(const 
> STRING &):83 ,0x1000ca40]
>  83  return database_dir + dbname;
> (dbx) p database_dir
> class 
> basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_c<char,char_traits__pt__2_c<char>,allocator__pt__2_c<char>> 
> {
>    _M_start = 0x10051238 = "/oasis/db//"
>    _M_finish = 0x10051243 = ""
>    _M_end_of_storage = 0x1005124d = ""
> }

That's OK - the temporary holds "/oasis/db//", and 0x43-0x38 is 11,
which is the correct length.

> (dbx) p *dbname
> class 
> basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_c<char,char_traits__pt__2_c<char>,allocator__pt__2_c<char>> 
> {
>    _M_start = 0x100503b8 = "default"
>    _M_finish = 0x100503bf = ""
>    _M_end_of_storage = 0x100503c0 = "query"
> }

Also looks OK - 0xbf-0xb8 = 7, the length of "default".

_M_end_of_storage presumably points to the end of the memory allocated
to this string, so the fact that memory contains "query" is irrelevant.

It's odd that dbname appears to be a pointer to string here ("p *dbname"
compared to "p database_dir"), but perhaps that's just how dbx handles
C++ references.

> Here's the code:
> 
>  78  bool collapse = false;
>    79 
>    80  static string
>    81  map_dbname_to_dir(const string &dbname)
>    82  {
> *  83      return database_dir + dbname;
>    84  }
> 
> Something doesn't look right to me, but I'm not a C++ expert.

I can't see anything wrong.

> I find this kind of interesting too:
> 
> [3] Process 1661228 (omega.cgi) stopped at [::main:155 ,0x1000d094]
> 155  db.add_database(Xapian::Auto::open(map_dbname_to_dir(dbname)));
> (dbx) p dbname
> class 
> basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_c<char,char_traits__pt__2_c<char>,allocator__pt__2_c<char>> 
> {
>    _M_start = 0x100503b8 = "default"
>    _M_finish = 0x100503bf = ""
>    _M_end_of_storage = 0x100503c0 = "query"
> }
> (That is before I step into the map_dbname_to_dir method)

This seems to be the same as above, which is what I'd expect as dbname
is passed by reference.

I'm not sure what to suggest really.  Perhaps the compiler doesn't like
the code.  If I knew why I could probably tweak the code to avoid the
problem.  I guess you could try storing the result of
map_dbname_to_dir() in an explicit temporary (but if the compiler really
isn't coping with that I'm suprised the library works at all!)

That is, in omega.cc you could change:

    db.add_database(Xapian::Auto::open(map_dbname_to_dir(dbname)));

to be:

    string xyz(map_dbname_to_dir(dbname));
    db.add_database(Xapian::Auto::open(xyz));

Cheers,
    Olly