I might not be able to do this until next week, but I will send it as soon as possible. Thanks to all!

On 28/01/2015 1:20 pm, Spencer Salazar 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]
<mailto:[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 <http://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 <http://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].__princeton.edu
                                <mailto:[email protected]>
                                
https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
                                
<https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>


                            _________________________________________________
                            chuck-users mailing list
                            [email protected].__princeton.edu
                            <mailto:[email protected]>
                            
https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
                            
<https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>

                        _________________________________________________
                        chuck-users mailing list
                        [email protected].__princeton.edu
                        <mailto:[email protected]>
                        
https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
                        
<https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>




                    _________________________________________________
                    chuck-users mailing list
                    [email protected].__princeton.edu
                    <mailto:[email protected]>
                    
https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
                    
<https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>

                _________________________________________________
                chuck-users mailing list
                [email protected].__princeton.edu
                <mailto:[email protected]>
                https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
                <https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>


            _________________________________________________
            chuck-users mailing list
            [email protected].__princeton.edu
            <mailto:[email protected]>
            https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
            <https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>

        _________________________________________________
        chuck-users mailing list
        [email protected].__princeton.edu
        <mailto:[email protected]>
        https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
        <https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>


    _________________________________________________
    chuck-users mailing list
    [email protected].__princeton.edu
    <mailto:[email protected]>
    https://lists.cs.princeton.__edu/mailman/listinfo/chuck-__users
    <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] <mailto:[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

Reply via email to