LoadProhibited Exception in readBmpHeader

[michaelotto]

I run three Inkplates pretty much since the beginning and have been getting spontaneous reboots from time to time (every few hours). I never bothered much but today I took the time to debug. I traced it down to this:

Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump:
PC : 0x400d8187 PS : 0x00060b30 A0 : 0x800d8775 A1 : 0x3ffb1b40
A2 : 0x3ffc4e34 A3 : 0x00000000 A4 : 0x3ffb1fa0 A5 : 0xb1cf72f9
A6 : 0x3ffb1d68 A7 : 0x3ffb1d78 A8 : 0x800df4ca A9 : 0x3ffb1cb0
A10 : 0x00000000 A11 : 0x00000000 A12 : 0x00000000 A13 : 0xfffffff5
A14 : 0x00000000 A15 : 0x3ffb1d08 SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000001 LBEG : 0x4008b774 LEND : 0x4008b78a LCOUNT : 0xffffffff

Backtrace: 0x400d8184:0x3ffb1b40 0x400d8772:0x3ffb1f70 0x400d8aca:0x3ffb1fe0 0x400d8083:0x3ffb2020 0x400d286a:0x3ffb2060 0x400d2c2e:0x3ffb2080 0x400d3065:0x3ffb20b0 0x4017c093:0x3ffb21f0 0x400e346d:0x3ffb2210 0x400d32e1:0x3ffb2260 0x400e6fdd:0x3ffb2290

PC: 0x400d8187: is in Image::readBmpHeader(unsigned char*, bitmapHeader*) (.../Arduino/libraries/InkplateLibrary/src/include/ImageBMP.cpp:88).
EXCVADDR: 0x00000001

Decoding stack results
0x400d8184: is in Image::readBmpHeader(unsigned char*, bitmapHeader*) (.../Arduino/libraries/InkplateLibrary/src/include/ImageBMP.cpp:87).
0x400d8772: is in Image::drawBitmapFromBuffer(unsigned char*, int, int, bool, bool) (...Arduino/libraries/InkplateLibrary/src/include/ImageBMP.cpp:281).
0x400d8aca: is in Image::drawBitmapFromWeb(char const*, int, int, bool, bool) (.../Arduino/libraries/InkplateLibrary/src/include/ImageBMP.cpp:225).
0x400d8083: is in Image::drawImage(char const*, int, int, bool, bool) (.../Arduino/libraries/InkplateLibrary/src/include/Image.cpp:84).
...

(the rest is my sketch).

So there seems to be a unauthorized buffer access problem in this method. This is totally plausible, because I'm exclusively using BMP bitmap files.

BTW: Using 10.0.0

[rsoric]

Hi @michaelotto,

sorry to hear you're having this issue. Due to the fact we're talking about an ESP32 and it's limited image processing capabilities, I think it's possible that your .bmp files are somehow formatted in a way which could cause errors.

Please try the following:

• Make the .bmp files 24-bit
• Make sure they're uncompressed BMP (so no RLE or any other compression)
• Make it Standard BMP version 3 (Windows BMP)

I think this could potentially solve your issue, give it a try. If there are still crashes, we'll look into it

-Rob

[michaelotto]

I don't think that it's that, because after the ESP reboots, it displays the exact same image - without any problems.

Anyway, whatsoever badly formatted data should not make the library and Inkplate crash.

[michaelotto]

BTW: The EXCVADDR shows that the library is accessing data at memory position 0x00000001, which is clearly not right.

[rsoric]

I agree it shouldn't crash, it's just that I was trying to determine the cause and see if it can be amended by formatting the image in a specific way.

@BornaBiro could you please have a look at this?

[rsoric]

Borna was just here so I'll reply in his name,

Seeing how you're using drawing image from web, there is an issue with how, if the downloading of the image fails - and there's an error - it will still attempt to draw the image, referring to your comment about accessing data at 0x00000001.

This is something which we can handle within the library, returning that drawImage failed and then letting the user repeat the action if necessary. Our team has been notified regarding this and we're going to look in fixing this issue in this way and reporting back here when we do.

[michaelotto]

As a very quick fix that at least solves my problem, I added

if (!buf)
   return 0;

in line 225 in ImageBMP.cpp. But this surely has to be checked elsewhere, too.

You can easily provoke the error if you try to load an image from a URL where there is no web server at all (so not a HTTP error response, but no response at all). It instantly crashes any sketch.

[rsoric]

Thank you @michaelotto, this has been added as a quick patch for now to the dev branch of the library and is set to be more seriously reformatted some time in the future. The quick patch will thus be included in the next release.

Gonna close the issue for now as this was resolved with this quick patch.