search

JKISoftware / JKI-State-Machine-Objects

Object-oriented framework for LabVIEW based on the JKI State Machine
BSD 3-Clause "New" or "Revised" License
96 stars 55 forks source link

Common LabVIEW crashes when using SMO #12

Closed 3esmit closed 4 years ago

3esmit commented 8 years ago

This is quite normal, and many others alike errors. I just got used to save all project before opening SMO Editor. After forced restart all runs normal. image

francois-normandin commented 8 years ago

Can you tell us in which LabVIEW version/service-pack you see these image.cpp crashes? It's been reported to happen in general with using arrows for comments. I have not followed if/when this is/was fixed.

3esmit commented 8 years ago

13.0.1f2 (32-bit) . Hey, can you guys at JKI tell NI to start using github? Or I wil have to keep using twitter (as Twitter seems to drag a little bit more attention to my issues being really fixed then just using phone support). Like this issue, I guess is their problem, and I have the internal report but JKI is able to read it? I think just NI can undestand this files. Anyway, here is the LVInternalReport for the above screenshot. ec170735-b818-470f-b5e1-eb804f90e1f9.zip Thank you.

3esmit commented 8 years ago

Another crash creating SMO. Details: Created Dyna.UI.Test wrongly with SMO.Basic then deleted Dyna.UI.Test from project, saved project and deleted Dyna.UI.Test folder and contents, pressed refresh in SMO Editor to reload list, tried to use Chart[Template].vi to add new Dyna.UI.Test, crash. 7e613142-a6ba-41d5-acb1-4a0adc47a313.zip

francois-normandin commented 6 years ago

I know this is an old thread. I'm still gonna bump it to mention that I've been playing around with updating the SMO Editor lately (not public yet), but I came across a few of those crashes while making tests with context management (App Instances). This is not to say that I understand the issue that generate those types of crashes, but they are on the radar.

One way I found that did produce crashes often enough for me to see a trend was this workflow:

The class stays in memory within that context (until project is closed) and the SMO Editor cannot get rid of the class reference without LabVIEW crashing. I suspect the culprit is that the class, still being in memory but inexistant on disk, causes LabVIEW to try to synchronize it across multiple contexts (one of which does not exist anymore) and fails to do so in a spectacular manner. Don't know if this makes any sense (but it's the best guess I have atm).

3esmit commented 6 years ago

I'm not sure, I've quit working with LabVIEW.