https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71192
Bug ID: 71192
Summary: Coredump - SIGSEGV exception handling on GCC 4.8.2 in
Solaris 11.3, Solaris 11.2 works with same GCC version
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: user1172464 at gmail dot com
Target Milestone: ---
Hi, we are trying to compile an opensource software from source that belongs to
a third party supplier.
While trying to compile the software on a Solaris 11.3 zone and also on a
Solaris 11.2 zone the compilation completes without any issues and the expected
shared object libraries are generated as expected.
When built and run the executable on a Solaris 11.2 environment everything
works as expected.
If we build and run the executable on a Solaris 11.3 environment the executable
(a daemon) during the start, it coredumps.
On both environments we are using the supplied compilation software that comes
with the Solaris release.
The Solaris 11.2 env we used gcc 4.8.2, on the Solaris 11.3 we have used the
same 4.8.2 version and also a in house compiled version of gcc 4.8.5, but
unfortunately the same codedump happens.
Looking into the source code, we can see that the coredump is happening as soon
as an exception (in the C++) code is being raised. Following the code logic and
the execution stack we can found that the exception is expected and is being
handled in a try ...catch section, but as soon the exception is thrown we are
not able to see the code execution to return to the expected catch section and
instead the code just coredumps.
We have tried to add debug symbols (i.e -g -g3 -O0) to the compilation options
and looks the symbols are there.
After running mdb against the core file generated we can see the stack trace
but we are not getting much support from the third-party supplier on resolving
this as they claim the code is working properly on Solaris 11.2.
Below is the calling stack extracted from the core dump file, below the real
name of the .so has been replaced with third-party-lib.so and the c++ namespace
used has been changed to ABCD to avoid the supplier to be identified.
Call stack details:
mdb core
Loading modules: [ libc.so.1 ld.so.1 ]
> $G
C++ symbol demangling enabled
> ::stack
libc.so.1`__lwp_sigqueue+8(6, ffffffff7fffd7b0, 5, 5, 0, 0)
libc.so.1`abort+0x10c(1, ff8, 6, 0, 1bb5b4, c00)
libstdc++.so.6.0.18`__gnu_cxx::__verbose_terminate_handler+0x1bc(100115580, 1,
fffffffbf6280608, 100103ce0, 100114f98, ffffffff3f98bbd0)
libstdc++.so.6.0.18`__cxxabiv1::__terminate+4(fffffffbf62839a0,
fffffffbf63f0938, ff, fffffffbf6280608, ffffffff7fffcff0, ffffffff7fffdb70)
libstdc++.so.6.0.18`std::terminate+0x1c(0, fffffffbe2561538, 0,
ffffffff7fffcc00, ffffffff7fffd3e0, ffffffff7fffcff0)
libstdc++.so.6.0.18`__cxa_throw+0x88(1001155a0, fffffffbe2781930,
fffffffbe240ff20, 0, 23, 100115580)
third-party-lib.so`ABCD::throw_not_found_error+0xdc(fffffffbe1e25868, 0, 2c, 0,
2c, 1001155a0)
third-party-lib.so`ABCD::__ini_lookup+0x5f4(ffffffff7fffe278, ffffffff7fffeae0,
fffffffbe1e22308, ffffffff7fffedd0, 0, 100116ec0)
third-party-lib.so`ABCD::read_profile_entry+0x7dc(ffffffff7fffec58,
fffffffbe1e22108, fffffffbe1e22308, ffffffff7fffedd0,
fffffffbe1e22108, fffffffbe1e22108)
third-party-lib.so`ABCD::read_profile_string+0x74(ffffffff7fffee00,
fffffffbe1e22108, fffffffbe1e22308, ffffffff7fffedd0,
fffffffbe1e22108, 142)
third-party-lib.so`ABCD::ABCD_licence::check2+0x324(100114be0,
ffffffff3f9979c8, 12, 0, 12, 0)
third-party-lib.so`ABCD::ABCD_licence::check+0x34(100114be0, 100114be0,
fffffffbe1e26500, fffffffbe1e279d0, f, fffffffbe278f7c8)
third-party-lib.so`ABCD::ABCD_static::initialize_licence+0xa4(100114710,
fffffffbe1e264f0, ffffffff7ffff05f, ffffffff3f986000, 1a0824,
100114908)
third-party-lib.so`ABCD::ABCD_static::init+0x160(100114710, fffffffbe278e4f8,
fffffffbe1e26448, fffffffbe1e26450, 100114b68,
ffffffffffffffff)
third-party-lib.so`ABCD::ABCD_static_ptr_static+0xf0(0, 2, ffffffff3f98cfc0,
ffffffff7f202a40, 0, 100114710)
third-party-lib.so`ABCD::ABCD_static_ptr+0x2c(0, 0, 0, ffffffff7f7498c0, 3,
ffffffff7f202a40)
third-party-lib.so`ABCD::ABCD_appl::init+8(ffffffff7ffff53f, 0, 100000b9c,
fffffffbe1fa91bc, ffffffff7f744608, 0)
third-party-lib.so`ABCD::ABCD_main0+0x40(a, ffffffff7ffff6d8, ffffffff3f98cfc0,
100000b9c, 0, 100101360)
third-party-lib.so`spooler_program+0x20(a, ffffffff7ffff6d8, ffffffff7ffff730,
1001013a0, 100000000, 2800)
_start+0x7c(0, 0, 0, 0, 0, 0)
Any ideas of what could be causing this issue only happening on Solaris 11.3?
Thanks,
Mike
