[gccsdk] C++ progam recursion of SIGSEGV

alan buckley alan_baa at hotmail.com
Wed Apr 9 04:44:57 PDT 2008


> On Thu, 3 Apr 2008 19:39:50 +0100 Lee Noar wrote:
> alan buckley wrote:
>>> On Wed, 2 Apr 2008 18:42:15 +0100 Lee Noar wrote:
>>>
>>> alan buckley wrote:
>>>> I've cross compiled a large C++ game (the latest version of
>>>> wesnoth) in the autobuilder using the GCC4.1 cross compiler
>>>> on Cygwin and although it builds OK, when I try to run it I get
>>>> a wimp error box with the following:
>>>>
>>>> Unixlib detected recursion of signal SIGSEGV.
>>>>
>>>> My usual debugging technique of putting printf into the
>>>> program is not working as it doesn't even reach the main
>>>> function.
>>>>
>>>> A grep of the src didn't show any signal handlers that
>>>> could be installed at this point.
>>>>
>>>> Could this be a bug in the compiler/unixlib?
>>>>
>>>> Can anyone suggest what I need to do to track the
>>>> error down?
>>>
>>> Global object constructors are called before main(), so this is probably
>>> where the crash is occurring.
>>
>> That was/still is my thought, but I couldn't see how you could get
>> a signal recursion if no signal was being set. (It is possible
>> that I missed something though).
>
> Basically, the order of execution is:
>
> 1) UnixLib initialisation
> 2) Global object constructors called (IIRC, the order the constructors
> are called is the same as the order they appear on the linker's command
> line).
> 3) main() called.

I tried creating dummy global classes in the first and last object files on
the linker command line that just did a printf and I still got nothing in
my redirected output file.

Do you know if global objects in the libraries may be being created first?

>
> Signal handlers for hardware exceptions such as memory violations are
> set up by UnixLib during its initialisation, so global object
> constructors can cause a SIGSEGV.
>
>>> One trick you can try is disabling the
>>> UnixLib signal handlers in syslib.s so that RISC OS gives you the error
>>> directly. !Reporter may be useful here to catch the error for reading.
>>>
>>
[snip technique for disabling handlers]

I tried this and I now get:
Error: 8000005
Message: Internal error: branch through zero at 03813584

(addresses in hex)

Any clues on where I can go from here would be appreciated.

Regards,
Alan


_________________________________________________________________
The next generation of Windows Live is here
http://www.windowslive.co.uk/get-live



More information about the gcc mailing list