Is this a familiar or unfamiliar type of stack corruption?

Development
1

I seem to have evidence of a stack corruption here? Sporadic, of course. The same action, performed a second time, triggered no error.

At ArrayedCollection:do, the ‘function’ is { |item, i| this.put(i, function.value(item, i)) } – this should be the same in the do method as it is in the function. But, magically, inside the function, this has become the array index = 1 (and I have no idea what the clock is doing in there).

Just noting…? No idea how to research it.

ERROR: Message 'put' not understood.
Perhaps you misspelled 'pow', or meant to call 'put' on another receiver?
RECEIVER:
   Integer 1
ARGS:
Instance of TempoClock {    (0x5fdd843b4d08, gc=5C, fmt=00, flg=00, set=03)
  instance variables [7]
    queue : instance of Array (0x5fdd83137ec0, size=19, set=11)
    ptr : RawPointer 0x5fdd83a022b0
    beatsPerBar : Float 4.000000   00000000 40100000
    barsPerBeat : Float 0.250000   00000000 3FD00000
    baseBarBeat : Float 0.000000   00000000 00000000
    baseBar : Float 0.000000   00000000 00000000
    permanent : true
}
   nil

PROTECTED CALL STACK:
	Meta_MethodError:new	0x5fdd849f0800
		arg this = DoesNotUnderstandError
		arg what = nil
		arg receiver = 1
	Meta_DoesNotUnderstandError:new	0x5fdd849f2b40
		arg this = DoesNotUnderstandError
		arg receiver = 1
		arg selector = put
		arg args = [ a TempoClock, nil ]
	Object:doesNotUnderstand	0x5fdd83d55c80
		arg this = 1
		arg selector = put
		arg args = nil
	ArrayedCollection:do	0x5fdd85fc1900
		arg this = [ an OSCMessageDispatcher, a Function ]
		arg function = a Function
		var i = 1
	Collection:collectInPlace	0x5fdd85f4c140
		arg this = [ an OSCMessageDispatcher, a Function ]
		arg function = a Function
	FunctionList:value	0x5fdd84dadb40
		arg this = a FunctionList
		arg args = nil
		var res = [ [ /button_10, 0.0 ], 1722.372526787, a NetAddr(127.0.0.1, 8080), 57120 ]
	Main:recvOSCmessage	0x5fdd84676600
		arg this = a Main
		arg time = 1722.372526787
		arg replyAddr = a NetAddr(127.0.0.1, 8080)
		arg recvPort = 57120
		arg msg = [ /button_10, 0.0 ]

hjh

2

Doesn’t look good :confused: It would be great if you have some code to share that can reproduce this reliable so it can be inspected further on the C++ side as well, but it seems this only comes up occasionally?

The clock could be a hint to some quirky thread-issue - but it would be strange if this would only popped up now? Maybe you found an interesting edge-case?

3

Unfortunately it’s in a response to an Open Stage Control button, in stable code that I’ve been using for, oh, 8+ years now? And normally never throws an error.

The button is calling “stop” on a process – this does use the clock, but shouldn’t return the clock.

It’ll probably never happen again. Just… weird.

hjh

4

FWIW the random failures in the test suite sometimes look similar… maybe?
E.g. LinkClock tests sometimes fail · Issue #5421 · supercollider/supercollider · GitHub

When I was looking into this, I was sometimes able to reproduce the issues if I ran the test with all the CPUs being under 100% artificial load. @jamshark70 can you try running your code with all CPUs under stress to see if that allows the error to be recreated?

5

I’ve often seen unexpected clocks when you read past the end of the stack. It might have something to do with thread creation requiring a lot of stack space? But that’s just speculation.

If you change the methods to capture this in a variable outside the function, does this change the error?

E.g.,

var fakeThis = this;
blah.do { fakeThis.use }

What version, os, and hardware is this on?