Giving jit.grab the message “getformatlist” will crash Max (on Mac) if the USB camera is unplugged
Giving jit.grab the message “getformatlist” (to get the list of resolution formats supported by a camera) will crash Max (on Mac) if the USB camera was unplugged. (working under Catalina 10.15.4 and Max 8.1.3 [da28f19] but I also have the same problem on Max 8.1.4).
To reproduce the problem easily: Plug in any USB camera in your Mac open the help file for jit.grab, click on the “open” message and turn on qmtero (to turn the camera on), then click on “getvdevlist” to populate the vdev umenu, then click on “getformatlist” to popular ethe format umenu. Now unplug the camera and click on “getformatlist” again and Max will crash.
The crash report (relevant section) is attached. Most relevant is the line "1 com.cycling74.jit.avf.engine 0x000000019356a860 jit_grab_getformatlist + 27"
This seems to be a bug. Is there a fix in the pipeline? Any ideas on how to go around it would be appreciated. I am developing a standalone that requires querying cameras for their resolution formats. A crash is an ungraceful way to deal with an unplugged camera.
Thanks,
Adam
_____________________Crash Report______________________
Process: Max [4385]
Path: /Applications/Max.app/Contents/MacOS/Max
Identifier: Max
Version: 8.1.3 [da28f19] (8.1.3)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Max [4385]
User ID: 509
Date/Time: 2020-05-28 15:44:28.907 -0400
OS Version: Mac OS X 10.15.4 (19E287)
Report Version: 12
Bridge OS Version: 4.4 (17P4281)
Anonymous UUID: 8C6D815B-614D-EDAB-709E-C67158A4A350
Time Awake Since Boot: 8100 seconds
System Integrity Protection: enabled
Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [4385]
VM Regions Near 0x8:
-->
__TEXT 000000010d8f5000-000000010e539000 [ 12.3M] r-x/rwx SM=COW /Applications/Max.app/Contents/MacOS/Max
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 com.cycling74.JitterAPIImpl 0x000000011c8f42db bm_grab_getDisplayModeNames + 10
1 com.cycling74.jit.avf.engine 0x000000019356a860 jit_grab_getformatlist + 27
2 com.cycling74.Max 0x000000010da1f9de object_method_typedfun + 120
3 com.cycling74.MaxAPIImpl 0x00000001118c20c7 object_method_typed + 71
4 com.cycling74.JitterAPIImpl 0x000000011c8b6f0e max_jit_obex_gimmeback_dumpout + 78
5 com.cycling74.JitterAPIImpl 0x000000011c8ba418 max_defer_low_method + 136
6 com.cycling74.Max 0x000000010d933bb8 typedmess_fun + 216
7 com.cycling74.Max 0x000000010d9c78f1 outlet_anything + 627
8 com.cycling74.Max 0x000000010d933bb8 typedmess_fun + 216
9 com.cycling74.Max 0x000000010d93484b aeval + 1427
10 com.cycling74.Max 0x000000010d906b0c atombuf_eval + 132
11 com.cycling74.message 0x000000019272b863 jmessage_atombuf_eval + 316
12 com.cycling74.message 0x0000000192729f9b jmessage_mousedown + 175
13 com.cycling74.Max 0x000000010da7b11c BoxComponent::sendMouseMessage(juce::MouseEvent const&, symbol*) + 582
14 com.cycling74.Max 0x000000010da7be9e BoxComponent::mouseDown(juce::MouseEvent const&) + 934
15 com.cycling74.Max 0x000000010e14ce41 juce::MouseInputSourceInternal::setButtons(juce::Point<float>, juce::Time, juce::ModifierKeys) + 2513
16 com.cycling74.Max 0x000000010e1576ed juce::ComponentPeer::handleMouseEvent(juce::MouseInputSource::InputSourceType, juce::Point<float>, juce::ModifierKeys, float, float, long long, juce::PenDetails, int) + 717
17 com.cycling74.Max 0x000000010e157376 juce::NSViewComponentPeer::sendMouseEvent(NSEvent*) + 310
18 com.cycling74.Max 0x000000010e150fac juce::JuceNSViewClass::mouseDown(objc_object*, objc_selector*, NSEvent*) + 236
19 com.apple.AppKit 0x00007fff2f4c9280 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4914
20 com.apple.AppKit 0x00007fff2f433a81 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2612
21 com.apple.AppKit 0x00007fff2f432e29 -[NSWindow(NSEventRouting) sendEvent:] + 349
22 com.apple.AppKit 0x00007fff2f4311b4 -[NSApplication(NSEvent) sendEvent:] + 352
23 com.cycling74.Max 0x000000010dc6ad6d swizzle_SendEvent(objc_object*, objc_selector*, NSEvent*) + 109
24 com.apple.AppKit 0x00007fff2f27e21f -[NSApplication run] + 707
25 org.chromium.ContentShell.framework 0x0000000114cad6ac 0x112519000 + 41502380
26 org.chromium.ContentShell.framework 0x0000000114cac1d8 0x112519000 + 41497048
27 org.chromium.ContentShell.framework 0x0000000114cf97b8 0x112519000 + 41813944
28 org.chromium.ContentShell.framework 0x0000000114ccea57 0x112519000 + 41638487
29 org.chromium.ContentShell.framework 0x00000001149dbf50 0x112519000 + 38547280
30 com.cycling74.Max 0x000000010dc7eb1e MaxCefEventLoopHandler::runMessageLoop() + 18
31 com.cycling74.Max 0x000000010e057d46 juce::JUCEApplicationBase::main(int, char const**) + 246
32 libdyld.dylib 0x00007fff6bf57cc9 start + 1
thanks for the report, i'll take a look.
Thank you Rob. Anxious to see you what you find.
hi Adam. I can't reproduce with a USB cam. Is there any other info about your setup? Are you using a Blackmagic capture card?
Hi Rob,
Thanks for checking into this .
The crash occurs consistently on all 5 Macs I have, which include 3 MacBook Pros (2012, 2017 and 2020) and 2 Mac minis (late 2012 and 2018). I do not know what graphics card these Macs use (I can find out if necessary) but none of these Macs have been modified (i.e. they all have their native graphics cards).
Regards,
Adam
Hi Adam, my question was regarding video capture cards that you may be using, not graphics cards. From the crashlog it looks like you are maybe using a Blackmagic device.
In any case please send along the patch you are using, and the camera details, as well as any other relevant specs (such as capture card, if indeed you are using one).
Thank you Rob for clarifying.
The crash occurs with all the USB cameras I used, which include the Logitech C270, C920, and C930e webcams, as well as a few lesser known cameras, to which I can send you links, but the Logitech cameras are the most popular and they all cause the crash if jit.grab gets the "getformatlist" message after the camera was unplugged.
The crash occurs 100% of the times using the jit.grab help file patch. My patch (which is huge and relies on too many externals to work and send, and set up) uses a very similar object configuration as the jit.grab. Since the problem occurs with the jit.grab help file patch there should be no need to send you my patch, especially since the crash report I quoted above was obtained using the jit.grab help file and not my patch.
Thank you so much for looking into this.
Regards.
Adam
thanks for persisting. finally managed to reproduce the crash on the 3rd machine i tried. It's now fixed up and will be in the next update. In the meantime if you'd like to test out the fix, I'd appreciate it.
Simply right-click, show package contents on the Max.app and navigate to Contents/Resources/C74/externals/jitter/
overwrite the existing jit.avf.engine.mxo with the one in this zip:
Rob,
I got a somewhat similar issue on my Windows 10/Max8.1.4 machine and a Magewell PCIe capture card, where "getformatlist" always leads to a crash, Magewell card stays attached. Using "format" I am able to select a working format.
Maybe your fix is related to that as well and I would be happy to give it a try on a Windows machine.
Ed
I also have similar issue, but no crash. " getformatlist " just doesn't output anything
Windows 10 / max 8.1.4. No capture card, just webcam.
Also, same, using (format $1) works
Yoann and Ed, this fix is only related to the Mac driver so would not affect windows. Please file a support ticket with your issues so our Windows support team can get it logged and try and reproduce.
Thank you Rob, I have downloaded the new jit.avf.engine.mxo and I will test it shorty and report back on this forum.
Your quick attention and efforts are much appreciated.
Hi Rob, I tested the new jitter external and the problem is gone.
Thank you so much!
Hi Rob, the new jit.avf.engine.mxo you posted is not code-signed. When I tried to notarize my standalone that uses this latest version the notarization failed. Could you please post a code-signed version.
Thanks.
Adam
hi Adam, please give the 8.1.5 update a try.
Hi Rob,
I tried 8.1.5 and I am sorry to report that I had a big problem with it: My main maxpat file for my standalone (which is a very complex patch that calls many externals and contains thousands of objects and hundreds of subpatches) which was working perfectly with Max 8.1.4 gets hung up upon launch. I get the dreaded beachball, the patch is frozen, and nothing happens indefinitely. After many trials, I gave ups and ran back to 8.1.4.
I did however copy jit.avf.engine.mxo from 8.1.5 into 8.1.4 and all is working (no crash induced by a getformatlist call to unplugged USB camera). Since this version of jit.avf.engine.mxo is code signed, I expect not to have any problems notarizing the standalone.
I kept a zipped version of Max 8.1.5 in case you wish me to run some tests to find out what may be happening. I do not have a crash report since Max froze up and did not crash.
Regards,
Adam
hi Adam. I would recommend trying again with 8.1.5 as it fixes a handful of bugs introduced in 8.1.4. I would let it launch fully first, and let the database finish rebuilding (you can check the activity monitor and see when i quiets down) before launching your patch.
If you are still unable to launch without hangs, please get in touch with support, otherwise there is no way we'll be able to get to the bottom of this.
Thank you Rob for the instructions. I launched Max 8.1.5 and monitored its CPU load on Activity Monitor. It shot up to above 100% than after about a minute it dropped and idled at about 1%. I closed it and launched it again a few times and each time it shot up to about 60% for a couple of seconds then dropped and idled at about 1%. I then tried to open my patch from within Max after it idled, but it hung up and froze. I waited more than 15 minutes to no avail. I repeated with launching Max by clicking on the patch and the same thing happened. When I force quitted it I got a report. I am attaching this "hang report", in case something seems obvious to you before I get in touch with support.
Thanks,
Adam
Hi Rob,
Update: I was able to isolate the culprit (a small sub-patch) which causes the freeze in 8.1.5 (but not 8.1.4). I will now look for the exact cause in that sub-patch and report back. Please ignore the previous message.
Hi Rob, I traced the cause of the freeze to the different behavior pattrstorage has in 8.1.4 and 8.1.5. I had set a few actions/measures to deal with how pattrstorage saves and recalls settings in 8.1.4 but it looks like 8.1.5 is handling pattrstorage more correctly and these actions/measures, now superfluous, were causing the freeze (too complicated to explain in detail). The bottom line is that all seems to be fine now with 8.1.15 and I will stick with it.
Thank you.