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 <[email protected]> wrote: > On OS X, I found the following to be really handy: > > > https://developer.apple.com/library/mac/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html > > 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 < > [email protected]> 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 <[email protected]> >> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> chuck-users mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> chuck-users mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> chuck-users mailing list >>>>>>> [email protected] >>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>>>> >>>>>>> _______________________________________________ >>>>>> chuck-users mailing list >>>>>> [email protected] >>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> chuck-users mailing list >>>>> [email protected] >>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>> >>>>> _______________________________________________ >>>> chuck-users mailing list >>>> [email protected] >>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>> >>> >>> _______________________________________________ >>> chuck-users mailing list >>> [email protected] >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >>> >>> >> >> >> -- >> Spencer Salazar >> Doctoral Candidate >> Center for Computer Research in Music and Acoustics >> Stanford University >> >> [email protected] >> +1 831.277.4654 >> https://ccrma.stanford.edu/~spencer/ >> >> _______________________________________________ >> chuck-users mailing list >> [email protected] >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >> > > _______________________________________________ > chuck-users mailing list > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > >
_______________________________________________ chuck-users mailing list [email protected] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
