Companion 2.7.1 Simulator and Standalone Simulator crashes with attached OTX file
Is there an existing issue for this problem?
- [X] I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Simulator
Current Behavior
The EdgeTx 2.7.1 companion simulator crashes, after loading this OTX file in Companion and launching the simulator. Also if I copy the MODEL and RADIO folder to the SD-Card Path, the standalone simulator (SD Card Mode) crashes after converting the bin file.
EDGE-Simulator-Crashes_with_this_Model.otx.zip .
Please rename the file to EDGE-Simulator-Crashes_with_this_Model.otx
I inspected all settings in the modell programming windows, for me it looks fine. But anything went wrong.
Expected Behavior
EdgeTx Companion will crash
Steps To Reproduce
- Start EdgeTX Companion 2.7.1
- Open the attached OTX file
- Start the simulation
- EdgeTx Companion will crash
Version
2.7.0
Transmitter
FrSky X10 Express / X10S Express (ACCESS)
Anything else?
No response
Does not crash for me on Ubuntu 20.04 however I do not have your sd card contents. There are known issues with themes causing crashes. A known issue is a single dash '-' for a tag value in the theme.yml file.
for the case:
1.Start EdgeTX Companion 2.7.1 2.Open the attached OTX file 3.Start the simulation 4. EdgeTx Companion will crash
I've also tried with any empty SD-Card folder and crashes too.
I've tested a clean installation on a clean windows 11 System, create a Radioprofile Horus X10S Express leave all other defaults and empty SDCard folder. Then 1.Start EdgeTX Companion 2.7.1 2.Open the attached OTX file 3.Start the simulation 4. EdgeTx Companion will crash
and crashes again.
Tested on Win 10 and it crashed
Yes. It seems to be an issue on Windows Plattforms. Same test on an Ubuntu 20.04 works without crash.
Win 10 simulating FrSky X10 Express from Companion:
- new file and new model does not crash
- your radio settings and new model does not crash
- default radio settings and your model does crash
- resetting all GVs to defaults and your model does not crash
- clearing the unit against each GV and your model does not crash and whilst in sim -- editing GV unit to % causes instability and sim crashes but not consistently at same place
- loading the saved temp files from the sim with the % unit added back into Companion and then simulating crashes
Win 10 standalone Firmware Simulator:
- using the saved temp folders with % unit added by the sim and the new sim session crashes
Win 10 simulating FrSky X12S:
- convert and your model crashes
Win 10 simulating FrSky X9D+:
- convert and your model does not crash
Win 10 simulating Radiomaster TX16S:
- convert and your model does not crash
On the radio hardware does the otx convert and work?
I will test it this evening. Actually I run OTX on the Horus X10S Express. I will report.....
Now I've tested on Horus X10S Express. It works as fine as in Ubuntu.
But I have now loaded a model converted from the Horus X10S Express via the Windows Companion. If I now start the simulator with it, it also crashes.
Would be good if a Mac user could test.
I was able to reproduce the crash on win 11 x64 in simulator (both via companion and standalone), but not via simu (although that is running via WSL2 so Linux build. Nothing useful in the debug logs as far as I could tell. I suspect it was something the simulator firmware didn't like in the model settings, as it loaded as much as the initial screen for the model then crashed. There may be some connection to #1933 as that also seems like a windows specific simulator crash.
CompanionDebug_22-06-07_19-15-14.zip
SimulatorDebug_22-06-07_19-17-26.zip
Now I was able to check and reproduce the crash on Windows 11 Companion Simulator. I used the attached Model file. If I set in Companion GVARS 1-3 in FM0 to 100% than the Simulator will run. But if you open the "Global Variables" programming page in Simulator and change the value FM0 GVAR1 from 100 to 99 the Simulator will crash instandly.
Hope that helps to find the bug.
@pfeerick in 2.8.0 selfbuild there is no crash anymore. What should we do with this ticket?
If it no longer crashes, If it no longer crashes, that hopefully means it was fixed (either expressly or accidentally). Either way, it no longer crashes for me either with a recent github build. I think it can be safely closed, and can be revisited if it pops it's ugly head up again. Normally you'd be fine to close it since you opened the issue, but it's good you pre-warned me as I'll tag it against 2.8 ;)