Regression test for thread safety?

[dank@kegel.com]

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
> <target-triple>/libstdc++-v3/include/<target-triple>/bits/atomicity.h)?

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) (
>     __n=672177968)
>     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 ()
   from /opt/hardhat/devkit/ppc/405/target/lib/libpthread.so.0
(gdb) bt
#0  0x0fe00440 in pthread_mutex_lock ()
   from /opt/hardhat/devkit/ppc/405/target/lib/libpthread.so.0
#1  0x100016dc in __gthread_mutex_lock(pthread_mutex_t*) (mutex=0x1001373c)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/powerpc-linux/bits/gthr-default.h:485
#2  0x10002248 in std::_STL_mutex_lock::_M_acquire_lock() (this=0x100016dc)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_threads.h:376
#3  0x10002184 in std::__default_alloc_template<true, 0>::_Lock::_Lock() (
    this=0x1)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_alloc.h:316
#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)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_alloc.h:184
#6  0x100025d0 in std::_List_alloc_base<int, std::allocator<int>, true>::_M_get_node() (this=0xfddfb8c)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_list.h:182
#7  0x10002518 in std::_List_base<int, std::allocator<int> >::_List_base(std::allocator<int> const&) (this=0x10013988, __a=@0x100016dc)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_list.h:201
#8  0x100024a0 in std::list<int, std::allocator<int> >::list(std::allocator<int> const&) (this=0x100016dc, __a=@0x0)
    at /opt/hardhat/devkit/ppc/405/include/g++-v3/bits/stl_list.h:286
#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 ()
   from /opt/hardhat/devkit/ppc/405/target/lib/libc.so.6

> 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
> order.
> 
> 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.

Thanks,
Dan