On Feb 25, 4:07 am, Paul Pluzhnikov <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED])
at inc/otlv4.h:6971
#12 0x083ae1fb in otl_inout_stream::operator<< (this=0x8655e48,
[EMAIL PROTECTED]) at inc/otlv4.h:23323
#13 0x083ad587 in otl_stream::operator<< (this=0x8632da4,
[EMAIL PROTECTED]) at inc/otlv4.h:27252
#14 0x0814dccd in CPODBA::FieldValToSQLStream (this=0x8632cb8,
[EMAIL PROTECTED], aEnumField=3)
at src/PODBA.cpp:76
#15 0x081481ab in CPODB::ToSQLStream (this=0x8632cbc,
[EMAIL PROTECTED]) at src/PODB.cpp:375
#16 0x083b90f1 in CPODBA::ToSQLStream (this=0x8632cb8,
[EMAIL PROTECTED])
at inc/PODBA.h:92
#17 0x083adf7a in operator<< ([EMAIL PROTECTED],
[EMAIL PROTECTED]) 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,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at src/IM.cpp:1642
#23 0x080801f4 in SoapServer::NS__Import (soap=0x85e5690,
import=0x85cda50, [EMAIL PROTECTED]) 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
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
