From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.oboj.net ([195.178.185.14]) by ur; Sun Jul 9 12:32:40 EDT 2017 Received: from mail.oboj.net (mail.oboj.net [195.178.185.14]) (Authenticated sender: jamos@oboj.net) by mail.oboj.net (Postfix) with ESMTPA id B08B7105578 for <9front@9front.org>; Sun, 9 Jul 2017 18:34:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6463a226f9646a55c960753358c8ec69" Date: Sun, 09 Jul 2017 18:33:45 +0200 From: jamos@oboj.net To: <9front@9front.org> Subject: Re: [9front] ACHTUNG! CRITICAL PATCH! PLEASE APPLY! In-Reply-To: References: Message-ID: X-Sender: jamos@oboj.net User-Agent: Roundcube Webmail/RCMAIL_VERSION List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: agile managed callback base lifecycle-based extension strategy --=_6463a226f9646a55c960753358c8ec69 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 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 --=_6463a226f9646a55c960753358c8ec69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I am not at all an expert on this, so maybe some one else
on the li= st might enlighten us, but given what you wrote I
did some experiments= =2E I added a local variable in the function
suspproc() allocating som= e 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 arr= ay of 18 bytes, it crashes for me.

So it looks like the programmer allocated exactly the amount
of hea= droom needed (at that time) and nothing more. It is
quite plausible th= at something that is bigger in a 64bit world
(larger datatypes or alig= nment 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 usual= ly 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? Mayb= e 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

 

 
--=_6463a226f9646a55c960753358c8ec69--