another odd Guru Meditation Error

[mzimmers]

Hi -

I have this routine:

Code: Select all

void Message::buildSilenceAck()
{
    string s;
    s = m_params->nvs->getIpAddr(IP_ADDRESS);
}

I get a GME on the assignment. I've verified that the routine being called returns a valid string.

Here's what's odd: when I change the assignment to this:

Code: Select all

 s = "10.10.0.157"; //m_params->nvs->getIpAddr(IP_ADDRESS);

It works.

Is this some kind of heap allocation error in disguise?

Thanks...

[ESP_igrr]

It may help if you post the panic handler output along with the decoded backtrace.
You may also find the error easier to debug if you enable gdbstub — this will drop you into a gdb session at the point the exception happens, then you can inspect variables and see what went wrong.

[mzimmers]

Thanks, igrr...I'll post it tomorrow.

Is there anything that works with gdbstub in the way of a visual debugger? I haven't used a command line debugger since Reagan was president!

[ESP_igrr]

Not that I know of. It is possible to launch gdb in MI mode and let some IDE like Eclipse connect to it, but that's not something that is easy to set up. Given that you only need a couple of commands ("p" for printing variables, "bt" for backtrace) you should be able to get enough info from the console debugger. GDB also can show you source or disassembly or both in a "window-like" UI, you can toggle it using "layout" command.

[mzimmers]

This is everything I get on the console when the error occurs:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400e1c8e  PS      : 0x00060a30  A0      : 0x800dd169  A1      : 0x3ffebdc0
A2      : 0x3fff0b10  A3      : 0x3fff16d8  A4      : 0x3fff0b10  A5      : 0x3fff0b14
A6      : 0x00000000  A7      : 0x3fff16dc  A8      : 0x00000000  A9      : 0x3ffebda0
A10     : 0x3ffebdec  A11     : 0xc98ca0b5  A12     : 0x00000000  A13     : 0x3fff07b0
A14     : 0x3fff0b14  A15     : 0x0000000a  SAR     : 0x00000005  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000010  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000

Backtrace: 0x400e1c8e:0x3ffebdc0 0x400dd166:0x3ffebe80 0x400dd5b9:0x3ffec0d0 0x400de257:0x3ffec570 0x400de2c3:0x3ffec5c0

CPU halted.

I'll experiment with GDB stub today. Thanks...

[ESP_igrr]

LoadProhibited, EXCVADDR: 0x00000010 tells that the code has likely tried to access a member of a structure at offset 0x10, but the pointer to the structure was NULL.

If you use idf_monitor ("make monitor" with Make build system, "idf.py monitor" with CMake), then the backtrace will automatically be converted into function names and line numbers, making it easier to understand where the error happens. More on this is explained in https://docs.espressif.com/projects/esp ... rrors.html

[mzimmers]

Hi Igrr -

I already know where the error is occurring (at least in application space). I did confirm this with monitor.

What I don't understand is why. I can't see anything wrong with my line of code. I get the feeling that something in the i2c component is exhausting a system resource (like semaphores), but that's just a sense.