Bug 18649 - terminate called after throwing - IOT/Abort trap (core dumped)
Summary: terminate called after throwing - IOT/Abort trap (core dumped)
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-24 15:48 UTC by Allen Skees
Modified: 2015-02-10 17:20 UTC (History)
3 users (show)

See Also:
Host:
Target: powerpc-ibm-aix5.1.0.0
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-11 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allen Skees 2004-11-24 15:48:41 UTC
The threaded program used in this ticket crashes intermittently.  The error is 
sometimes "terminate called after throwing" and something "unwind called 
recursively".  A sample stack trace is shown below.

#0  0x00000000 in ?? ()
#1  0xd254ece4 in __gxx_exception_cleanup (code=539406920, exc=0x2026b228)
    at /home/downloads/gcc/gcc-3.4.2/libstdc++-v3/libsupc++/eh_throw.cc:52
#2  0xd26bdab0 in _Unwind_DeleteException (exc=0x2026b228)
    at /home/downloads/gcc/gcc-3.4.2/gcc/unwind.inc:277
#3  0xd2548530 in __cxa_end_catch ()
    at /home/downloads/gcc/gcc-3.4.2/libstdc++-v3/libsupc++/eh_catch.cc:119
#4  0x1000049c in thread_handler ()
#5  0xd004a410 in _pthread_body () from /usr/lib/libpthreads.a(shr_xpg5.o)
#6  0x00000000 in ?? ()
#7  0x00000000 in ?? ()
Previous frame identical to this frame (corrupt stack?)


To reproduce the bug, copy this program to "main.cpp" and compile it with "g++ -
pthread main.cpp".  Then, run the program with "while ./a.out do sleep 1; 
done".  After a minute or so, the program will die.  (It doesn't die every 
time, so that is why you need to run it in the loop.)

======================================================================
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/timeb.h>

#define NUM_THREADS 200
#define NUM_LOOPS 1000

pthread_mutexattr_t cs_attr;
pthread_mutex_t cs;
int cnt;

void*
thread_handler(void* idptr)
{
  printf("thread_handler (start)\n");

  for (int i=0; i<NUM_LOOPS; ++i)
  {
    try
    {
      throw "nothing";
    }
    catch(...)
    {
      //pthread_mutex_lock(&cs);

      time_t now = time(0);
      struct tm now_tm;
      localtime_r(&now, &now_tm);

      //pthread_mutex_unlock(&cs);
    }
  }

  pthread_mutex_lock(&cs);
  ++cnt;
  pthread_mutex_unlock(&cs);

  printf("thread_handler (stop)\n");
  return NULL;
}

int
main(int argc, char** argv)
{
  pthread_mutexattr_settype(&cs_attr, PTHREAD_MUTEX_RECURSIVE);
  pthread_mutex_init(&cs, &cs_attr);

  cnt = 0;

  for (int i=0; i<NUM_THREADS; ++i)
  {
    pthread_attr_t attr;

    int err = pthread_attr_init(&attr);
    if (err != 0)
    {
      printf("Could not initialize thread [errno=%d]\n", err);
      return 1;
    }

    err = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    if (err != 0)
    {
      printf("Could not set detachable thread [errno=%d]\n", err);
      return 1;
    }

    pthread_t thread;
    err = pthread_create(&thread, &attr, thread_handler, (void*)NULL);
    if (err != 0) 
    {
      printf("Could not create thread [errno=%d]\n", err);
      return 1;
    }
  }

  bool stop = false;
  while(!stop)
  {
    sleep(1);

    pthread_mutex_lock(&cs);
    stop = (cnt == NUM_THREADS);
    printf("*** cnt = %d\n", cnt);
    pthread_mutex_unlock(&cs);
  }

  return 0;
}
======================================================================



gcc was configured as follows.

configure --enable-threads=posix --prefix=/usr/local/gcc/gcc-3.x.x --enable-lang
uages=c,c++ --disable-multilib
Comment 1 Andrew Pinski 2004-11-24 18:41:56 UTC
This is already fixed in 3.4.3 and it is a dup of bug 13391.

