This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

std::string MT issue



I have been debugging a crashing multithreaded application for weeks
now, and I feel I can safely say that this snippet of code in
std::string is causing the crashes.

I'm using a RedHat 6.0 linux distrubtion with the following relevant
package versions:

gcc-2.95-4
libstdc++-2.9.0-24
binutils-2.9.5.0.31-1

I'm compiling and running on a dual pentium-II 450 machine (smp) using
the following flags:

-DGCC -D__USE_MALLOC -DLinux -DOS_VERSION=2.2.12-20smp -Di686 -fPIC -g
-O2 -D_REENTRANT

Here's the snippet of code:

...
#if defined __i486__ || defined __i586__ || defined __i686__
    void release ()
      {
    size_t __val;
    // This opcode exists as a .byte instead of as a mnemonic for the
    // benefit of SCO OpenServer 5.  The system assembler (which is
    // essentially required on this target) can't assemble xaddl in
    //COFF mode.
    asm (".byte 0xf0, 0x0f, 0xc1, 0x02" // lock; xaddl %eax, (%edx)
        : "=a" (__val)
        : "0" (-1), "m" (ref), "d" (&ref)
        : "memory");

    if (__val == 1)
-->   delete this;
     }
#else
...

When my code crashes, "info thread" shows:

(lots of threads suspended)
...
* 13 Thread 597  0x40f2bf73 in __libc_free (mem=0x808d5cc) at
malloc.c:3012
  12 Thread 596  0x40f2bf73 in __libc_free (mem=0x808d5cc) at
malloc.c:3012
...
(more suspended threads)

And "where" shows:

#0  0x40f2bf73 in __libc_free (mem=0x808d5cc) at malloc.c:3012
#1  0x807e637 in basic_string<char, string_char_traits<char>,
__malloc_alloc_template<0> >::replace ()


From what I can tell using gdb, etc. it appears that the attempt at
making the 'reference count check' an atomic operation doesn't work on a
multiprocessor machine.

At this point, I'm quite ready to hear that I should give up and stop
trying to use string in a multithreaded application.  The solution to
this problem is not trivial, and I seriously doubt you will give me an
encouraging response about it being high priority or anything like
that.  I would, however, like to hear it, one way or the other.

Thanks!

    -David Gould
    Physitron, Inc.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]