scope buffer allocation problem

[timblechmann]

evaluating this code triggers a bug in the scope buffer allocation:

s.boot

s.freqscope
s.reboot

{SinOsc.ar * -30.dbamp}.scope

the freqscope is shown in the scope window and this error message is posted:

ScopeOut2: Requested scope buffer unavailable! (index: 0, channels: 1, size: 4096)

[telephon]

I can't reproduce this problem with the current build on OSX.
However, putting the computer to sleep with the freqscope window open, and then doing a scope again crashes the interpreter:

Date/Time:       2013-08-17 09:33:38.067 +0200
OS Version:      Mac OS X 10.8.4 (12E55)
Report Version:  10
Sleep/Wake UUID: 9F7A3545-18A6-46EF-B527-041030B88558

Interval Since Last Report:          406067 sec
Crashes Since Last Report:           36
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      D9526E62-A120-F61E-8E9B-4EA4E7A70E63

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000011a36f5b0

VM Regions Near 0x11a36f5b0:
    mapped file            0000000119364000-0000000119b64000 [ 8192K] rw-/rwx SM=ALI  /private/tmp/*
--> 
    CG shared images       000000012ed59000-000000012ed61000 [   32K] r--/r-- SM=SHM  

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   sclang                          0x00000001054dbdda QcScopeShm::paint1D(bool, int, int, int, QRect const&, QPainter&) + 1418 (QcScopeShm.cpp:242)
1   sclang                          0x00000001054db7cc QcScopeShm::paintEvent(QPaintEvent*) + 188 (QcScopeShm.cpp:167)
2   QtGui                           0x000000010803a606 QWidget::event(QEvent*) + 2294
3   QtGui                           0x0000000107fe293d QApplicationPrivate::notify_helper(QObject*, QEvent*) + 189
4   QtGui                           0x0000000107fe8dc4 QApplication::notify(QObject*, QEvent*) + 1060
5   sclang                          0x00000001054a6801 QcApplication::notify(QObject*, QEvent*) + 177 (QcApplication.cpp:146)
6   QtCore                          0x0000000108f2a17c QCoreApplication::notifyInternal(QObject*, QEvent*) + 124
7   QtGui                           0x0000000108037fae QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 1822
8   QtGui                           0x0000000108038a24 QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 1460
9   QtGui                           0x00000001080388e5 QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 1141
10  QtGui                           0x00000001080388e5 QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 1141
11  QtGui                           0x0000000108037d40 QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 1200
12  QtGui                           0x0000000107f877ea -[QCocoaView drawRect:] + 1786
13  com.apple.AppKit                0x00007fff8985d064 -[NSView _drawRect:clip:] + 4217
14  com.apple.AppKit                0x00007fff8985b6c1 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1656
<...>

[timblechmann]

@telephon please (a) markdown-format backtraces and (b) file a separate bug as this does not seem to be related.

in general, sleeping while the synthesis can cause a lot of undefined behavior

[telephon]

On 17.08.2013, at 11:18, Tim Blechmann notifications@github.com wrote:

@telephon please (a) markdown-format backtraces and

how should they be formatted?

(b) file a separate bug as this does not seem to be related.

are you sure? If you are sure, I can do so.

in general, sleeping while the synthesis can cause a lot of undefined behavior

It definitely should not, at least on OS X.
So far you could always safely sleep even in or before concerts.

[muellmusik]

On 17 Aug 2013, at 20:05, Julian Rohrhuber notifications@github.com wrote:

in general, sleeping while the synthesis can cause a lot of undefined behavior

It definitely should not, at least on OS X.
So far you could always safely sleep even in or before concerts.

Yes, that would certainly seem like a serious regression. Users will reasonably expect all software, on all platforms, to sleep without crashing.

[jleben]

I can't reproduce this issue either, on Linux. Tim, on which git branch/revision is this?

I've seen this issue due to Julian Rohrhuber's commit 253b99c which caused problems in node.free. This commit has since been reverted, and the functionality implemented in a different manner (by Tim).

Unfortunately the latest released 3.6 version still contains the regression!! (We really need to make another bugfix release!!)

[timblechmann]

it is on master, 10ef043. and i can reproduce it with both scsynth and supernova.

[telephon]

On 18.08.2013, at 23:03, Jakob Leben notifications@github.com wrote:

I've seen this issue due to Julian Rohrhuber's commit 253b99c which caused problems in node.free. This commit has since been reverted, and the functionality implemented in a different manner (by Tim).

I don't see how this could be connected. I still don't understand the revert btw (but I trust you).

[timblechmann]

@telephon you deferred the free command. this means that if you depend on the sequence free->new, you are screwed. that commit caused the problem that the scope buffer descriptor could not be allocated by a new synth, because the old synth was not freed.
btw, this was a subtle but very annoying bug, which took jakob and me several hours to track down.

[telephon]

On 18.08.2013, at 23:50, Tim Blechmann notifications@github.com wrote:

@telephon you deferred the free command. this means that if you depend on the sequence free->new, you are screwed. that commit caused the problem that the scope buffer descriptor could not be allocated by a new synth, because the old synth was not freed.
btw, this was a subtle but very annoying bug, which took jakob and me several hours to track down.

Thanks for the explanation. I'd like to understand: I was making sure that the free command is processed exactly at the time scheduled and not some unknown time. Why weren't you just using a new synth with a different ID? I can imagine that it was hard to track down. Maybe it is an ok solution, but it seems a little bit like duck tape. If you want to be certain that one synth is started after the other is freed, you can use the onFree message.

[timblechmann]

scope buffers have a language side and a server side (and shared memory in between). so one would also have to re-assign a new scope buffer id for the widget.

but in general, it is more about sequential consistency. if use code does something like:

aNode.free;
aNewNode = Synth(...);

the events should not be reordered. so in this case the correct fix was not to defer the n_free command, but to ensure that it is using the same dispatch mechanism as s_new to ensure sequential consistency.

[telephon]

This makes sense. However, looking at the patch: #253b99c
This behaviour was not changed, the bundle option remaining an option.
Using bind seems a little unwieldy, but sure, it does work.

[timblechmann]

f939dc2 is my fix (btw # references issues, just paste the commit hash and github will generate the lin)

[telephon]

Fix f939dc2 has been pushed, but this seems unrelated to the current issue (#937)?
But according to jleben, this has been fixed?

[telephon]

Seems to be fixed.