Matthew, I think you have something there with the -g flag. i just compiled racket myself. I can see gcc receiving the -g flag. Running the produced binaries provides the stack trace.
I think I need to open a bug report against debian's racket packages. Thanks for you help, -- Chad On Thu, Jun 28, 2012 at 11:28 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > I wonder whether the problem could be related to compilation options. > Did you compile your own executable? If so, what flags were given to > `configure' and/or the C compiler? > > On x86_64 Linux, Racket uses DWARF information to walk parts of the > runtime stack. It occurs to me that if you use gcc without the `-g' > flag, then DWARF information isn't included, so Racket can't understand > the stack. There may be other options that confuse the stack walker. > > (Errortrace and DrRacket both add their own context tracking > independent of the way that Racket is compiled, but that context is not > reflected via `continuation-mark-set->context'.) > > At Tue, 26 Jun 2012 16:37:13 +0900, Chad Albers wrote: >> I'm using Debian Linux. >> -- >> Chad Albers >> >> >> On Sun, Jun 24, 2012 at 10:08 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >> > What platform are you using? >> > >> > If it's Win64, the problem is likely Racket's weak support for getting >> > a backtrace on that platform (when the JIT is enabled). >> > >> > At Sun, 24 Jun 2012 22:01:02 +0900, Chad Albers wrote: >> >> Hi Eli, >> >> >> >> Thanks for you help. Unfortunately, it doesn't seem to work. I >> >> literally cut the code and pasted in a rkt file with #lang racket at >> >> the top. I ran it with the racket CLI, and received: '() >> >> >> >> Should I be invoking the CLI with some option? Any other ideas? >> >> >> >> -- >> >> Chad >> >> >> >> >> >> On Sun, Jun 24, 2012 at 2:08 PM, Eli Barzilay <e...@barzilay.org> wrote: >> >> > A few minutes ago, Chad Albers wrote: >> >> >> Hi, >> >> >> >> >> >> Is there some sort of 'secret' to acquiring the stack trace of an >> >> >> exception? It is my understanding that when an exception is raised >> >> >> with the 'error' procedure in creates a exn:fail structure that has >> >> >> a message field and a continuation-marks field. Presumably the >> >> >> stack trace is in the continuation-marks field. To actually get the >> >> >> stack trace I need to call the following: >> >> >> >> >> >> (continuation-mark-set->context (exn-continuation-marks exception)) >> >> > >> >> > This should work -- for example, I see a stack trace with: >> >> > >> >> > (with-handlers ([void (λ (e) (continuation-mark-set->context >> >> > (exn-continuation-marks e)))]) >> >> > (+ 1 "two")) >> >> > >> >> > >> >> >> However, whenever I call this, it yields an empty list: () - Not a >> >> >> stack trace. >> >> > >> >> > That can happen from running code in threads which start from an empty >> >> > context. For example, doing the above in a thread: >> >> > >> >> > (thread (λ () (printf "~s\n" ...same...))) >> >> > >> >> > shows an empty trace. >> >> > >> >> > -- >> >> > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >> >> > http://barzilay.org/ Maze is Life! >> >> >> >> ____________________ >> >> Racket Users list: >> >> http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
