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

[Jonatan Liljedahl <lijon@xxxxxxxxxxxx>]

Also interesting:

(
f = { |x,g|
    g.()
};

f.(2,{ var abc = "this";

f.(42,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{
f.(2, { "abc is %".format(abc).postln; 3})})})})})})})})})})})})})})})
)

abc is 42
3

So then we know which frame the value is coming from.

Also, with Main.tailCallOptimize = false, I get random results.

On Wed, Nov 20, 2013 at 4:18 PM, James Harkins <jamshark70@xxxxxxxxx> wrote:
> On Nov 20, 2013 7:06 PM, "Miguel Negrão"
> <miguel.negrao-lists@xxxxxxxxxxxxxxxxx> wrote:
>> I'm afraid I can't help much at all, but just so you feel less lonelly,
>> I was at some point getting similar behaviour from sclang. At some point
>> the same variable, without being changed, would output completelly
>> random results.
>>
>> https://github.com/supercollider/supercollider/issues/999
>
> This sounds related. My code is racking up some quite deep stack traces,
> dispatching OSC messages through multiple Protos, often by way of
> NotificationCenter. Proto is especially demanding on the stack, since
> pseudo-method dispatch through doesNotUnderstand "use"-s the Proto,
> incurring frames for protect and prTry. Multiple layers of notifications are
> involved as well. It wouldn't surprise me if the stack approached a hundred
> frames.
>
> So the million dollar question is: Does anybody know enough about this to
> trace it in gdb and check the state of the stack? I sure don't.
>
>> Stating the obvious, indeed one of the advantages of using a mainstream
>> language is that you have people that can look into this sort of stuff
>> that know exactly what is going on, freeing the sc developers to focus
>> on the musical aspect of things. But then again, I'm afraid there will
>> never be consensus on a language... sclang is kind of the glue that
>> keeps us together, for the better or worse ;-)
>
> I guess, it's "whose consensus." I could go with ruby, lua or Haskell (with
> Haskell being the least likely to gain traction among the user base as a
> whole).
>
> hjh



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