DrRacket internal error uncompressing

Hi Guix,

Using guix 80739ea480a7db667b83b45e3a08be740449f689 on x86_64, running:

`guix environment --ad-hoc racket -- drracket` produces:

```

$bytevector-uncompress: internal error uncompressing #"\0\0\0\0chez\310\224\206:\r()#\201\256R-d\205\233\24\363\5\20\201P\6A\v\300\0\16\f\6\31\2\f\6\f&H\275\0\1\0\362\bA\377e\0\1\0C\6A\21\3\v\300\0\201\265!\f\6\n\0\a\1\35\0\1+\0\360\27\201\375\300\0\0\0\17\205\210Z\0\0M\215\245\b\4\0\0M9fH\17\206fZ\0\0I\2...

context...:

body of "/gnu/store/mmrax3f1vx3c8ih9hhgffpvka6chk96w-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/utils.rkt"

body of "/gnu/store/mmrax3f1vx3c8ih9hhgffpvka6chk96w-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/platform.rkt"

```

However, `guix time-machine --commit=b1248016e0492e1897f4d1127ccb07736c9bb6a5 -- environment --ad-hoc racket -- drracket`

successfully opens drracket. b1248016e0492e1897f4d1127ccb07736c9bb6a5 is

the commit before the Racket 8.0 update, so I think the update introduced

the problem. Other Racket GUI programs like slideshow and gracket also

also exhibit the problem. The command line REPL works however.

I have not investigated to determine if the problem is specific to the GUI

packages or if loading other extra Racket packages would also exhibit the

problem.

Best,

Jack

I wrote to the racket-users [0] list to see if they have advice on what

could be causing this problem.

[0] https://www.mail-archive.com/racket-users@googlegroups.com/msg46066.html

Best,

Jack

Philip,

Thanks for the work you've been doing on improving our Racket package. I

wanted to make sure you were aware of the failure of DrRacket and other

graphical Racket components to load in the latest Racket package.

Best,

Jack

Jack, thanks for the pointer: I hadn't noticed this earlier.

On 3/15/21 12:49 AM, Jack Hill wrote:

This appears to be an error uncompressing Racket's compiled code—whether

generated by the Racket layer or the Chez Scheme layer, I'm not sure.

The stack trace is pointing to the module `mred/private/wx/gtk/utils`,

which is here:

At first glance, the most unusual-looking thing about that module is the

use of `(only-in '#%foreign ctype-c->scheme)` … but it could also be

something else altogether. I'll try to investigate further, but thoughts

from others would be very welcome!

-Philip

I can reproduce the error with just:

```

$ racket -l mred/private/wx/gtk/utils

$bytevector-uncompress: internal error uncompressing

#"\0\0\0\0chez\310\224\206:\r()#\201\256R-d\205\233\24\363\5\20\201P\6A\v\300\0\16\f\6\31\2\f\6\f&H\275\0\1\0\362\bA\377e\0\1\0C\6A\21\3\v\300\0\201\265!\f\6\n\0\a\1\35\0\1+\0\360\27\201\375\300\0\0\0\17\205\210Z\0\0M\215\245\b\4\0\0M9fH\17\206fZ\0\0I\2...

context...:

body of

"/gnu/store/bbnhjamch9125c412bl7ybf28a0jxrkd-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/utils.rkt"

```

Aha! Running:

guix environment --ad-hoc --no-grafts racket -- drracket

launches DrRacket just fine.

My guess is that Racket CS is compressing string literals in compiled

code. Currently, Guix patches Racket source files to include the

absolute paths to foreign libraries in the store as string literals.

There are a bunch of grafts for GTK and such: if I'm right, Guix somehow

mangles the compiled code while attempting to apply the grafts.

I already thought this strategy was a bad idea. If it is really the

problem, I should be able to patch it fairly quickly: I've already been

experimenting along these lines.

-Philip

Hi,

I do not have problems with racket on a foreign distro. On guix system I

experience the same error.

Malte

On Mon, 15 Mar 2021, 22:06 Jack Hill, <jackhill@jackhill.us> wrote:

On Mon, 15 Mar 2021, Philip McGrath wrote:

Aha, that does sound promising. This certinially wouldn't be the only

grafts corner case:

Thanks for taking a look,

Jack

I've submitted a patch at https://issues.guix.gnu.org/47180that I hope

will resolve this issue.

-Philip

Hi Philip, [removed 'racket-users' from the recipient list]

Philip McGrath <philip@philipmcgrath.com> writes:

I think I know what happened here.

Recall that the grafting code performs a set of substitutions, replacing

store item names (i.e. file names in /gnu/store) with replacement store

items of the same length, with rules like:

"fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10" =>

"rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12".

The grafting code currently only checks the first 33 bytes, consisting

of the nix-base32 hash and the "-". It *assumes* that the remainder of

the associated store item name immediately follows, and blindly writes

the replacement string over whatever is there.

In this case, I suspect that within a *.zo file, a Guix store item name

was split into pieces, with the hash and "-" together in one piece but

split somewhere between the "-" and the last byte of the store item.

This results in corruption of the bytes following that piece.

I've recently observed the splitting of store item names in *.zo files

(see https://bugs.gnu.org/47614), but in that case the "-" was

separated from the hash, and as a result the reference was _invisible_

to the grafter.

For the record, when I originally wrote this fast(er) grafting code

(commit 5a1add373ab427a3b336981d857252e703a9f8d1), by design it only

rewrote the hashes, and so naturally it had the following desirable

property: it never overwrote any byte without first checking it against

an expected value. Later, starting in commit

57bdd79e485801ccf405ca7389bd099809fe5d67, the grafting code was modified

to allow rewriting the entire store item name (notably including the

version number). Unfortunately, although the set of overwritten bytes

was extended past the "-", the set of bytes *checked* was left

unchanged, and thus the aforementioned desirable property was lost.

I think we ought to restore that property. I'm already working on some

other changed to the grafting code (supporting UTF-16 and UTF-32 encoded

references), so I'll try to find the time to fix this problem as well.

Regards,

Mark

Hi Mark and everyone,

On 4/14/21 1:54 AM, Mark H Weaver wrote:

Yes, I agree with this diagnosis.

It seems the discussion has become a bit fragmented, since Jack first

reported one set of symptoms in https://issues.guix.gnu.org/47064 and

you then reported another in https://issues.guix.gnu.org/47614 (with

much better forensics than I'd found on my own—thanks!).

Both issues should have been fixed (at least with respect to Racket) by

my patch in https://issues.guix.gnu.org/47180, which was applied on

Monday.

-Philip

Hi Philip,

Philip McGrath <philip@philipmcgrath.com> writes:

FYI, I've now verified this suspicion. Here's precisely the corruption

that occurred:

Sounds good, thank you!

Mark