Re: gdb backtrace for g++ programs showing ?? symbol

[naam . yaad . nahin]

On Feb 25, 4:07 am, Paul Pluzhnikov <ppluzhnikov-...@gmail.com> wrote:
> You should at least post the gdb backtrace -- it may not give you any
> clues, but may give someone else a good idea of what you are seeing.

Here is the (big) backtrace (with some names changed):

#0  0x0837e037 in allocator<char>::deallocate (this=0x28780cc,
p=0x83b4704 "\213]üÉÃ\215v")
    at /opt/ospace/2.1.6/LinuxIA32AS2.1/ospace/osstd/allocate.h:214
#1  0x0837d7dc in basic_string<char, char_traits_char, allocator<char>
>::deallocate (this=0x28780c0)
    at /users/libuser/ospace/2.1.6/LinuxIA32AS2.1/ospace/osstd/
allocate.h:214
#2  0x0837ca2a in basic_string<char, char_traits_char, allocator<char>
>::~basic_string (this=0x28780c0, __in_chrg=2)
    at /opt/ospace/2.1.6/LinuxIA32AS2.1/ospace/osstd/basic.h:717
#3  0x083b4c62 in otl_tmpl_select_stream<otl_exc, otl_conn, otl_cur,
otl_var, otl_sel, otl_oracle_date>::rewind (this=0x8607ab8)
    at inc/otlv4.h:5409
#4  0x00156501 in ?? () from /usr/lib/libstdc++-libc6.2-2.so.3
#5  0x00156752 in ?? () from /usr/lib/libstdc++-libc6.2-2.so.3
#6  0x00156c3f in __rethrow () from /usr/lib/libstdc++-libc6.2-2.so.3
#7  0x083b4704 in otl_tmpl_cursor<otl_exc, otl_conn, otl_cur,
otl_var>::exec (this=0x8655e48, iters=1, rowoff=0) at inc/otlv4.h:4153
#8  0x083c2fc7 in otl_tmpl_out_stream<otl_exc, otl_conn, otl_cur,
otl_var, otl_oracle_date>::flush (this=0x8655e48, rowoff=0,
    force_flush=false) at inc/otlv4.h:6719
#9  0x083c2234 in otl_tmpl_inout_stream<otl_exc, otl_conn, otl_cur,
otl_var, otl_oracle_date>::flush (this=0x8655e48, rowoff=0,
    force_flush=false) at inc/otlv4.h:7769
#10 0x083b117a in otl_tmpl_out_stream<otl_exc, otl_conn, otl_cur,
otl_var, otl_oracle_date>::check_buf (this=0x8655e48) at inc/otlv4.h:
6830
#11 0x083b07b9 in otl_tmpl_out_stream<otl_exc, otl_conn, otl_cur,
otl_var, otl_oracle_date>::operator<< (this=0x8655e48, s=@0x287ad20)
    at inc/otlv4.h:6971
#12 0x083ae1fb in otl_inout_stream::operator<< (this=0x8655e48,
s=@0x287ad20) at inc/otlv4.h:23323
#13 0x083ad587 in otl_stream::operator<< (this=0x8632da4,
s=@0x287ad20) at inc/otlv4.h:27252
#14 0x0814dccd in CPODBA::FieldValToSQLStream (this=0x8632cb8,
aOTLStream=@0x8632da4, aEnumField=3)
    at src/PODBA.cpp:76
#15 0x081481ab in CPODB::ToSQLStream (this=0x8632cbc,
aOTLStream=@0x8632da4) at src/PODB.cpp:375
#16 0x083b90f1 in CPODBA::ToSQLStream (this=0x8632cb8,
aOTLStream=@0x8632da4)
    at inc/PODBA.h:92
#17 0x083adf7a in operator<< (aOTLStream=@0x8632da4,
aPersistencyObject=@0x8632e24) at inc/SQLQueryStream.h:64
#18 0x0814a448 in CPODB::AddNewRow (this=0x8632cbc,
IsContainsBLOB=true, Id=-1) at src/PODB.cpp:873
#19 0x08149cae in CPODB::Save (this=0x8632cbc) at src/PODB.cpp:819
#20 0x083b9171 in CPODBA::Save (this=0x8632cb8) at inc/PODBA.h:112
#21 0x0814139b in Transaction::SavePO (this=0x85ca0c8,
thePersistencyObject=0x8632cbc) at src/TO.cpp:83
#22 0x0811b67c in IMImp::ObjectImport (this=0x84afe00, soap=0x85e5690,
import=@0x85cda50, objects=@0x8585e90)
    at src/IM.cpp:1642
#23 0x080801f4 in SoapServer::NS__Import (soap=0x85e5690,
import=0x85cda50, importObjects=@0x287b320) at src/NS.cpp:358
#24 0x080905c6 in SoapServer::soap_serve_NS__Import (soap=0x85e5690)
at src/NSsoapServer.cpp:607
#25 0x0808e3d5 in SoapServer::NSsoap_serve_request (soap=0x85e5690) at
src/NSsoapServer.cpp:64
#26 0x0808e0a3 in SoapServer::NSsoap_serve (soap=0x85e5690) at src/
NSsoapServer.cpp:28
#27 0x083d83ba in Job::run (this=0x85c2540) at src/SoapServer.cpp:51
#28 0x083d81bb in os_runnable<Job>::run (runnable=0x85c2540) at /opt/
ospace/2.1.6/LinuxIA32AS2.1/ospace/thread/runnable.h:31
#29 0x083da86f in os_task::run (this=0x287b3f0) at inc/pooltask.h:40
#30 0x081b9508 in os_thread_pool::run (thread_pool=0xbffff6f4) at src/
thrdpool.cpp:586
#31 0x007698a8 in _internal_thread_wrapper () at inc/IController.h:151
#32 0x00116371 in start_thread () from /lib/tls/libpthread.so.0
#33 0x00253ffe in clone () from /lib/tls/libc.so.6

I am using a library called OTL (database library available at
http://otl.sourceforge.net/) as well as a library called ospace (an
STL replacement). The SIGSEGV happens because the pointer is not
correct at deallocate() in frame #0.

It seems that control should not go there at all. The exception is
thrown at frame #6 and it is an expected exception. The actual
exception handler is in frame #19. However, frames #5 and #4 do not
show the function name and then control goes to a function (frame #3)
where it should not go. I think that ::rewind() (the function in frame
#3) should not even be called.

::rewind() is also not called from any of the destructors in the
objects on the call stack.

So basically my question is why/how does control go to ::rewind() ?

A side note - the same program works on Windows (Microsoft Visual
Studio 6.0). Exception is caught at frame #19 and correct log messages
are written out.

Thanks for all the help.

Cheers,
Naam Nahin