I2C example with stop condition in logic analyzer leads to crash (R1103@WIN10)

I tried to use the example ".../examples/Logic/Memory/I2C_RAM/i2cRam_328.sim1" with the trigger condition "CH1F" in the logic analyzer in R1103@WIN10 selected. The simulation directly crashes after starting: It closes without additional info / error message. I tried to "single step" trough the circuit. In this case the last value of the PC was decimal 821.

I have the vague suspicion, that the might be a memory or CPU ressource issue somewhere. I have the feeling, that after starting WIN freshly, Simulide to crashes less. And it seems to crash more, when additional load (= some other running programs in WIN) is applied.

I will have a look.

About the crashes:
I noticed that Windows, at least Win10, closes the program if it becomes "irresponsive".
So sometimes it is not a crash but a forced "kill" of the process.

Yes, I know this type of crash. In the not-responding case the Simulide window often gets "grayed out". In the case here, the window suddenly closes and simulide did not show high load before.

I keep my fingers crossed that you can reproduce it and find something, since I'm still try to hunt the bug (families), which leads to arbirtrary crashes on WIN systems...
The students gets now less annoyed, compared to last year. But they are still sometimes confused by sudden crashes.

Yes, I know this type of crash. In the not-responding case the Simulide window often gets "grayed out". In the case here, the window suddenly closes and simulide did not show high load before.

Good to know...

I keep my fingers crossed that you can reproduce it and find something, since I'm still try to hunt the bug (families), which leads to arbirtrary crashes on WIN systems...

Well... I can't reproduce it in Linux or Windows 10.
But sometimes is all about doing the exact same thing.
Here is what I'm doing:

Hmm...

That's what it is for me:
https://wiki.mexle.org/_media/2022-07-05_14-39-27.mp4

Sometimes with "grey out" (in this case I killed the tasks), more often without. For small stepping the terminal PC is around 820...840. I haven't recorded the single step per second, but in this case it was 821.

Damn... And I thought I got him ...

Damn... Evil or Very Mad And I thought I got him ...

Well... I think we've got it surrouned.
We know it is not an actual crash, for some reason it gets stuck and I know exactly where.

One thing I noticed is that machine seems slow, this could be a factor.
Is that 32 or 64 bit PC?

I can't be sure if this will solve the issue because I can't reproduce it, but if you have time to test it we will know:

https://drive.google.com/file/d/1rBZ-yj1GAh6hEXFHfvniPvL12E5WJpQE/view?usp=sharing

The version you provided works beautifully
What did you change?

(BTW: my machine looks slow, because I'm also in other tools a heavy user   and I have some tabs and windows to work through   )

The version you provided works beautifully bounce
What did you change?

Nice to know.

Your video shows exactly where is the problem:
Note that the message in tool bar shows: "Paused", but the message "Simulation paused" is not shown in the bottom panel yet and the pause button is not activated.
That happens in 2 adjacent lines of code, so nothing there can block the program.

This nonsense usually means some inter-thread conflict.
Then I realized that the call to the UI to set the message and activate pause button, etc. is not thread safe.
So I made the call to only set a flag and the proper thread reads the flag in the proper moment and proceed to modify the UI.

If the machine is slow (or overloaded) the call to the UI probably happens in the middle of the UI updating or something.
But if the machine has time to do all the UI stuff before the call, then nothing bad happens.
That is in line with your appreciation that the more cpu load the more it tends to crash.

These threading problems are not obvious, so we were lucky this time.

Ah.. Thanks for the info.

At least one catch of these ugly bastards
They really sound hard to break down.

The next time, I find a strange crash on load, I'll be alert. I'll have a look whether a single core VM (WIN in WIN) does not show this issue. Might be a good test bed for me.

In a WIN in WIN VM the situation is similar to what you saw: no bug at R1103 when no additional load is applied. When I add some more load (e.g. 2 additional SimulIDE instances running the Marduino game + Browser + x) I unregularily get the bug.

On a quieter time in my calendar I try to find an stable "load emulation"  in the VM...