crash when running thread

[crankshaft]

I have the main thread and another thread, available memory whilst both are running is more than 50% free,

Here's the backtrace:

Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x400e9598  PS      : 0x00060b30  A0      : 0x800e95ec  A1      : 0x3ffe1850  
A2      : 0x3ffe43f0  A3      : 0x00000001  A4      : 0x00000000  A5      : 0x3ffe1870  
A6      : 0x400dbf40  A7      : 0x3ffc1068  A8      : 0x800e9598  A9      : 0x3ffe1830  
A10     : 0x0000000d  A11     : 0x00060b23  A12     : 0x00060b20  A13     : 0xb33f0000  
A14     : 0xb33fffff  A15     : 0x00060923  SAR     : 0x00000013  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000001d  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400e9598:0x3ffe1850 0x400e95ec:0x3ffe1870 0x400dbf50:0x3ffe18a0 0x400e071f:0x3ffe18c0 0x400d7e80:0x3ffe1940

                                                                                                                        Rebooting...
ets Jun  8 2016 00:22:57

Any suggestions on what this is indicating - 'loadProhibited' ?

[livius]

@crankshaft
loadProhibited is equal to desktop Access Violation

[jmarcelino]

You can have an idea of what going on by building micropython from source (from https://github.com/pycom/pycom-micropython) and using gdb or addr2line

Once built go into the build directory (build/WIPY/release) and run:

xtensa-esp32-elf-addr2line -fe application.elf 0x400e9598

My source is modified and I'm running on the LoPy not the WiPy so the result will very likely not not match yours (your build should match exactly what you're running, same version, same options, so ideally run your own build on the WiPy), but just as an example for me it says:

Dev/LoPy/build/pycom-micropython/esp32/../py/parse.c:1027
(but as I explained above this may NOT be the same for you)

Another option is to use gdb:

xtensa-esp32-elf-gdb application.elf

Then take your PC (program counter) from your dump:

info symbol 0x400e9598

which should return where in the code it crashed.

mp_parse + 1020 in section .flash.text

If you want to get really deep into it you can also do :

disassemble 0x400e9598

and get a complete disassembly of where the code crashed.

[crankshaft]

@jmarcelino - thanks, I am now seeing crashes regularly pretty much when anything that involves interrupts or threads.

I am starting to think that maybe threading is still work in progress ??