Regression test for thread safety?
Tue Jul 16 11:01:00 GMT 2002
Loren James Rittle wrote:
> requirements (see http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_6).
> Can you confirm that your application code matches those expectations?
I believe it does. It's a big app, written by a large group of
people, though, so someone might have slipped up. In particular,
there may be multiple threads *reading* shared objects without locking-
I wasn't aware there was a restriction on that. (Is there really?)
> Can you confirm that a non-generic implementation of atomicity.h is
> installed for the target platform (in the build tree, look at
Yes, it's non-generic.
> Under the assumption that there is something wrong with this particular
> configuration, you could try the following steps:
> (1) Using the version of GCC you have built (I assume that the library
> itself was built without defining __USE_MALLOC and that you have
> not manually touched c++config, etc), run:
> $ g++ -g -pthread pthread1.cc
> (2) Using any gdb that works with this GCC output executable, run:
> $ gdb -nw a.out
> (3) Within gdb:
> (gdb) break pthread_mutex_lock
> (gdb) run
> ``bt'' then ``continue'' repeatedly until you see a backtrace
> similar to this (the exact names of library routines might have
> changed a bit; the key is to see a hit for line pthread1.cc:118):
> #0 0x281448e1 in pthread_mutex_lock () from /usr/lib/libc_r.so.4
> #1 0x280ac0c6 in std::__default_alloc_template<true, 0>::allocate(unsigned) (
> at /usr/users/rittle/tmp/gcc-build-latour-3.1-0516/i386-unknown-freebsd4.6/libstdc++-v3/include/i386-unknown-freebsd4.6/bits/gthr-default.h:484
> #2 0x080494c1 in std::__simple_alloc<std::_List_node<int>, std::__default_alloc_template<true, 0> >::allocate(unsigned) (__n=1)
> at /usr/local/include/g++-v3/bits/stl_alloc.h:224
> #3 0x08049456 in std::_List_alloc_base<int, std::allocator<int>, true>::_M_get_node() (this=0x8087030) at /usr/local/include/g++-v3/bits/stl_list.h:238
> #4 0x080494fc in _List_base (this=0x8087030, __a=@0xbfbfe7f0)
> at /usr/local/include/g++-v3/bits/stl_list.h:262
> #5 0x08049480 in list (this=0x8087030, __a=@0xbfbfe7f0)
> at /usr/local/include/g++-v3/bits/stl_list.h:361
> #6 0x0804935d in task_queue (this=0x8087030) at pthread1.cc:49
> #7 0x08048d4d in main (argc=1, argv=0xbfbfe934) at pthread1.cc:118
> #8 0x08048abf in _start (arguments=0xbfbfeabc "/tmp/a.out")
> at /usr/users/rittle/outside-cvs-src/freebsd-src/lib/csu/i386-elf/crt1.c:96
> If you never see that backtrace, then something is completely forked
> in your POSIX thread environment.
I do see it, so looks like I'm ok there:
Breakpoint 2, 0x0fe00440 in pthread_mutex_lock ()
#0 0x0fe00440 in pthread_mutex_lock ()
#1 0x100016dc in __gthread_mutex_lock(pthread_mutex_t*) (mutex=0x1001373c)
#2 0x10002248 in std::_STL_mutex_lock::_M_acquire_lock() (this=0x100016dc)
#3 0x10002184 in std::__default_alloc_template<true, 0>::_Lock::_Lock() (
#4 0x10002778 in std::__default_alloc_template<true, 0>::allocate(unsigned) (
__n=12) at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_alloc.h:338
#5 0x100026e0 in std::simple_alloc<std::_List_node<int>, std::__default_alloc_template<true, 0> >::allocate(unsigned) (__n=1)
#6 0x100025d0 in std::_List_alloc_base<int, std::allocator<int>, true>::_M_get_node() (this=0xfddfb8c)
#7 0x10002518 in std::_List_base<int, std::allocator<int> >::_List_base(std::allocator<int> const&) (this=0x10013988, __a=@0x100016dc)
#8 0x100024a0 in std::list<int, std::allocator<int> >::list(std::allocator<int> const&) (this=0x100016dc, __a=@0x0)
#9 0x10002364 in task_queue::task_queue() (this=0x10013988) at pthread1.cc:49
#10 0x10001524 in main (argc=1, argv=0x7ffffeb4) at pthread1.cc:118
#11 0x0fccddbc in __libc_start_main ()
> If you see that backtrace, then you adapt these steps to look at your
> built application.
OK. I'll try that next.
> BTW, if any application or library code was compiled with __USE_MALLOC
> defined, then it all must be or you might corrupt the malloc() heap.
> Since defining __USE_MALLOC verses not defining it created no ABI or
> naming change, it was impossible to detect this failure at application
> link-time. Some malloc() implementations will catch this with a
> controlled abort() or similar; some will not.
Good to know. We had guessed this.
> After discounting application code mismatch with library requirements
> (yes, this would require an audit of all your application code) and
> the above gdb exercise, testing later releases of GCC would be in
> It would be *very* helpful to the GCC project if you could report
> whether GCC 3.1 fixes your problem. If it fails there, then also
> testing and reporting against GCC mainline would be the biggest help.
I'll reply again if I learn anything.
More information about the Libstdc++