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

[Jonatan Liljedahl <lijon@xxxxxxxxxxxx>]

Regarding SC4, I think this is another demonstration of why it would
be good to use an existing language implementation instead. sclang has
hard-to-find bugs, and no one understands all the internals.

On Wed, Nov 20, 2013 at 10:33 AM, James Harkins <jamshark70@xxxxxxxxx> wrote:
> 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/



-- 
/Jonatan
http://kymatica.com

_______________________________________________
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/