Doing it the hard way: mapping errors to line numbers.

Supposing I was debugging and had a Garmin log file, the original .iq archive but no ERA report.

I had thought that I could simply to a hex > decimal of the error location and get to a corresponding pc="" entry in one of the debug.xml.

Only...

I'm doing something wrong!

The error I saw was:

CALLSTACK: @PC = 0x100032fc

And if I do a hex to decimal of 100032fc I get 268448508

However, the humanised error log would have been:

Stack: [SYMBOL] at [PATH]:198 0x100032fc

And that equates to:

So clearly my simplistic hex > decimal conversion is wrong!

Anybody know the actual way to convert / interpret these codes?

Thanks,

0 jim_m_58 over 5 years ago

See

https://forums.garmin.com/developer/connect-iq/f/discussion/231129/so-you-have-a-ciq_log-file-but-all-you-see-is-pc-without-a-friendly-stack-trace---what-to-do

Brandon.ConnectIQ was going to add this to the FAQ but not sure if he has yet

0 9635560 over 5 years ago in reply to jim_m_58

I think that’s pretty close to what I tried, but my hex to decimal got a result 14 away from what I needed, when there is an exact match in debug.xml

Is there definitely nothing else at play?

14 in 268 million doesn’t sound much, but in the debug.xml it made the difference between in the styx versus in the right place.

0 jim_m_58 over 5 years ago in reply to 9635560

A line number doesn't map to a specific byte code (one line of source can multiple byte codes) so that's why it may appear to be between to line numbers.

Prior to ERA, this was how devs had to deal with all ciq_log files from users.

0 Travis.ConnectIQ over 5 years ago

When searching debug.xml, you want to find the PC value that closest to and is less than or equal to the value you are searching for.