[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
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.



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/