red syntax location x misbehaves reproducibly when debugging turned off

[jbclements]

Running without debugging annotations on certain saved files produce a red x that, when clicked, tries to splice the name of the current file onto the DrRacket process's current directory; if this doesn't exist, it signals an internal error and also creates a new tab that's in a strange in-between state; its title changes to "Untitled" when you switch to it.

Steps to reproduce:

1) Open DrR, open new buffer. 2) Change language level details to set to "no debugging or profiling" 3) Paste this text into the definitions window:

#lang racket

((λ () (car (/ 1 0))))

4) Save the file in a directory other than DrRacket's current directory (say, /tmp/tmp.rkt). 5) Click 'run'. 6) See the (expected, correct) error message "tmp.rkt:3:0: /: division by zero". 7) Click on the red source-location "x". 8) See this internal error text:

open-input-file: cannot open input file
  path: /Users/clements/brinckerhoff-source/tmp.rkt
  system error: No such file or directory; errno=2
  context...:
   raise-filesystem-error
   open-input-file
   /Users/clements/racket/racket/share/pkgs/gui-lib/mred/private/editor.rkt:225:19
   dynamic-wind
   /Users/clements/racket/racket/share/pkgs/drracket/drracket/private/unit.rkt:3063:8: create-new-tab method in frame-mixin
   /Users/clements/racket/racket/share/pkgs/drracket/drracket/private/unit.rkt:5566:2: open-drscheme-window
   loop
   /Users/clements/racket/racket/collects/racket/contract/private/arrow-higher-order.rkt:375:33
   dynamic-wind
   /Users/clements/racket/racket/collects/racket/contract/private/arrow-val-first.rkt:489:18
   call-in-empty-metacontinuation-frame
   /Users/clements/racket/racket/collects/racket/contract/private/arrow-val-first.rkt:489:18
   /Users/clements/racket/racket/share/pkgs/drracket/drracket/private/debug.rkt:1053:2: open-and-highlight-in-file
   /Users/clements/racket/racket/share/pkgs/drracket/drracket/private/debug.rkt:122:6: on-event method in clickable-snip-mixin207
   /Users/clements/racket/racket/share/pkgs/gui-lib/mred/private/wxme/editor-canvas.rkt:412:2: on-event method in editor-canvas%
   dynamic-wind

Note that the name of the file "tmp.rkt" was attached to DrRacket's current directory Note also that there's now another tab open.

[rfindler]

continuation-mark-set->context seems to be returning srclocs with relative paths in them. When I follow the steps you list, I see this prefix of the list:

(("condition->exn" . #f) ("do-raise" . #f) ("dynamic-wind" . #f) (#f . #(struct:srcloc #<path:tmp.rkt> 3 0 15 22)) ....

(this is with a printf right after the call in stack-checkpoint.rkt.)

[rfindler]

There are absolute paths when running from racket, tho:

$  racket
Welcome to Racket v7.8.0.10 [cs].
> (define exn (with-handlers ([exn:fail? values]) (dynamic-require `(file "/tmp/tmp.rkt") #f)))
> (continuation-mark-set->context (exn-continuation-marks exn))
(list
 '("condition->exn" . #f)
 '("do-raise" . #f)
 '("dynamic-wind" . #f)
 (cons #f (srcloc #<path:/tmp/tmp.rkt> 3 0 15 22))
 '("call-with-values" . #f)
.......

[jbclements]

I'm guessing... the srcloc structs are built at "read-syntax" time, when DrR hands the buffer's content over? Would that be the path that's passed as the optional first argument to read-syntax? Just thinking out loud...

[mflatt]

It looks like CS code deserialization (from background expansion in this case) doesn't fall back to current-directory as it should when current-load-relative-directory is #f. I'll push a repair.

[jbclements]

Thanks for deducing that this was CS. I knew I was going to forget to mention that.

[jbclements]

This bug seems to be back. Specifically, I'm running "version 7.9.0.10--2020-12-03(-/f) [cs]." and I can follow the original steps to observe the same broken behavior. FWIW, I do see this commit ( @8f08a9e ) in my git log.

[shhyou]

I suspect racket/racket@f07c2fea71b726 is related to this bug. The program in the above issue prints a relative path at f07c2fea71b726 while it prints an absolute path at f07c2fea71b726~1.

[mflatt]

@shhyou Yep - same problem, different library, allowed to happen again due to a missing test. Thanks for tracking that down, and I'll work on a repair.