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