[sc-dev] Re: Still occasional memory corruption...

[James Harkins <jamshark70@xxxxxxxxx>]

On Tuesday, November 19, 2013 10:42:48 PM HKT, James Harkins wrote:
> Sorry to report that I'm seeing some sporadic (very sporadic) 
> memory corruption problems again. It doesn't happen very often, 
> but when things get complicated, it does still pop up.

Naturally, this is only getting worse, just two days before a show.

In the last 40 minutes, I've gotten:

- ERROR: Message 'add' not understood.
RECEIVER:
Instance of TempoClock {    (0x588d398, gc=E4, fmt=00, flg=00, set=03)
 instance variables [7]
   queue : instance of Array (0x2945580, size=4, set=8)
   ptr : RawPointer 0x7fbed4000a20
   beatsPerBar : Integer 3
   barsPerBeat : Float 0.333333   55555555 3FD55555
   baseBarBeat : Float 0.000000   00000000 00000000
   baseBar : Float 0.000000   00000000 00000000
   permanent : false
}

.. when I haven't written any "add" calls against TempoClock. Further, if 
I unload the piece (without recompiling the class library), load it again 
and take exactly the same actions, then there probably won't be any error. 
If it works most of the time, then I think it's extremely doubtful that I 
wrote anything to issue this call.

Sure, there's random number generation in my piece, but that's rather a 
different sort of indeterminacy from this...

- Multiple sclang crashes while loading resources. When I tried to 
reproduce the problem in gdb, of course it didn't crash. Now it seems hard 
to reproduce from scide as well. What's different about my last report is 
that these crashes are occurring *early* in the session.

I'm on master, but I didn't update anything for at least the last month 
(since, a month ago, I was preparing for concerts in Beijing and Seoul).

Things like this make me want to quit using SuperCollider. It's really not 
fun to go into a performance situation with no confidence that the tool 
will remain stable. The problem is... there's nothing else that will come 
close to letting me do the kinds of things I want. Don't really have 
another choice.

I can hardly wait for a version where we cut out all the garbage and bloat 
and return SC to a clean, lean, efficient state. "Wouldn't it be nice if we 
had...?" NO, it would NOT be nice if it makes things more prone to crash.

Grr.

hjh

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/