and found that 5 out of 11 attempts will open the UI successfully and display the graphs. The other 6 will show a white window and crash the UI.
JLS File, crash log, screenshot found here:
Windows fatal exception: code 0x8001010d
Thread 0x00002438 (most recent call first):
File "joulescope\usb\winusb\win32_device_notify.py", line 119 in _run_window
File "threading.py", line 892 in run
File "threading.py", line 954 in _bootstrap_inner
File "threading.py", line 912 in _bootstrap
Thread 0x00000af0 (most recent call first):
File "joulescope\data_recorder.py", line 897 in _reduction_handler_v2
File "joulescWindows fatal exception: oaccess violationp
e\data_recorder.py", line 869 in _reduction_tlv
File "joulescope\data_recorder.py", line 934 in get_reduction
File "joulescope\data_recorder.py", line 1051 in data_get
File "joulescope_ui\recording_viewer_device_v1.py", line 121 in _update
File "joulescope_ui\recording_viewer_device_v1.py", line 327 in run
File "threading.py", line 892 in run
File "threading.py", line 954 in _bootstrap_inner
File "threading.py", line 912 in _bootstrap
Thread 0x00001370 (most recent call first):
File "multiprocessing\connection.py", line 816 in _exhaustive_wait
File "multiprocessing\connection.py", line 884 in wait
File "multiprocessing\connection.py", line 335 in _poll
File "multiprocessing\connection.py", line 262 in poll
File "multiprocessing\queues.py", line 113 in get
File "joulescope_ui\logging_util.py", line 181 in _listener_run
File "threading.py", line 892 in run
File "threading.py", line 954 in _bootstrap_inner
File "threading.py", line 912 in _bootstrap
Current thread 0x000022dc (most recent call first):
File "joulescope_ui\main.py", line 1942 in run
File "joulescope_ui\entry_points\ui.py", line 50 in on_cmd
File "joulescope\entry_points\runner.py", line 105 in run
File "joulescope_ui\__main__.py", line 41 in <module>
Thanks for the detailed information. I download the JLS file, and of course, it works great (no crashes in 20 tries with Joulescope UI 0.9.7) on the first machine I tried. I noticed that 0.9.5 fixed a race condition when starting the UI with the JLS file argument. It looks like we did not entirely fix the issue.
I think that the device discovery is conflicting with opening the JLS file. If you unplug your Joulescope and start the Joulescope UI with the JLS file argument, does the UI always start without crashing?
Thanks for the additional log files, @andrewhh ! joulescope_20210816_163855_2448.log was especially strange with two different crash stack traces.
I tried to duplicate the issue on two different machines across several different SSDs, HDDs, and network drives with no success yet. I have a few more machines that I will try…
Thank you for the offer @andrewhh . Ideally, I would like to recreate the issue on a local machine so that we can investigate and know that we fixed it. Let me see what we can do, but I may take you up on the offer. Thanks!
The i3-5005U will not be winning any performance awards, but it should still run the Joulescope UI. We will consider slower processing causing race conditions while looking for the issue.
I’ve been looking at the stack traces and code. I haven’t found any issue yet, but I do have a question.
If you launch the Joulescope UI normally without a Joulescope connected and then do File → Open, do you see the same crashes on this machine? If it works the first time, you can select Device → disable and then repeat.
I tried this procedure 3 times with the Joulescope connected and 3 times with the Joulescope not connected. Crash only on attempt 4. Successful open 5/6 other times.
I got the log files. You should also be able to post the links normally going forward since I marked as not spam.
I took a look, and every single log shows an access violation. It’s strange, but most of the access violations seem to occur while simultaneously:
Attempting to read the JLS file, but at different points in the code.
Attempting to check for Joulescope UI updates.
Not sure it’s going to help, but you could turn off the automatic update check. File → Preferences → General → update_check and click to unselect it.
Thanks for the video. Finding segfaults in python is painful, and I am not making much progress. I suspect something about how numpy is processing the JLS file. The code is likely not holding onto a reference that is used slightly later. These types of issues take a long time to track down.
How about a different approach? The JLS v1 file format you are currently using is on the way out. While we will continue to support it for a long while, the JLS v2 format is a huge improvement and is already being used by a few customers. The Joulescope UI already supports viewing the JLS v2 file, so you should be able to use it to display your captured data.
I created a new capture_jls_v2 example. Can you capture your data like this to the JLS v2 file format?
Hi @andrewhh - Great to hear that the JLS v2 file format works. Yes, recording voltage and current will be 2x the size, at least until we add compression. The JLS v1 format stores the raw 14-bit samples (32-bits @ 2 MHz), at least for full-rate data. The v2 format always stores float32 values for current and voltage.
I refactored the JlsWriter into pyjoulescope. You will need to upgrade:
pip3 install -U pyjls joulescope
I updated the trigger example to store JLS v2 by default.
Thanks for updating trigger.py! Yes it fits now into my automated setup. I changed trigger.py to disable all output and only output JSON so my script can read the output more easily.