Code crashes after 10-15minutes for Linux/Win32 profile on Embedded Wizard version10.0

Question

Hi,

Our code is getting crashed after some time when it is kept running continuously for unit testing.

I would like to brief you about it:

GUI screen is controlled by gRPC protocol – gRPC is a modern open-source high performance Remote Procedure Call (RPC) framework that can run in any environment – it is acting as middle layer which sends request to EW Application as per Main Application requirement and related screen and screen live data is shown at EW Code and on key pressed event, response is sent back to Main Application through gRPC.

Currently request and response is running continuously and only 2 screens are getting displayed one by one in loop.

After some time, it is getting crashed.

It could be segmentation fault due to pointer behaviour; we are digging into it.

But would like to understand below code part from Core.c (it is for Linux Profile) and possible reason of crash and how to debug it.

 

On first screen some texts are there along with % value for loading(similar to battery management) and 1 bitmap image which is getting loaded through External Bitmap method + 5 functional keys.

Second screen consists of 12 Text Widgets – each widget has 2 texts + 5 texts + 16 (39*39 size) icons/images + 5 functional keys.

 

Observation – the loop is running approximately 400 times and gets crashed.

Crashing is observed on win32 profile as well.

Attached is the log observed for both the profile Win32/Linux profile 

Note: Similar issue was not observed with Lower version i.e 8

https://ask.embedded-wizard.de/?qa=blob&qa_blobid=2618858202834056435

https://ask.embedded-wizard.de/?qa=blob&qa_blobid=1169565748581249156

Answer 1

Hi Pidea,

I'm not sure if your support request is related to GUI development with Embedded Wizard so that we can help you here efficiently.

So far I'm not familiar with gRPC. Can you provide a reproducible example without gRPC?

One important note: The entire GUI application has to be executed/accessed only within the GUI thread/task.

Can you ensure that the GUI application is never accessed from a different task? 

Best regards,

Manfred.

 

Comments

Hello Pidea,

I followed the discussion here and it seems that we are moving far far away from support concerning GUI development with Embedded Wizard.

It turned out, that the initial "code crash" was caused by accessing GUI code from different threads, which has to be avoided in any case.

Additionally, a tested code snippet was provided in the above discussion, that demonstrates how to post and receive message between Win32 threads.

However, all other topics concerning communication between your master and slave, between two Win32 executables or via gRPC are not related to Embedded Wizard. Let me recommend to study the documentation of Microsoft or gRPC to understand their technology. I hope for your understanding that we cannot provide free-of-charge support for third-party software stacks.

Thank you and best regards,

Manfred.

---

sure thanks for the reply

---

hi,

If i want to debug the statemennt in core.c

Is it posible to modify the core.c and take a log for the same

https://ask.embedded-wizard.de/?qa=blob&qa_blobid=17038744164630216977

---

Hello Pidea,

for debugging purpose, of course, you can modify the generated Core.c file and add some printf(), etc. code for logging purpose. Doing this, don't forget that when you generate the code again, the modifications are overwritten. However, I'm not sure whether it will help you to solve the crash problem.

From the attached screenshot I deduce that there is some invalid Task object existing in a TaskQueue. The TaskQueue refers to an object 0xDDDDDDDD which is surely not a valid object address. Such error indicates that EmWi code has been called from a foreign thread or native code has overwritten Embedded Wizard memory areas. Whatever happened, the existing Task or TaskQueue object is corrupted now.

If your application does still use threads which invoke EmWi code, I would focus on this issue to ensure that no thread does call EmWi code. Please note the parallel discussion via e-mail concerning the threads invoking ApplicationDeviceClass_HomeTriggerEvent() Embedded Wizard function. Exactly this function will create and append a new Task on a global TaskQueue (to store the event inside it). Doing this in context of a foreign thread will surely lead to the observed crash. So my question: have you solved this multi-threading issue already?

Best regards

Paul Banach

---

Hi Paul,

 

I am working on multi-threading issue. But also I want to find out the cause for crashing .