*** This bug has been marked as a duplicate of 13391 ***
Comment 2 Allen Skees 2004-11-24 21:29:36 UTC
I downloaded 3.4.3 and the bug still exists.  So, it is not a duplicate of 
13391.  
Comment 3 Colm McHugh 2005-04-08 20:18:05 UTC
I downloaded and built 3.4.3 on AIX 5.2, and this bug does still exist; I tried
the following program (scarfed from 13391) and it crashes every time. Is there
any resolution/fix ? 


bluetrance:13391$ more a2.cpp
void mycall()
{
        throw 0;
}
bluetrance:13391$ more a1.cpp
                                                                                 
extern void mycall();
 
int main()
{
        try {
                mycall();
        } catch (int i) {
                return i;
        }
        return 1;
}
 
 
bluetrance:13391$ g++ -fPIC -DPIC -shared -o liba2.a a2.cpp
bluetrance:13391$ g++ -fPIC -DPIC -o a1 a1.cpp -L. -la2
bluetrance:13391$ a1
terminate called after throwing an instance of 'i'
IOT/Abort trap (core dumped)

bluetrance:build$ g++ --v
Reading specs from /usr/local/bin/../lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/specs
Configured with: /export/xtegra3/gcc-3.4.3/gcc-3.4.3/configure
--enable-languages=c,c++ --enable-threads=aix --disable-nls
--prefix=/export/xtegra3/gcc-3.4.3/installdir
Thread model: aix
gcc version 3.4.3
Comment 4 Colm McHugh 2005-04-13 00:41:27 UTC
If I compile and link the example in my last comment (shown below) with
-pthread, it will always run. If I don't it will always core dump. This is with
g++ 3.4.3 on AIX 5.2. Does anyone know if the same program compiled with g++
3.3.3 will behave the same way on AIX 5.2 ? (i.e. run okay when compiled and
linked with -pthread but abort otherwise ?)

bluetrance:13391$ cat a2.cpp
void mycall()
{
        throw 0;
}
bluetrance:13391$ cat a1.cpp
                                                                                 
extern void mycall();
 
int main()
{
        try {
                mycall();
        } catch (int i) {
                return i;
        }
        return 1;
}
 
 
bluetrance:13391$ g++ -fPIC -DPIC -shared -pthread -o liba2.a a2.cpp
bluetrance:13391$ g++ -fPIC -DPIC -o a1 a1.cpp -pthread -L. -la2
Comment 5 Kean Johnston 2005-08-11 09:18:43 UTC
On UnixWare I have a very similar failure. It seems to be -fPIC that's wreaking
the havoc. I have an almost identical test case, and it aborts with:
terminate called after throwing an instance of 'int'
terminate called recursively

This only happens when compiling a2.cpp with -fPIC and producing a .so. If you
link the two together, it works fine. This was with 3.4.4.
Comment 6 bucreev_1 2011-11-05 09:21:35 UTC
This example (Allen Skees 2004-11-24 15:48:41 UTC) also does not work correctly when using gcc version 4.5.2.

D:\MinGW\bin>gcc -v
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc.EXE
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
Comment 7 Richard Biener 2012-01-11 12:43:52 UTC
Still an issue?
Comment 8 bucreev_1 2012-01-11 15:26:45 UTC
There are no questions. Just to inform you that in version of gcc 4.5.2. this example does not work.
Comment 9 Kai Tietz 2013-09-11 09:30:58 UTC
(In reply to Richard Biener from comment #7)
> Still an issue?

gcc 4.8 and upward still have this issue.
Comment 10 Kai Tietz 2013-12-07 11:06:45 UTC
For mingw-code this bug is fixed.  It was caused by a bug in SjLj catch-reason.  Issue is fixed for 32-bit and 64-bit mingw targets for all open branches.
As report was for different targets, it would be good if PPC maintainer could verify that this issue is fixed for this target, too.
Comment 11 Kai Tietz 2015-02-10 17:20:26 UTC
So waited long enough for a reply of PPC maintainer.  I assume it is fixed too.