Diemo Schwarz

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:

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     0x04141071 sysmem_freeptr + 31

4 com.cycling74.lcd     0x1c28ba9b lsd_deletesprite + 168

5 com.cycling74.lcd     0x1c28bb0a lsd_doclosesprite + 96

0 com.cycling74.lcd     0x1b5859cd spritelem_free + 21

1 com.cycling74.lcd     0x1b585a9b lsd_deletesprite + 168

2 com.cycling74.lcd     0x1b585b0a lsd_doclosesprite + 96

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:

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          	0x04141071 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:


lcd-multi-threading-crashes

Sadly, the 5.1.5 update didn't fix this crash.

Could we get a timeframe or at least an acknowledgement, please?

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



Sadly, the 5.1.5 update didn't fix this crash.  

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.

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.


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. 

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.

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.  


lcd multi-threading crashes