lcd multi-threading crashes
It seems that the sprite handling in lcd is not thread safe. The simple patch below that frantically recreates the same sprite and tries to draw it from different threads crashes eventually, sometimes just when trying to go in and out of edit mode, e.g. like this:
Thread 0:
0 com.cycling74.MaxMSP 0x0002d4ef lockout_set + 1
1 com.cycling74.MaxMSP 0x0002fca5 dofreebytes(char*, short) + 75
2 com.cycling74.MaxMSP 0x0002de91 sysmem_freeptr + 51
3 com.cycling74.MaxAPI 0×04141071 sysmem_freeptr + 31
4 com.cycling74.lcd 0x1c28ba9b lsd_deletesprite + 168
5 com.cycling74.lcd 0x1c28bb0a lsd_doclosesprite + 96
Thread 1 Crashed:
0 com.cycling74.lcd 0x1b5859cd spritelem_free + 21
1 com.cycling74.lcd 0x1b585a9b lsd_deletesprite + 168
2 com.cycling74.lcd 0x1b585b0a lsd_doclosesprite + 96
Thread 0 Crashed:
0 com.cycling74.lcd 0x1a192285 lsd_drawloop + 46
1 com.cycling74.lcd 0x1a18ce9d lsd_drawsprite_cb + 200
2 com.cycling74.MaxMSP 0x0005c27a linklist_funall + 68
3 com.cycling74.MaxAPI 0x041470ad linklist_funall + 45
4 com.cycling74.lcd 0x1a18cd5c lsd_paint + 2272
I’m on Max 5.1.4, Mac OS 10.5.8 and here is the patch:
Sadly, the 5.1.5 update didn’t fix this crash.
Could we get a timeframe or at least an acknowledgement, please?
Best, Diemo
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000458b18f4 Crashed Thread: 0 Thread 0 Crashed: 0 com.cycling74.lcd 0x1bbc9285 lsd_drawloop + 46 1 com.cycling74.lcd 0x1bbc3e9d lsd_drawsprite_cb + 200 2 com.cycling74.MaxMSP 0x0005bca8 linklist_funall + 68 3 com.cycling74.MaxAPI 0x026fef91 linklist_funall + 45 4 com.cycling74.lcd 0x1bbc3d5c lsd_paint + 2272 5 com.cycling74.MaxMSP 0x0010b481 BoxComponent::paint(juce::Graphics&, juce::AffineTransform const&) + 1545 6 com.cycling74.MaxMSP 0x001d790d ZoomableComponent::paint(juce::Graphics&) + 43 7 com.cycling74.MaxMSP 0x002f668f juce::Component::paintEntireComponent(juce::Graphics&) + 555 8 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 9 com.cycling74.MaxMSP 0x001bc1e8 PatcherLayerComponent::paintEntireComponent(juce::Graphics&) + 80 10 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 11 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 12 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 13 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 14 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 15 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 16 com.cycling74.MaxMSP 0x002f68a9 juce::Component::paintEntireComponent(juce::Graphics&) + 1093 17 com.cycling74.MaxMSP 0x0038ef90 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 48
Haven’t been able to reproduce the crash as of yet in 10.6 or 10.5.
Perhaps if you describe what you’re going for, we can try to help you find a way to patch it that would have a better chance at minimizing event backlog.
Hello maxers,
i had crashes with [lcd] when i test my [yankee] external with really high (and stupid) flow of messages to [lcd] ; i tried to reproduce the crash without my external ; but i couldn’t ; maybe it is qelem specific as when i reproduce the patch without [yankee] (but using [defer]) it didn’t crash but seems to store messages in memory as [lcd] continued to draw stuff during almost ten seconds – while i stopped the [metro] – …
not very clear but HTH
I have never posted on these forums before, but I have found them a useful source of information. I hope this is useful to someone else.
This post is intended for someone struggling with crashes in heavy-duty high-performance use of the LCD.
I am working on a LCD display for Midi data coming from a Continuum Fingerboard. (This is part of the Continuum Editor max program’s next release.) There can be a whole lot of Midi data from the Continuum, resulting in lots of drawing in the LCD. I need a snappy display, else people will think it’s the Continuum or Midi that is slow. It was easy to use the LCD to make a nice snappy display, but after minutes or hours of playing Continuum the LCD crashed in a way similar to Diemo Schwartz’s posting. If I slowed down the rate of data going to the LCD I could avoid crashes, but the display was too sluggish.
After trying many things, I came up with this solution that never crashes and has every fast updates:
(1) After drawing updated graphics for a Midi channel (the Continuum assigns each simultaneous finger is its own Midi channel), send the LCD a getpenloc. Increment a counter whenever a getpenloc is sent to the LCD.
(2) Every time the LCD responds with a penloc, decrement the counter.
(3) Do not draw new updates if there are too many outstanding getpenloc responses. I got snappy display (without crashes) by limiting it to 3 outstanding getpenloc responses.
The following are small excerpts of a large max program. The first is part of the formatting of the messages going to the LCD. The second has LCD getpenloc response processing in the upper left.