GP2X Dumping Core


try 'ulimit -c unlimited', run your program, and then 'gdb program-name core-filename'.

Although it's probably easier to just 'gdb program-name' and when you get the fpu exception, it'll point out where in the program it was. You can then use 'bt' for a backtrace (assuming you compiled with debug info)
 
Thanks! Okay I'll give that a try.

I tried ulimit initially and it told me that the GP2X was already set to "unlimited".

I'd read that in some casees, the system won't produce a core dump when a floating point exception is generated.
______________

Okay, I've run "ulimit -c unlimited" and produced a core file. Previously to this I'd done a "make clean" to clear out all my *.o and then added "-ggdb" so that "arm-linux-g++" will include debugging info.
Since this is a threaded app, I backed up /lib/libpthread-0.9.so and copied the non-stripped version to this location.
I then ran "gdb prog.gpe core". The resulting backtrace is disappointing:

(gdb) bt
#0 0x0029e020 in ?? ()
Cannot access memory at address 0xff

Am I still doing something wrong? Or is this the limit to gdb's ability?

Here's the full story:

QUOTE
[root@gp2x mamegp2x_3.8]$./gdb --exec=mame_gp2x_test.gpe --core=core.103

warning: Symbol "td_init" not found in libthread_db: ./gdb: undefined symbol: td
_init
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-gp2x-linux".

warning: core file may not match specified executable file.
Core was generated by `./mame_gp2x_test.gpe polepos'.
Program terminated with signal 8, Arithmetic exception.
#0 0x0029e020 in ?? ()
(gdb)
(gdb) bt
#0 0x0029e020 in ?? ()
(gdb)
#0 0x0029e020 in ?? ()
(gdb)


Any further assistance?

EDIT:
Okay found it, I was removing the symbol table using "-s" option when calling g++ :)

EDIT AGAIN:
Still having problems. Even with a symbol table I'm only getting this:

QUOTE
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-gp2x-linux"...Using host libthread_db library "/
lib/libthread_db.so.1".


warning: core file may not match specified executable file.
Core was generated by `./mame_gp2x_test.gpe'.
Program terminated with signal 8, Arithmetic exception.
#0 0x0029e020 in __div0 ()
(gdb)
(gdb) bt all
No symbol "all" in current context.
(gdb)


Still need some help in tracking where this div by 0 is occuring...
 
Why are you doing "bt all"? Simple "bt" doesn't work?
Also check the compile log to see if all files were compiled with -ggdb and without optimization.
 
I've removed -O3 from the compiler flags.

My mistake about "bt all", I wanted to type "bt full".

Recompiled and here is gdb output:

QUOTE
(gdb) bt full
#0 0x0053c140 in __div0 ()
No symbol table info available.
#1 0x0053bf58 in __divsi3 ()
No symbol table info available.
#2 0x0053bf58 in __divsi3 ()
No symbol table info available.
Previous frame identical to this frame (corrupt stack?)
(gdb)


It's still not telling me anything?

I am NOT using "-s", so the symbol table should be intact?

EDIT: The symbol table seems to be there. Running "nm" shows me what seems to be a correct symbol table?

QUOTE
...
...
00701134 d blockade_layout
007022a8 d blockade_machine_driver
00702238 d blockade_rom
00700dfc d blockade_sample_name
00715df0 D blockgal_driver
00716640 d blockgal_rom
008019ac D blockout_driver
...
...
 
slaanesh said:
I've removed -O3 from the compiler flags.

My mistake about "bt all", I wanted to type "bt full".

Recompiled and here is gdb output:

QUOTE
(gdb) bt full
#0 0x0053c140 in __div0 ()
No symbol table info available.
#1 0x0053bf58 in __divsi3 ()
No symbol table info available.
#2 0x0053bf58 in __divsi3 ()
No symbol table info available.
Previous frame identical to this frame (corrupt stack?)
(gdb)
It's still not telling me anything?

I am NOT using "-s", so the symbol table should be intact?

EDIT: The symbol table seems to be there. Running "nm" shows me what seems to be a correct symbol table?

QUOTE
...
...
00701134 d blockade_layout
007022a8 d blockade_machine_driver
00702238 d blockade_rom
00700dfc d blockade_sample_name
00715df0 D blockgal_driver
00716640 d blockgal_rom
008019ac D blockout_driver
...
...



I think you should remove this line in Makefile.gp2x also:
$(STRIP) $(PROG)
 
Last edited by a moderator:
slaanesh said:
Franxis said:
I think you should remove this line in Makefile.gp2x also:
$(STRIP) $(PROG)
Yep, had done that :)


I would remove also the optimization flags, e.g.
-O3 -fxxxx (e.g. -ffast-math -fexpensive-optimizations -fweb -frename-registers -fomit-frame-pointer
-finline -finline-functions -fno-builtin -fno-common)
 
Last edited by a moderator:
UPDATE.
I know this thread is old but it's still useful. In fact I've revisited this thread and found it useful myself. I'd like to add some more information.

To use gdb if your program crashes, I find that the following is the best way to do so.

(1) Compile and link your program correctly

arm-linux-gcc -g -c prog.c -o prog.o

Add -g as this adds the necessary debugging information used by gdb.

And link correctly:

arm-linux-gcc -static prog.o -o prog.gpe

Don't use -s when linking, this removes symbolic links.

(2) Running your program

The following assumes you have telnet access to your GP2X and you are running your program from that.
It also assumes you have installed gdb.

Before you execute your program, run the following command then run your program.
This will allow it to create a core file. Otherwise, no core file is created when it crashes.

ulimit -c unlimited
prog.gpe


Once the prog.gpe crashes, you will see a message indicating "core dumped" and we get a resulting core file. ie. core.123 (where '123' was the PID)

(3) Using gdb

Now, start gdb:

gdb

You'll get the gdb prompt.
Next, load the symbols from the executable:

(gdb) file prog.gpe

then load the core file:

(gdb) core-file core.123

You should then get information where the process died. Very useful!

Let me know if you need help.
 
Back
Top