Using symbols.db

SDK Get Help
, ,
1

I've got an on device crash that I'm debugging, and I want to make sure I'm using symbols.db correctly.

Firstly, this is my crashlog.txt:

build:bcbf4fed-2.6.0-release.176236-buildbot
   r0:00000000    r1:90fab954     r2:00006140    r3: 00000000
  r12:240dbc86    lr:24098279     pc:24052ab8   psr: 210f0200
 cfsr:00000082  hfsr:00000000  mmfar:00000000  bfar: 00000000
rcccsr:00000000
heap allocated: 16481440
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

As I understand it:

  • pc is the address of the function that was executing when the crash occurred
  • lr is the return pointer from that address. I can think of it as the second function in the stack trace

Both 0x24052ab8 are 0x24098279 functions within the SDK.

For each of those, am I correct in the formation of the following queries?

> sqlite3 /usr/local/playdate/bin/symbols.db ".headers on" ".mode column" \
  "SELECT * FROM functions WHERE 0x24052ab8 BETWEEN low AND low + size;"

name    low        size  hw_id
------  ---------  ----  -----
hidden  604318372  422   1    

> sqlite3 /usr/local/playdate/bin/symbols.db ".headers on" ".mode column" \
  "SELECT * FROM functions WHERE 0x24098279 BETWEEN low AND low + size;"

name               low        size  hw_id
-----------------  ---------  ----  -----
LCDBitmap_addMask  604602804  252   1    

> sqlite3 /usr/local/playdate/bin/symbols.db ".headers on" ".mode column" \
  "SELECT * FROM lines INNER JOIN files ON file_id WHERE lines.low < 0x24052ab8 ORDER BY lines.low DESC LIMIT 1;"

id      low        file_id  lineno  hw_id  id  path
------  ---------  -------  ------  -----  --  ----
200542  604318390  142      0       1      1   OS  

> sqlite3 /usr/local/playdate/bin/symbols.db ".headers on" ".mode column" \
  "SELECT * FROM lines INNER JOIN files ON file_id WHERE lines.low < 0x24098279 ORDER BY lines.low DESC LIMIT 1;"

id      low        file_id  lineno  hw_id  id  path
------  ---------  -------  ------  -----  --  ----
349249  604603000  241      271     1      1   OS

Does that all look right?

And while I'm here, Is there any other userful information I can gather from the crashlog?

2

Instead of trying to manually look up symbols, you can use the firmware_symbolizer.py script found in the /bin folder to symbolicate device crashes.

3

Unfortunately, that hasn't been helfpful:

build:bcbf4fed-2.6.0-release.176236-buildbot
   r0:00000000    r1:90fab954     r2:00006140    r3: 00000000
  r12:240dbc86    lr:24098279     pc:24052ab8   psr: 210f0200
 cfsr:00000082  hfsr:00000000  mmfar:00000000  bfar: 00000000
rcccsr:00000000
heap allocated: 16481440
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0 

?? ??:0
?? ??:0

And when I look at the source for the symbolizer, it doesn't query the symbols database

4

Oh right, it only symbolizes app elf files...hum.

5

Oops. I just found that I never hit "Reply" on this. :frowning: Here's what I wrote last week:

The SQL query looks right, though I guess the lines table isn't very useful to you. FWIW 0x24052ab8 is in memcpy(), and I don't think there's any good reason for us to obscure that. I'll file an issue on getting newlib symbols back in--though, again, I'm not sure how useful it would be here. You'd see that it's memcpy crashing, and from $r0=0 you could guess that it's trying to copy into a null pointer. It looks like what's happened is you've run out of memory and the allocation for the mask data has failed. (We don't generally check for OOM errors because there's not much we can do anyway and pushing the error up the stack usually leads to weird buggy behavior because it's not handled properly there either.)

I'm not 100% sure the heap allocated value is correct (I know the Lua memory stats are a bit fishy) but it does look like you've malloced all the way to the end of the heap. You can get a view of memory usage by opening the Device Info window and opening the Memory tab.

6

Thanks for taking a look — you’re right on all accounts. I was running out of memory because of a combination of missing pools in some places, oversized pools in others, memory fragmentation, and a couple of good old fashioned memory leaks.

1 Like