Oh, but maybe this is the right way to do things: [robby@yanpu] ~/git/plt/src/build$ gdb `which racket` GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) set args -l drracket (gdb) run Starting program: /Users/robby/git/exp/plt/bin/racket -l drracket On Sat, Apr 27, 2013 at 5:15 PM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > I'm not following. I meant "- ell", fwiw. Here's what I see on my mac os x > machine: > > [robby@yanpu] ~/git/plt/src/build$ gdb racket -l drracket > warning: could not set timeout limit to `drracket'. > GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC > 2011) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-apple-darwin"...Reading symbols for > shared libraries ... done > > (gdb) run > Starting program: /Users/robby/git/exp/plt/bin/racket > > > > > On Sat, Apr 27, 2013 at 5:09 PM, Patrick King <slowthou...@gmail.com>wrote: > >> gdb racket -"ell" >> gdb racket -"one" >> gdb racket -"eye" >> >> Good to have gdb back, down in the guts. appalling how much I've >> forgotten. Most likely error message so far: >> >> ~/Source$ gdb racket -i drracket >> Interpreter `drracket' unrecognized >> ~/Source$ >> >> I've tried running from home, usr directories, various variations of ./* >> for file references. >> >> >> On Sat, Apr 27, 2013 at 5:42 PM, Robby Findler < >> ro...@eecs.northwestern.edu> wrote: >> >>> How about doing this: >>> >>> gdb racket -l drracket >>> >>> from the command line and then, when gdb shows up, type "run" and hit >>> return. Then you should get a stack trace, at least. >>> >>> Robby >>> >>> >>> On Sat, Apr 27, 2013 at 4:39 PM, Patrick King <slowthou...@gmail.com>wrote: >>> >>>> On Sat, Apr 27, 2013 at 5:02 PM, Robby Findler < >>>> ro...@eecs.northwestern.edu> wrote: >>>> >>>>> I'm not sure how to better communicate with ubuntu, but if you run >>>>> drracket from a shell / terminal window then there might be some output in >>>>> that window after the crash happens that might be a hint. >>>>> >>>>> >>>> pking@pk-Aspire-5733Z:~/Source$ ./drracket.sh >>>> Seg fault (internal error) at 0x7f20eb35aa40 >>>> SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0x7f20eb35aa40 >>>> ./drracket.sh: line 2: 2470 Aborted (core dumped) >>>> /usr/racket/bin/drracket >>>> pking@pk-Aspire-5733Z:~/Source$ >>>> >>>> I haven't found where the core dump is actually hiding. There is no >>>> line 2470 in usr/racket/bin/drracket, which is what ./drracket.sh: line 2 >>>> appears to reference. It might refer to a line deep in the gracket source. >>>> >>>> Thanks, Pat. >>>> >>>> >>>> >>> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
