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.
Lee.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
