ACHTUNG! CRITICAL PATCH! PLEASE APPLY!

ACHTUNG! CRITICAL PATCH! PLEASE APPLY!

[Alex Musolino]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Greetings,

Sorry for the somewhat alarmist subject line, but I trust you will all
appreciate the gravity of the situation.  As it stands, games/[45]s are
broken on amd64.

Patch attached.

--
Cheers,
Alex Musolino

[-- Attachment #2: xs.patch --]
[-- Type: text/x-patch, Size: 424 bytes --]

diff -r 8551f3aaa97d sys/src/games/xs.c
--- a/sys/src/games/xs.c	Thu Jun 22 07:31:35 2017 +0000
+++ b/sys/src/games/xs.c	Thu Jul 06 23:44:57 2017 +0930
@@ -877,7 +877,7 @@
 	suspc= chancreate(sizeof(int), 0);
 	mousec= chancreate(sizeof(Mouse), 0);
 	kbdc= chancreate(sizeof(Rune), 0);
-	threadcreate(suspproc, nil, 1024);
+	threadcreate(suspproc, nil, 2*1024);
 	points = 0;
 	memset(board, 0, sizeof(board));
 	redraw(0);

Re: [9front] ACHTUNG! CRITICAL PATCH! PLEASE APPLY!

[jamos]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

 

Thanks for the patch, Alex! 

It actually fixed a bug in 'games/5s'
that I noticed only a week ago,
making it crash if the font variable is
set to a "bigger" font. 

font=/lib/font/bit/dejavusans/unicode.18.font
games/5s # big font - crash
font=/lib/font/bit/vga/unicode.font games/5s
# stdandard font - no crash 

It looks like applying your patch solves
the issue :-). I now also tried
on plan9/arm (Miller's edition) and it
runs without modification. 

What caused you to find the bug? Maybe some
other means than
with changing the font. 

Jonas 

2017-07-06 16:23
skrev Alex Musolino: 

> Greetings,
> 
> Sorry for the somewhat alarmist
subject line, but I trust you will all
> appreciate the gravity of the
situation. As it stands, games/[45]s are
> broken on amd64.
> 
> Patch
attached.
> 
> --
> Cheers,
> Alex
Musolino

font=/lib/font/bit/dejavusans/unicode.18.font 

[-- Attachment #2: Type: text/html, Size: 1279 bytes --]

Re: [9front] ACHTUNG! CRITICAL PATCH! PLEASE APPLY!

[Alex Musolino]

> What caused you to find the bug? Maybe some other means
> than with changing the font.

I also use a non-default font but have only recently started using
amd64 kernels.  If I changed back to /lib/fonts/bit/vga/unicode.font I
don't see the problem anymore.  Originally I thought that the larger
size of pointers on amd64 was causing the stack to be exhausted, but
now I'm not sure what's going on.  There seems to be nothing obviously
font-related in the suspproc thread.

--
Cheers,
Alex Musolino

Re: [9front] ACHTUNG! CRITICAL PATCH! PLEASE APPLY!

[jamos]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

 

I am not at all an expert on this, so maybe some one else
on the
list might enlighten us, but given what you wrote I
did some
experiments. I added a local variable in the function
suspproc()
allocating some extra space on the stack. 

Without setting a bigger
font, it seems to be possible to allocate
another 17 bytes on the stack
without crashing. Upon allocating
an array of 18 bytes, it crashes for
me. 

So it looks like the programmer allocated exactly the amount
of
headroom needed (at that time) and nothing more. It is
quite plausible
that something that is bigger in a 64bit world
(larger datatypes or
alignment padding) could consume those
few extra bytes. 

It would be
interesting to hear if there has been similar problems
with other
programs, e.g. while converting to amd64, and how
you usually determine
how much of stack to allocate, by trial and
error, or by calculating?


Jonas 

2017-07-09 08:51 skrev Alex Musolino: 

>> What caused you to
find the bug? Maybe some other means than with changing the font.
> 
> I
also use a non-default font but have only recently started using
> amd64
kernels. If I changed back to /lib/fonts/bit/vga/unicode.font I
> don't
see the problem anymore. Originally I thought that the larger
> size of
pointers on amd64 was causing the stack to be exhausted, but
> now I'm
not sure what's going on. There seems to be nothing obviously
>
font-related in the suspproc thread.
> 
> --
> Cheers,
> Alex Musolino



[-- Attachment #2: Type: text/html, Size: 1995 bytes --]