I've recompiled chuck with -g and it just gets stranger: with a construct along the lines of: fun void a() { <<< "in a before b" >>>; b(); <<< "in a after b" >>>; } fun void b() { <<< "entering b" >>>; ...do some stuff... <<< "exiting b" >>>; } There are no yields() that would let another process run in-between the call to b and returning to a, but it *sometimes* crashes after the return, so I see the equivalent of: "in a before b" "entering in b" "exiting in b" [crash] I'm seeing a "KERN_INVALID_ADDRESS" at a non-zero address, thrown from inside Chuck_Instr_Reg_Push_Imm::execute() I'm at a real loss how to tackle this one. Its part of a large body of code, so excerpting it down to a minimal example would be tough. Absent any suggestions from the Chuck wizards out there, I'm tempted to simply re-write my code in a different way and hope it makes a difference. But that's not my favorite approach. Suggestions more than welcome. - rdp On 23 May 2009, at 21:49, Tom Lieber wrote:

On Sun, May 24, 2009 at 12:36 AM, Robert Poor wrote:

...

(and do I need to recompile the sources with -g?)

Yeah, if you don't get filenames in gdb, you need to recompile with -g. I thought it did that by default... maybe it's inconsistently used across the makefiles?

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Tom: Good guess, but that doesn't seem to be the problem here. I found what tickled the bug and have worked around it, but I have no insights as the the cause: * In the crashing version, I was loading up a bunch of SndBuf objects (doing sndbuf.read(...)) early in the startup phase. * When I stopped pre-loading _all_ sndbufs, no crash. * When I pre-loaded _any_one_ sndbuf, crash (but randomly once in a dozen times executing the fun void a() code, etc). * When I moved the calls to sndbuf.read() to "load on demand just before using it", no crash. I need to point out that the place where the ChucK VM crashed had *nothing* to do with SndBufs -- lexically and temporally, the "fun void a()" code was far removed from any SndBuf code. The only thing that I can imagine is that ChucK has a thread internal to the VM which it uses for lazy reads, and it's somehow corrupting the stack. (???) Unfortunately, this is part of a large-ish real- time performance system. If someone really wants to debug this, contact me and I'll do what I can to trim it down to a minimum failing example. - Rob On 24 May 2009, at 05:37, Tom Lieber wrote:

On Sun, May 24, 2009 at 1:32 AM, Robert Poor wrote:

...

I've recompiled chuck with -g and it just gets stranger: with a construct along the lines of:

fun void a() { <<< "in a before b" >>>; b(); <<< "in a after b" >>>; }

fun void b() { <<< "entering b" >>>; ...do some stuff... <<< "exiting b" >>>; }

There are no yields() that would let another process run in-between the call to b and returning to a, but it *sometimes* crashes after the return, so I see the equivalent of:

"in a before b" "entering in b" "exiting in b" [crash]

I'm seeing a "KERN_INVALID_ADDRESS" at a non-zero address, thrown from inside Chuck_Instr_Reg_Push_Imm::execute()

I'm at a real loss how to tackle this one. Its part of a large body of code, so excerpting it down to a minimal example would be tough. Absent any suggestions from the Chuck wizards out there, I'm tempted to simply re-write my code in a different way and hope it makes a difference. But that's not my favorite approach.

Suggestions more than welcome.

Well, the only non-bus-error of ways to crash ChucK I'm familiar with is to use variables before their definition in a way the compiler doesn't catch. Liiike:

fun void a() { b(); } a(); int v[1]; fun void b() { <<< v[0] >>>; }

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

--: Robert Poor e: robert.poor@nbt-ventures.com p: +1 617 818 5115 b: http://blog.nbt-ventures.com --: This message and the information it contains are the proprietary and confidential property of NBT Ventures and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. --: