[chuck-users] Debugging Segmentation fault: 11

Spencer Salazar spencer at ccrma.stanford.edu
Tue Jan 27 21:20:38 EST 2015


+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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20150127/679faa5e/attachment-0001.html>


More information about the chuck-users mailing list