Re: [chuck-users] Debugging Segmentation fault: 11

Ah - very cool, Rob! I'll look into turning these on for our continuous integration unit tests. mc On Tue, Jan 27, 2015 at 6:30 PM, Robert Poor wrote:

On OS X, I found the following to be really handy:

https://developer.apple.com/library/mac/documentation/Performance/Conceptual...

so you can do things like:

$ gdb chuck (gdb) set env MallocGuardEdges 1 (gdb) run

Setting MallocGuardEdges, MallocScribble and MallocPreScribble might cause ChucK to get a segfault sooner. Then you print a backtrace by doing:

(gbd) bt

and send the results to Spencer for post mortem!

HTH...

- Rob

On Tue Jan 27 2015 at 6:20:49 PM Spencer Salazar < spencer@ccrma.stanford.edu> wrote:

...

+1 for gdb. If I were able to see a stack trace with function names (I think after it crashes in gdb, enter the 'backtrace' command) that would help a lot as far as pinpointing whatever in your ChucK code is triggering the crash.

spencer

On Tue, Jan 27, 2015 at 2:39 PM, Joel Matthys wrote:

...

Oh yeah! I had forgotten about ConsoleInput. (It's undocumented and I think it's generally considered archaic.) I know some early SLorK/PLorK pieces used Tcl/Tk GUIs outputting control numbers piped into ChucK. So I'm sure it's valid code, but I don't know how to debug it with GDB.

Joel

On 01/27/2015 04:33 PM, Gonzalo wrote:

...

This was a suggestion by Perry Cook, it's in chuck-users in a thread called "timestamps", Dec 14. The essence is:

ConsoleInput stdin; // gonna read from here stdin.prompt("") => now; // wait until something comes in while (stdin.more()) { stdin.getLine() => ... } // read input

(fully working code in his post)

I'll try your way to see if I can do this with gdb. Thanks!

On 28/01/2015 9:21 am, Joel Matthys wrote:

...

Hmm... I've never piped anything into ChucK like that before. How does ChucK access the timestamp?

Typically I would do something like that with an argument:

chuck wp.ck:`date +"%y%m%d-%T"`

and then access it in ChucK with me.arg(0) => string timestamp;

Joel

On 01/27/2015 03:27 PM, Gonzalo wrote:

...

Thanks Joel. One more hiccup: I start my chuck program with:

date +"%y%m%d-%T" | chuck wp.ck

(I need it to have a timestamp)

But I can't do that in gdb. I can disable the timestamp part in the code, but just checking to see if this is possible.

On 28/01/2015 8:01 am, Joel Matthys wrote:

> I assume you're on Linux or OSX. (If it's Windows, I'm clueless.) > > For me on Ubuntu I type: > > $ *gdb chuck* > > and then once it starts up and I get the (gdb) prompt I type: > > (gdb) *run my_chuck_file.ck* > > Of course GDB slows down your system, A LOT, but you can keep it > running > until it hits the segfault. The spew should (hopefully) point toward > a > specific place in the chuck code that is the problem. (Type q to exit > gdb.) You might want to copy the error messages here for the devs to > look into. > > Joel > > On 01/27/2015 02:53 PM, Gonzalo wrote: > >> Never used gdb before, I'll read about this, but any pointers on how >> to get started? >> >> >> On 28/01/2015 7:39 am, Joel Matthys wrote: >> >>> It's hard to debug segfaults in the ChucK code itself. running gdb >>> chuck >>> might help narrow down the problem. >>> >>> Joel >>> >>> On 01/27/2015 02:31 PM, Gonzalo wrote: >>> >>>> Hi, >>>> >>>> On a project I'm working on, I sometimes get a "Segmentation >>>> fault: >>>> 11" error, and the program crashes. But I can't figure out when it >>>> happens, and cannot reproduce it. It's a big project, with many >>>> components communicating via events, and I have no idea who's >>>> triggering the problem. My question is how would you go about >>>> debugging this? Any ideas what can be triggering it? It sounds >>>> very >>>> generic... >>>> >>>> Probably unrelated, but just in case, I also got this (only once >>>> so >>>> far): >>>> >>>> chuck(22226,0x7fff790ee310) malloc: *** error for object >>>> 0x1028f3408: >>>> incorrect checksum for freed object - object was probably modified >>>> after being freed. >>>> *** set a breakpoint in malloc_error_break to debug >>>> Abort trap: 6 >>>> >>>> Thanks! >>>> Gonzalo >>>> _______________________________________________ >>>> chuck-users mailing list >>>> chuck-users@lists.cs.princeton.edu >>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>> >>> >>> _______________________________________________ >>> chuck-users mailing list >>> chuck-users@lists.cs.princeton.edu >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >>> _______________________________________________ >> chuck-users mailing list >> chuck-users@lists.cs.princeton.edu >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >> > > > > _______________________________________________ > chuck-users mailing list > chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University

spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users