eventspace internal error when copying drracket internal error dialog

[samth]

I provoked this by:

1. Starting with some out of date zos
2. Running something in DrRacket that triggered an internal error due to the out of date zos
3. Try to copy the error text from the DrRacket internal error dialog.

Here's the racket/gui error:

internal error: wrong eventspace for constrained event handling

/home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/mred/private/wx/common/freeze.rkt:9:0 internal-error
/home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/mred/private/wx/common/freeze.rkt:36:0 constrained-reply6

And here's the previous DrRacket error:

/home/samth/sw/plt/racket/share/pkgs/s3-sync/compiled/info_rkt.zo::1: read (compiled): wrong version for compiled code
  compiled version: 6.3.0.3
  expected version: 6.3.0.4
  context...:
   standard-module-name-resolver
   /home/samth/sw/plt/racket/collects/setup/getinfo.rkt:32:0: get-info/full
   /home/samth/sw/plt/racket/collects/racket/contract/private/arrow-val-first.rkt:325:3
   /home/samth/sw/plt/pkgs/racket-index/setup/xref.rkt:29:3: for-loop
   /home/samth/sw/plt/pkgs/racket-index/setup/xref.rkt:23:0: get-dests
   /home/samth/sw/plt/pkgs/racket-index/setup/xref.rkt:19:0: get-rendered-doc-directories
   /home/samth/sw/plt/extra-pkgs/drracket/drracket/drracket/private/syncheck/blueboxes-gui.rkt:671:2: fetch
   /home/samth/sw/plt/extra-pkgs/drracket/drracket/drracket/private/syncheck/blueboxes-gui.rkt:670:0: get-blueboxes-cache
   /home/samth/sw/plt/extra-pkgs/drracket/drracket/drracket/private/syncheck/blueboxes-gui.rkt:444:4: compute-tag+rng method in ...ck/blueboxes-gui.rkt:173:2
   /home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/framework/private/coroutine.rkt:47:20
   /home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/framework/private/coroutine.rkt:56:0: coroutine-run
   /home/samth/sw/plt/racket/collects/racket/contract/private/arrow-val-first.rkt:303:18
   /home/samth/sw/plt/extra-pkgs/drracket/drracket/drracket/private/syncheck/blueboxes-gui.rkt:410:4: update-the-strs method in ...ck/blueboxes-gui.rkt:173:2
   /home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/framework/private/logging-timer.rkt:41:0: log-timeline/proc
   /home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/mred/private/wx/common/timer.rkt:34:38
   /home/samth/sw/plt/extra-pkgs/gui-lib/gui-lib/mred/private/wx/common/queue.rkt:454:6
   ...

[samth]

See also http://bugs.racket-lang.org/query/?cmd=view&pr=14953

[rfindler]

Out of date zo files can cause arbitrary memory corruption nowadays. Why is this worth investigating?

[samth]

Wait, really? I didn't know that -- when did it happen?

Also, these errors are from a wrong version, which is detected before reading, so I don't think memory corruption would be possible.

[rfindler]

Well, if I have an unexported function and an exported macro in one file and another file requires that one, using the macro. The macro does some syntactic checks and compiles into a call to the function. Say this call is saved in a .zo file. Then, later on, the function and the macro both change in such a way that the generated call from an old use of the macro no longer makes a safe call to the function. If the .zo file is not recompiled then the function will be called in a way that breaks internal invariants of that function. Now arbitrary bad things can go wrong because invariants are broken. (The main interesting example of this phenomenon is TR, of course.)

[samth]

First, that definitely isn't what's happening here -- Racket is trying to load something and failing, not loading the wrong thing.

Second, it's always been the case that you can call unexported functions by generating the appropriate bytecode (or by using things like require/expose). But the scenario you describe sounds like it just would see the .zo file as out of date, rather than loading the wrong code, since the file defining the macro had changed without the dependent zo being updated.

[rfindler]

First, You said it was using out of date .zo files. How exactly do you know that that error was the only thing that went wrong?

Second, I am not getting what relevance second has to this PR.

My question remains.

[samth]

I think we should investigate this because I don't think it's caused by memory corruption. I don't, of course, know that the error messages I saw were the only thing that went wrong; something else could always have happened. But it seems like the error messages are the most likely indicator of what the error was.

[rfindler]

Okay, but if you stick arbitrary errors into DrRacket in places that would correspond to bugs then I would prefer to fix the bugs rather than reason about DrRacket's implementation behaves when ordinarily okay expressions start randomly erroring.

Unless you are saying that point 2. happend in the interactions window (and the out of date .zo files are not ones that DrRacket itself depends on)?

[samth]

The error message is pointing to the s3-sync package, which I don't think DrRacket depends on. More generally, I don't think this is a bug in DrRacket -- the function at issue is is never called in DrRacket source code.

[rfindler]

Sorry, I should have said "the gui library" not DrRacket. I agree that that error is effectively blaming racket/gui somewhere.

I suppose it is reasonable that one should be able to survive runtime errors in all dynamic-requires (even those from lazy-require) in more friendly ways, but it seems really hard and it's not clear it is worth it.

I'm not seeing how this is a good use of our time. Just re-compile your .zo files and move on. IMO.

[samth]

I don't think the actual bug is failing to handle out-of-date .zo files properly, but that clipboard handling sometimes calls things in the wrong eventspace. It just happens that the internal errors you get from DrRacket when you have out-of-date .zos triggers this bug, but I don't think that's the only thing that does. For example, @soegaard's bug report that I linked to doesn't mention zo files, and the bug @mfelleisen reported here has a different error that seems to have triggered it.

[samth]

Ok, here's a different way to reproduce the error:

• open drracket/private/syncheck/blueboxes-gui.rkt (thanks C-S-o)
• go to line 671
• add (car) to the beginning of the fetch function
• restart DrRacket
• type something in the defns window (so that background check syntax runs)
• get an internal error
• try to copy the message text

The error is because the eventspace attached to the wx object in the mouse handling for the mouse-release event is the original eventspace, not the error-display-eventspace. All the other events for that window are in the correct eventspace, so I'm not yet sure what's going on to cause this.

[rfindler]

Thanks!

I don't see the bad behavior on my mac, but what happens if you change thread on line 85 on drracket/private/init to queue-callback?

[samth]

That didn't seem to change the behavior.