I just wanted to post an update in case anyone else runs into this. This issue is related this gcc bug:
It looks like it started in gcc 4.8.0 and that you will probably need to use the workaround listed in the link.
Original Message:
Sent: Thu May 25, 2023 10:44 AM
From: Adam Swartz
Subject: core file with new version of g++
I am trying to reply directly, but my sent messages never show the message as being sent, so trying here as well.
Sangamesh,
I don't know why my replies are not working, but trying again. There is a script included to compile on your machine (compile_test.sh).
Thanks,
Adam
------------------------------
Adam Swartz
Original Message:
Sent: Fri May 19, 2023 01:08 PM
From: SANKET RATHI
Subject: core file with new version of g++
Hi Adam,
I sent you a private message not sure if you receive.
But I could not find the sample code.
Original Message:
Sent: 5/19/2023 10:30:00 AM
From: Adam Swartz
Subject: RE: core file with new version of g++
Sanket, I haven't heard anything more since I posted the sample code. Any updates? Is there a JIRA I can watch or something?
------------------------------
Adam Swartz
Original Message:
Sent: Tue May 09, 2023 10:16 AM
From: Adam Swartz
Subject: core file with new version of g++
Here is the code. I sent the password privately. There is no makefile, but the shell script will build it. Just run the resulting bin/TestCreateByMethodV4 program and you will get the core. TestCreateByMethod.cpp is the entry point and wraps everything in a try catch. I had to have several levels of inheritance with the template to recreate the core.
Thanks!
------------------------------
Adam Swartz
Original Message:
Sent: Mon May 08, 2023 01:29 PM
From: SANKET RATHI
Subject: core file with new version of g++
If you do not want to send on forum then you can send me privately.
Original Message:
Sent: 5/4/2023 3:48:00 PM
From: Adam Swartz
Subject: RE: core file with new version of g++
Sanket,
It has been a long time since the last post, but I was able to confirm this is a bug in the compiler on AIX. Our old compiler (4.2.4) does not cause a core. The same code when compiled on Linux or other platforms does not create a core either. I was able to pare down the code to some sample code that can reproduce the problem. The heart of the problem is that a try/catch block is not being honored. It is like it forgets it is in the try/catch and therefore cores. Where would I send source to so they can work on a fix? I would prefer not to post it on the forum.
$oslevel -s
7200-05-03-2148
$gcc --version
gcc (GCC) 10.3.0
Thanks,
Adam
------------------------------
Adam Swartz
Original Message:
Sent: Tue October 25, 2022 02:32 PM
From: SANKET RATHI
Subject: core file with new version of g++
Hi Adam,
Is there a simple testcase that you can share to reproduce the problem ? We would like to try on our test system.
------------------------------
SANKET RATHI
Original Message:
Sent: Fri October 21, 2022 06:01 PM
From: Adam Swartz
Subject: core file with new version of g++
I stepped through the debugger with the test file and problem file. I found the test file's last line was 371 in char_traits.h:
(gdb) info lineLine 371 of "/opt/freeware/src/packages/BUILD/gcc-build-8.3.0/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/bits/char_traits.h" starts at address 0x12338978 <_ZNSi6ignoreEl+512> and ends at 0x12338988 <_ZNSi6ignoreEl+528>.(gdb) bt#0 0x0900000012338980 in std::istream::ignore (this=0x90, __n=<incomplete type>) at /opt/freeware/src/packages/BUILD/gcc-build-8.3.0/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/bits/char_traits.h:371#1 0x000000010000074c in main (argc=0, argv=0x110001208 <_cce3nhgc.rw_+360>) at test.cpp:10(gdb) siAn exception occurred, processing has terminated abnormally. Specific messages follow:This is a test[Inferior 1 (process 33882590) exited with code 01]
while the coring program's last lines are
(gdb) info lineLine 1334 of "/opt/freeware/src/packages/BUILD/gcc-build-8.3.0/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/bits/char_traits.h" starts at address 0x12338978 <_ZNSi6ignoreEl+512> and ends at 0x12338988 <_ZNSi6ignoreEl+528>.(gdb) bt#0 0x0900000012338980 in std::istream::ignore (this=0x90, __n=<incomplete type>) at /opt/freeware/src/packages/BUILD/gcc-build-8.3.0/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/bits/char_traits.h:1334#1 0x0000000100283834 in (anonymous namespace)::FilterAssertNoMediumOverlays::doThrow (this=0x0, mmName=...) at src/AfpFiltersExternal/FilterAssertNoMediumOverlays.cpp:96#2 0x0000000100283668 in (anonymous namespace)::FilterAssertNoMediumOverlays::write (this=0x0, buf=0x110013298 <_cczixF3b.rw_+43832>, bufSize=1) at src/AfpFiltersExternal/FilterAssertNoMediumOverlays.cpp:84#3 0x000000010005bbc0 in AfpOutputFilter::sink_write (this=<incomplete type>, buf=<incomplete type>, bufSize=173) at src/AfpFiltersInternal/AddSuppressTextToFormdef.cpp:67#4 0x00000001000ead90 in (anonymous namespace)::FilterInputFile::close (this=0x110045470) at src/AfpFiltersExternal/FilterInputFile.cpp:93#5 0x0000000100001380 in main (argc=1, argv=0x0) at src/afpsak.cpp:138(gdb) siterminate called after throwing an instance of 'std::runtime_error' what(): Assertion has failed in filter "assertNoMediumOverlays". The medium map with name "AAAPRIME" defines a medium overlay and is invoked just before page sequence 1.Program received signal SIGABRT, Aborted.0x09000000000416ac in raise () from /usr/lib/libc.a(shr_64.o)
That line number looks out of range since the header is only 708 lines long.
------------------------------
Adam Swartz
Original Message:
Sent: Fri October 21, 2022 02:44 AM
From: SANKET RATHI
Subject: core file with new version of g++
Are both of these files compiled with same compiler and there is no other older library and other compiled unit ?
------------------------------
SANKET RATHI
Original Message:
Sent: Thu October 20, 2022 06:51 PM
From: Adam Swartz
Subject: core file with new version of g++
We moved from gcc 4.8.4 to 8.3.0. When we run some regression testing we get a core file when we try to throw an exception. The code throwing the exception is this:
char s[2048];snprintf(s, 2048, "Assertion has failed ...");throw std::runtime_error(s);
This is caught in main with this:
catch (std::exception &ex) { fprintf(stderr, "An exception occurred, processing has terminated abnormally. Specific messages follow:\n%s\n", ex.what()); exit(EXIT_FAILURE);}
The stack shows this:
$ cat core_stack.txt
raise.raise(??) at 0xd01247c8
abort.abort() at 0xd018a6b8
vterminate.__gnu_cxx::__verbose_terminate_handler()(), line 95 in "vterminate.cc"
eh_terminate.__cxxabiv1::__terminate(void (*)())(handler = ??), line 47 in "eh_terminate.cc"
eh_terminate.std::terminate()(), line 57 in "eh_terminate.cc"
eh_throw.__cxa_throw(obj = @0x200469f8, tinfo = ??, dest = ??), line 95 in "eh_throw.cc"
FilterAssertNoMediumOverlays.(anonymous namespace)::FilterAssertNoMediumOverlays::doThrow(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)(0x20035628, 0x20035680), line 96 in "FilterAssertNoMediumOverlays.cpp"
I tried to pull out the problem code into a file:
#include <string>#include <stdexcept>int main(int argc,char *argv[]){ //Catch unexpected exceptions. try { char s[2048]; snprintf(s, 2048, "This is a test"); throw std::runtime_error(s); } catch (std::exception &ex) { fprintf(stderr, "An exception occurred, processing has terminated abnormally. Specific messages follow:\n%s\n", ex.what()); exit(EXIT_FAILURE); }}
and that runs without error. Could it be because we link in some older code even if it is not used?
Thanks
------------------------------
Adam Swartz
------------------------------