Bug 98390 - AIX: exceptions in threads: IOT/Abort trap(coredump)
Summary: AIX: exceptions in threads: IOT/Abort trap(coredump)
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-19 10:11 UTC by Stefan Krah
Modified: 2024-03-13 05:08 UTC (History)
4 users (show)

See Also:
Host:
Target: powerpc-aix
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Krah 2020-12-19 10:11:32 UTC
The following test case is extracted from a larger program. When repeated
often enough, it terminates with: IOT/Abort trap(coredump)

Confirmed with g++ (GCC) 7.2.0 and g++ (GCC) 10.2.0 on gcc119.fsffrance.org.


test.cc:
========================================================================
#include <stdexcept>
#include <thread>
#include <vector>


class suntime_error : public std::runtime_error {
  using std::runtime_error::runtime_error;
};

static void
doit()
{
    try {
        throw suntime_error("this is an error");
    }
    catch (const suntime_error& err) {
        (void)err;
    }
}

static void
do_threads()
{
    const size_t n = 100;
    std::vector<std::thread> t(n);

    for (size_t k = 0; k < n; k++) {
        t[k] = std::thread(doit);
    }

    for (size_t k = 0; k < n; k++) {
        t[k].join();
    }
}

int
main()
{
    do_threads();
    return 0;
}
========================================================================


doit.sh:
========================================================================
#!/bin/sh

while ./test; do
    :
done
========================================================================



$ g++ -pthread -Wall -Wextra -std=gnu++11 -pedantic -O0 -g -o test test.cc

$ ./doit.sh
./doit.sh[3]: 14484092 IOT/Abort trap(coredump)

$ gdb ./test core
[...]
Program terminated with signal SIGABRT, Aborted.
#0  0xd058f3ec in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
(gdb) bt
#0  0xd058f3ec in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
#1  0xd058e7cc in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2  0xd0123608 in raise () from /usr/lib/libc.a(shr.o)
#3  0xd0189ebc in abort () from /usr/lib/libc.a(shr.o)
#4  0xd08741a4 in uw_init_context_1 () from /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libgcc_s.a(shr.o)
#5  0xd0874e50 in _Unwind_RaiseException () from /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libgcc_s.a(shr.o)
#6  0xd17cd2cc in __cxa_throw () from /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libstdc++.a(libstdc++.so.6)
#7  0x100006dc in doit () at test.cc:14
#8  0x100021fc in void std::__invoke_impl<void, void (*)()>(std::__invoke_other, void (*&&)()) (__f=<incomplete type>)
#9  0x100020c4 in std::__invoke_result<void (*)()>::type std::__invoke<void (*)()>(void (*&&)()) (__fn=<incomplete type>)
#10 0x10002cd4 in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=<incomplete type>)
#11 0x10002c2c in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=<incomplete type>)
#12 0x10002b8c in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=<incomplete type>)
#13 0xd18964d8 in execute_native_thread_routine () from /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libstdc++.a(libstdc++.so.6)
#14 0xd0572f68 in _pthread_body () from /usr/lib/libpthreads.a(shr_xpg5.o)
#15 0x00000000 in ?? ()
Comment 1 Stefan Krah 2024-01-02 15:24:28 UTC
The issue can still be reproduced with a gcc-14 snapshot. ibm-clang++ does not have this problem. The LLVM unwinder has been reworked for AIX:

https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg275024.html


Would it be possible for gcc to use the LLVM libunwind on AIX? It would be great if IBM unlocked some funding for this.

gcc often produces faster binaries than clang and this is literally the only gcc issue on AIX that I've come across after many long running tests. It would be worth fixing --- both AIX and gcc (except for this issue) are very stable.