[chuck-users] Debugging Segmentation fault: 11

Tue Jan 27 23:43:44 EST 2015

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 <rdpoor at gmail.com> 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 <
> spencer at 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 <jwmatthys at gmail.com>
>> 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 at lists.cs.princeton.edu
>>>>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> chuck-users mailing list
>>>>>>>>> chuck-users at lists.cs.princeton.edu
>>>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>> chuck-users mailing list
>>>>>>>> chuck-users at lists.cs.princeton.edu
>>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> chuck-users mailing list
>>>>>>> chuck-users at lists.cs.princeton.edu
>>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>> chuck-users mailing list
>>>>>> chuck-users at lists.cs.princeton.edu
>>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> chuck-users mailing list
>>>>> chuck-users at lists.cs.princeton.edu
>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>
>>>>>  _______________________________________________
>>>> chuck-users mailing list
>>>> chuck-users at lists.cs.princeton.edu
>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at 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 at ccrma.stanford.edu
>> +1 831.277.4654
>> https://ccrma.stanford.edu/~spencer/
>>
>>  _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20150127/f56a45bd/attachment-0001.html>