[gccsdk] Autobuilding Battle of Wesnoth

Lee Noar leenoar at sky.com
Fri Jul 11 07:21:00 PDT 2008

alan buckley wrote:
>> On Thu, 10 Jul 2008 15:09:28 +0100 Lee Noar wrote:
>> alan buckley wrote:
>>>> On Wed, 9 Jul 2008 20:38:46 +0200 John Tytgat wrote:
>>>> In message
>>>> alan buckley wrote:
>>>>> I've been trying to build the latest Battle of Wesnoth in
>>>>> the autobuilder over the last few months and although
>>>>> it builds, it crashes immediately when run. I don't get
>>>>> enough information for me to track the problem down
>>>>> and it doesn't get as far as the main routine so I can
>>>>> put in trace lines.
>>>> Are you using the shared or static UnixLib ? I expect the static UnixLib
>>>> to work.
>>> I'm using the static UnixLib. The program is normally put through elf2aif,
>>> but I get the same results just running it as an ELF executable.
>>>> It is certainly worthwhile to track down what's going on. You
>>>> have stackdump ?
>>> No I don't get a stackdump. I just get the application failed wimp
>>> error box and details leads to internal error: branch through zero
>>> at &03813584. This was a slightly modified unixlib to try to get
>>> more details. The standard unixlib just gave a signal recursion
>>> message through the wimp with no stack dump.
>>> I'm afraid I can't think of anything else to try. I've tried various
>>> combinations of Reporter, messing about with the boost library
>>> it uses and even profiling to try to get some useful information
>>> and failed.
>>> This could easily be a problem with the code. But I'm not getting
>>> anything to help me track it down and haven't been able to find
>>> anything I can add to help.
>> Does r14 from *showregs not indicate which function attempted to jump to
>> address 0?
> I believe I tried this when you suggested it previously, but can't remember
> how I ran showregs, if I did at all. I assume the where command register
> dump in Reporter is giving the same information.

Yes, it does.

> If not how and when do I run showregs?

As soon as Wesnoth crashes, type *showregs at a command line. It doesn't 
have to be in Wesnoth's application space, although sometimes the 
register store can be reset if too much happens (eg, starting other 
applications) between the crash and *showregs.

> As you mentioned it I'm trying to see where r14 is again to see if I missed
> something last time around.

Hopefully r14 will be a return address in Wesnoth. Load the Wesnoth 
binary into an editor in code mode and find the address, then look back 
through the binary to find the embedded function name of the caller. If 
there are no embedded function names, then you can use nm -n on the 
binary to list all the symbols in address order so you can see which one 
the return address is in.


More information about the gcc mailing list