Priority(1) after Screen('OpenWindow') causes Screen('OpenMovie') crash #857
Comments
|
Psychtoolbox 3.0.19 is no longer supported. On 3.0.20.1 with GStreamer 1.22 + Windows 11 + Octave I couldn't reproduce this with Intel graphics, don't have access to my Win10 machine with other graphics cards or Matlab atm. |
|
I'm not in the lab next week, but will test again the week after, with latest PTB |
|
I just tested with the latest 3.0.20.3, with MATLAB R2024b. The Windows build is 20348.2849 (21H2), still Windows server 2022 (so basically Windows 10). I get the same crash/hang in MATLAB, sadly again no traceback as Windows just closes the application after being non-responsive. I also tested on Octave 7.3, as that i think is the version you use? Anyway, same problem for me there too... |
|
Octave 7.3 is the only supported version atm., as later versions have bugs in their MinGW64 build/runtime system which prevent compiling of complex mex files like Screen. But this means it is not a Matlab problem. Does the same happen on other Windows machines or with the latest GStreamer versions? The only thing I can try is to see if it happens on my only Windows-10 machine, once I'm back at my flat. I can't think of a reason why switching to above normal priority would cause a crash though, especially after OpenMovie was already successful. |
|
It also happens with latest GStreamer (1.24.12). I got a stacktrace this time: |
|
Should be fixed in the just built Screen mex files in my master branch, if you want to test. |
|
Thanks for the investigation and fix! A working workaround for me has been to do this: dcnieho/Titta@f19f62b I am not sure if that makes sense given the results of your investigations, but it prevents the hang or crash on my machines. |
8000
|
I will test next week, when i am near the machines again |
|
The problem didn't happen during my tests with Windows 11, initially didn't
happen on Windows 10, but then happened consistently on both Octave and
Matlab in every run. Maybe some slightly different behaviour after Windows
bootup due to some background processing still running post-boot? I didn't
reboot the machine anymore, just put it to sleep overnight, as my machine
is so slow in booting Windows that it can take upwards of 45 minutes to get
a usable machine after powerup.
It also doesn't matter anymore if I do Priority(1) before or after
OpenWindow. It simply depends if, at the specific microsecond when
GStreamer/GLib creates some processing threads during startup and makes
them inherit the parent process priority, the priority level of the parent
thread - as dynamically selected by MMCSS depending on different factors -
is a level that is a valid parameter to SetThreadPriority() => All good, or
an invalid level => Crash/Hang. More specifically, GetThreadPriority()
returns the current level of the thread, as statically set via
SetThreadPriority() or dynamically selected by MMCSS if it is active, but
not all returned levels are actually valid input values to
SetThreadPriority(). GLib seems to assume that anything returned by
GetThreadPriority() for the parent thread is also a valid parameter for
SetThreadPriority() on the new GLib thread, and this is not the case.
Assuming MMCSS can dynamically adjust based on unknown factors, it would
explain why it sometimes work, but often not, or why it most of the time
crashes/hangs on my Windows 10 machine, but never crashed on my different
Window 11 hardware.
Assuming that GStreamer startup would be the only time when this can go
sideways, your workaround should be effective, and I thought about the same
thing as workaround inside PTB's Gstreamer startup code. But GStreamer
creates/destroys many threads in many cases, depending on what the exact
playback pipeline configuration is, and that also depends on both the
hardware in use (e.g., wrt. audio hardware / audio subsystem in use, and if
and what type of video hardware decoding/encoding acceleration is used),
which specific video/audio files with which codecs and properties are used,
and how the design of GStreamer changes. So I'm not sure if such a
workaround would only reduce the frequency or probability of such
crashes/hangs happening, or if it would fix them, or what a future
GStreamer version might do. Ergo I went for the more extensive option of
"once GStreamer is used even once in a session, permanently disable all
MMCSS scheduling for the main thread".
A proper solution would be to contribute improvements/fixes to GLib for
Windows to make that priority inheritance code MMCSS proof. But that is way
more work, and this one already took a whole weekend to track down and fix.
Maybe in the future...
…On Tue, Feb 25, 2025 at 9:57 AM Diederick C. Niehorster < ***@***.***> wrote:
Thanks for the investigation and fix! A working workaround for me has been
to do this: ***@***.***
<dcnieho/Titta@f19f62b>
I am not sure if that makes sense given the results of your
investigations, but it prevents the hang or crash on my machines.
—
Reply to this email directly, view it on GitHub
<#857 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIXMNWKPFSEAAM22LDIXAD2RQV6RAVCNFSM6AAAAABV7YZE5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGE4DQOBTGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: dcnieho]*dcnieho* left a comment
(Psychtoolbox-3/Psychtoolbox-3#857)
<#857 (comment)>
Thanks for the investigation and fix! A working workaround for me has been
to do this: ***@***.***
<dcnieho/Titta@f19f62b>
I am not sure if that makes sense given the results of your
investigations, but it prevents the hang or crash on my machines.
—
Reply to this email directly, view it on GitHub
<#857 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIXMNWKPFSEAAM22LDIXAD2RQV6RAVCNFSM6AAAAABV7YZE5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGE4DQOBTGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ok, i see. I guess i am getting lucky with the way i have been using it so far. I'll keep my workaround in place for now to reduce crashing/hanging chances and keep things running on older PTB that do not include your fix. Glad you have something more robust. Guess it'll have to stay this way anyway, unless it gets fixed in GLib at some point and you can detect whether a fixed version is used or not (sounds like a hassle). Thanks again! I'll test when i can and you'll hear back. |
|
I don't know if you are getting lucky, or if that workaround or fix would be perfectly sufficient and what I've implemented now is a bit of overkill. I just have no way to be sure that the simpler fix would be sufficient, so this is trading a bit of deterministic timing on MS-Windows for "peace of mind", and not having to spend multiple days on debugging again in the future. |
kleinerm
added a commit
that referenced
this issue
Mar 21, 2025
PTB Beta update 3.0.20.4 "Sleight of Hand" [This Psychtoolbox release was sponsored by Mathworks under the year 2024/2025 contract for significant enhancements, sponsoring the OpenXR hand tracking support as major new feature.](https://www.mathworks.com/solutions/neuroscience.html) ### Compatibility changes wrt. Psychtoolbox 3.0.20.3: - None. ### Highlights: - OpenXR articulated handtracking and fingertracking support for VR applications. Sponsored by Mathworks. ### All: - We now have OpenXR hand tracking support via our OpenXR driver, utilizing the XR_EXT_hand_tracking OpenXR extension! This works on Linux and Windows with any articulated hand tracking device that has suitable runtime support. Tested with Monado Mercury computer vision hand tracker and UltraLeap Leapmotion v2 vision based hand tracker on Linux Ubuntu 22.04/24.04 and on MS-Windows 10, both with Monado and SteamVR, Octave and Matlab. Thanks to Mathworks for sponsoring this work! - PsychLicenseHandling(): Refine auto download and install for LM client libs. - Various other smaller refinements, bug fixes and documentation updates. ### Linux: - Psychtoolbox was built and tested against Matlab R2024a and Octave 5.2 and later. - Our OpenXR VR/AR/MR/XR driver can now use articulated hand trackers to track a users hand and finger movements and configuration. Tested with a Ultraleap Leapmotion v2 controller under SteamVR and Monado runtimes with a real VR HMD and a simulated HMD, as well as under Monado with Monado's Open source Mercury hand tracker on a simulated NorthStar HMD and with a Luxonis W-Pro smart camera. ### Windows: - Psychtoolbox was built and tested against Matlab R2024a and Octave 7.3. - Screen(): Improve/Fix per-pixel alpha for onscreen window transparency, now also on Matlab, not just Octave! This used to work on WindowsXP, but got broken by some later version of MS-Windows. This change should fix it on Windows 10+, at least on the tested gpu's from Intel, AMD and NVidia. - Screen(): Whenever GStreamer is used, disallow MMCSS scheduling. This is a workaround for a GStreamer bug present since at least GStreamer 1.22. If `Priority(1)` was called in a script before `Screen('OpenMovie')` to enable Realtime scheduling, it would end with a crash during movie playback. See GitHub issue #857 reported by Diederick Niehorster for the background info. - Our OpenXR VR/AR/MR/XR driver can now use articulated hand trackers to track a users hand and finger movements and configuration. Tested with a Ultraleap Leapmotion v2 controller under SteamVR runtime with a real VR HMD. ### macOS: - Psychtoolbox was built and tested against native Matlab R2024a and against native Octave 9.4 from HomeBrew, on macOS 13.7.1 Ventura for Intel Macs, and on macOS 14.5 Sonoma for Apple Silicon Macs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I had crashes when running code of mine that played videos. I hunted it down to an issue that involved when Priority(1) is called relative to OpenWindow. This bug crashes matlab (almost always without a stack trace, but when i got one, it was deep inside GStreamer, don't remember the exact issue)
To Reproduce
Steps to reproduce the behavior:
SimpleMovieDemo.mPriority(1)afterScreen('OpenWindow', ...Priority(1)call beforeScreen('OpenWindow', ..., there is no crash.Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: