Law

Thanks for confirming that QHsm is allowed inside an extended thread via composition. This led me to investigate into my own code for the memory corruption issue. Too often we forget to check for stack overlow, and "obviously" in hindsight the memory corruption was caused by incorrecting sizing the stack of the extended thread. It called into a library that used more stack memory than initially sized for. Just want to share this with other readers. The 6.0.2-beta qpcpp works fine with a "dual-mode"...

Thanks so much for confiming the fix. I have tried the 6.0.2 version and this issue is gone. However I ran into another hardfault by just haveing one xthread! I post an event to it before calling run(). The xthread is waken up and got the event from the built-in queue. I then dispatch the event to the composed QHsm inside a the xthread (in a class derived from it). The QHsm got the event but some time later either it got a hardfault or assert when calling get from the queue again. Looks like memory...

Hi Miro, Can you please confirm that it is NOT allowed to encapsulate a QHsm object in an extended thread? It looks like after dispatching an event to an QHsm object inside an extended thread, the thread context is corrupted. Thanks!

I spoke too soon. In 6.0.2 beta, when I tried to post a event in the extended thread, it triggered another hardfault. Not characterized yet, but not it doesn't seem stable.

Okay - there is a new 6.0.2 beta version that fixed this issue! Glad to see it. I wonder why this wasn't caught before release! Thanks for fixing this quickly.

Hi, has anyone looked into this issue? I ran into the exact same problem. I'd like to know if there is an old version I could revert back to. I remember there was no such issue a while back. Thanks!