Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0003_esp8266_esp32_send_data crashes #164

Closed
leoujz opened this issue Nov 12, 2023 · 2 comments · Fixed by #180
Closed

0003_esp8266_esp32_send_data crashes #164

leoujz opened this issue Nov 12, 2023 · 2 comments · Fixed by #180

Comments

@leoujz
Copy link

leoujz commented Nov 12, 2023

example 0003_esp8266_esp32_send_data crashes after "Connected to AP", running on Arduino IDE, on ESP32 dev module, with

#define USING_HTTPS false
#define ENCRYPTED false

After comparing with another example, finally I found that is caused by

#define THINGSBOARD_ENABLE_STREAM_UTILS 1

After deleting this line, it successfully connect to the server and do the expected things.

does that mean THINGSBOARD_ENABLE_STREAM_UTILS can not be used on ESP32? maybe no need to use it on ESP32?

Thanks for the great work of thingsboard, all the things are great!

@MathewHDYT
Copy link
Contributor

MathewHDYT commented Dec 20, 2023

Issue was reproducible in combination when using MQTT and enabling the usage of STREAM_UTILS it causes a crash with the ThingsBoard::connected() method more specifically the crash occurs when it attempts to call the IMQTT_Client::connected method.

Meaning it crashes on the virtually dispatched call.


I could further debug the issue it prints a InstrFetchProhibited exception and crashes with this backtrace.

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

Core  1 register dump:
PC      : 0x00000000  PS      : 0x00060d30  A0      : 0x800dce14  A1      : 0x3ffcab80  
A2      : 0x3ffc3a30  A3      : 0x3ffc3738  A4      : 0x3ffc3d54  A5      : 0x3f40025b  
A6      : 0x00000000  A7      : 0x80000001  A8      : 0x800d5bcf  A9      : 0x3ffcab60  
A10     : 0x3ffc38a0  A11     : 0x3f400276  A12     : 0xa7df7740  A13     : 0x3ffcab1c  
A14     : 0x3ffc3d54  A15     : 0x3ffcab1c  SAR     : 0x00000015  EXCCAUSE: 0x00000014  
EXCVADDR: 0x00000000  LBEG    : 0x4008abd5  LEND    : 0x4008abe5  LCOUNT  : 0xffffffff  

Backtrace: 0xfffffffd:0x3ffcab80 0x400dce11:0x3ffcac00

  #0  0xfffffffd:0x3ffcab80 in ?? ??:0
  #1  0x400dce11:0x3ffcac00 in loopTask(void*) at /.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50

It seems like the method it attempts to call are invalid. That is really weird tough because the underlying object is correct, the reference does point to a valid instance of the IMQTT_Client in memory.

I'm also rather confused why this occurs only when I enable THINGSBOARD_ENABLE_STREAM_UTILS, because the only thing that define changes in the associated class is adding more methods to both the interface and the implementation.


The only thing I can think of is the stupid way that is step for step removing the code that THINGSBOARD_ENABLE_STREAM_UTILS creates and then once it does not crash anymore readding the code until it crashes again. That should hopefully help get the specific lines that cause issues.

Used that method to debug further and what I could find out is that the Print inheritance causes direct issues with not being able to call any method without crashing. If that is removed it works partially again.

But additionally the begin_publish and other added calls if THINGSBOARD_ENABLE_STREAM_UTILS is enabled do not seem to be instantiated correctly because if the checks are removed to add those methods they do not crash anymore. If that is not done tough it causes a crash if it attempts to call them.

@MathewHDYT
Copy link
Contributor

MathewHDYT commented Dec 23, 2023

The underlying issue has been resolved it was the macro, causing issues because it was sometimes overwritten correctly and other times not. To resolve that issue the library now automatically detects if the StreamUtils library is installed and if it is it enables the aforementioned feature, otherwise it does not.

Additionally there also was a small mistake in the implementation that caused disconnects even if the data could be sent. That has been resolved now as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants