[gambit-list] Medium-to-high-prio, would appreciate a hand resolving this completely reproducible pita bug: SIGSEGV on every ordinary termination (, q (exit) etc.) on Gambit-current on OpenBSD-current w at least g++ 4.7.2 & 4.6.3
mikael.rcv at gmail.com
Sat Jan 12 15:21:14 EST 2013
Now had the occasion to go through if Gambit termination works on
different GCC & G++ versions in OpenBSD 5.2 AMD64 default.
I did not check with the "-latest" aka snapshot OBSD release this time,
that could of course provide additional information, though sponaneously I
would guess that the issue with eg++ (GCC) 4.7.1 in the default release as
described below has the same underlying cause, as the output looks exactly
This test make clear that there is a way to get Gambit going without issues
on OBSD, so,
As far as I'm personally concerned this is a solved issue.
For completeness, here are the results:
Correct behavior of Gambit termination for different GCC & G++ versions on
OBSD 5.2 AMD64 non-snapshot is as follows:
gcc (GCC) 4.2.1 20070719 (this is the bundled version): Worked. (also
./configure --enable-single-host worked)
g++ (GCC) 4.2.1 20070719 (this is the bundled version): Worked.
egcc (GCC) 4.6.3: Worked.
eg++ (GCC) 4.6.3: Worked.
egcc (GCC) 4.7.1: Worked.
eg++ (GCC) 4.7.1: FAIL
For GCC compilation, ./configure --enable-single-host --enable-debug was
For G++ compilation, ./configure --enable-single-host --enable-debug
--enable-cplusplus was used.
For invocation of the non-default version, CC=/usr/local/bin/egcc or
CXX=/usr/local/bin/eg++ respectively was
added as prefix to the ./configure command line, in bash.
make clean was used to reset the GCC directory between compilations. The
g++ 4.6.3 compilation was also double-checked by also compiling from a
fresh Gambit source copy.
Gambit compiled with eg++ (GCC) 4.7.1 produces the following in response to
terminate called after throwing an instance of '___throw_struct'
terminate called recursively
Abort trap (core dumped)
If I recall right, on the snapshot OBSD AMD64 release, this failure
behavior was on both the 4.6 and 4.7 G++, and I did not try the 4.2 release
at all due to ./configure's warning about excessive RAM consumption.
The only hint I picked up as regards the source of this issue, is that it
might have to do with that 4.7.1 perhaps brings an alternative libstdc++
package (libstdc++ 4.7.1 it's called) while perhaps the other ones don't. I
would guess this was not an issue though - it would make no sense for them
to publish a problematic package without making the installer print a
warning or alike. #openbsd seems to have nothing to say on the topic.
If there would be any checks I could do for completeness at some point,
feel free to mention them.
Thanks and with best regards,
2013/1/3 Mikael <mikael.rcv at gmail.com>
> Hi Marc,
> Thank you so much for having a look.
> 2013/1/3 Marc Feeley <feeley at iro.umontreal.ca>
>> I can't reproduce this bug with OpenBSD 5.2 and the g++ 4.2.1 which comes
>> with it. My guess is that the problem is related to a bug in the versions
>> of g++ you have used. Can you install an older g++ and see if that solves
>> the problem? Can you also try to compile using gcc (i.e. don't use
> Aha funny.
> Just for reference, in the test you made, was the OS compiled for the
> AMD64 architecture?
> I did not use 5.2 but "current" a.k.a. "snapshot" for AMD64, as found on
> http://www.mirrorservice.org/pub/OpenBSD/snapshots/amd64/ . Except for
> regarding exiting Gambit, this version of the system has shown to perfectly
> stable in every way I checked, so this is why I was so surprised to see any
> issue about Gambit's execution on it.
> And right, I tried with G++ 4.7.2 and 4.6.3. On your 5.2 installation,
> installing this would look something like:
> pkg_add g++-4.6.3p6
> (or just pkg_add
> rm /usr/bin/g++
> ln -s /usr/local/bin/eg++ /usr/bin/g++
> I believe I did not try 4.2.1 til now because ./configure warned me that
> that GCC version is broken or slow or something.
>> > But if so, why is not an uncaught exception error printed at gsc
>> termination on every platform (which is g++'s default behavior)???
>> No, the runtime system should catch this exception in the ___BEGIN_TRY /
>> ___END_TRY macros which are called in lib/setup.c (in only 2 places, so it
>> should be easy to verify that the exception is actually caught by adding
>> some printfs in the code).
> Right, so that's really funny.
> Quite soon I'll try compiling Gambit on the 5.2 and maybe snapshot
> with different versions of both GCC and G++ including 4.2.1, and report the
> results here.
> Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list