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

[jamos@oboj.net]

[-- 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 --]