[omniORB] Anybody seen a crash cleaning up thread specific storage like this?

[Harri Pasanen]

Have you tried running with valgrind?  It can usually detect 
this type of things early on.

-Harri

On Wednesday 04 January 2006 19:09, Jonathan Biggar wrote:
> Here's the gdb output from an application running OO 4.0.5
> on Linux with a 2.6 kernel:
>
> #0  0x002557a2 in _dl_sysinfo_int80 () from
> /lib/ld-linux.so.2 #1  0x002967d5 in raise () from
> /lib/tls/libc.so.6 #2  0x00298149 in abort () from
> /lib/tls/libc.so.6 #3  0x002ca27a in __libc_message () from
> /lib/tls/libc.so.6 #4  0x002d0abf in _int_free () from
> /lib/tls/libc.so.6 #5  0x002d0e3a in free () from
> /lib/tls/libc.so.6
> #6  0x00263a5d in ___tls_get_addr_internal () from
> /lib/ld-linux.so.2 #7  0x0036bf7b in __libc_dl_error_tsd ()
> from /lib/tls/libc.so.6 #8  0x00261045 in _dl_catch_error
> () from /lib/ld-linux.so.2 #9  0x0036bbce in __libc_dlsym
> () from /lib/tls/libc.so.6 #10 0x004242f0 in
> _Unwind_ForcedUnwind () from /lib/tls/libpthread.so.0 #11
> 0x00421f81 in __pthread_unwind () from
> /lib/tls/libpthread.so.0 #12 0x0041df00 in pthread_exit ()
> from /lib/tls/libpthread.so.0 #13 0x082ef62b in
> omni_thread::exit ()
> #14 0x082eed86 in omni_thread_wrapper ()
> #15 0x0041d341 in start_thread () from
> /lib/tls/libpthread.so.0 #16 0x00335fee in clone () from
> /lib/tls/libc.so.6
>
> The application crashed with this message:
>
>   *** glibc detected *** free(): invalid pointer:
> 0xb7f3db88
>
> I saw this crash once or twice when running my application
> under VMWare, but I finally saw it yesterday without
> virtualization.  I think it's happening when the
> application is trying to exit, but it's hard to capture
> much detail at that point.


Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Trema does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Trema does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of Trema are neither given nor endorsed by the company or its directors. A list of Trema's directors is available on our web site: www.trema.com