Wrong stack alignment when calling out to libraries

[robryk]

Sledge crashes for me when I try to use the framebuffer. I am running on a 64-bit Intel architecture, in a Linux environment. The issue seems to be an unaligned address in a MOVAPS instruction that points to the stack, so I'm pretty sure that the issue is that the call to libsdl has badly aligned stack. See the following gdb session:

robryk@sharya-rana ~/V/i/sledge> gdb ./sledge
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./sledge...done.
(gdb) r
Starting program: /home/robryk/VC/interim/sledge/sledge 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[compiler] creating global env hash table…
[compiler] init_allocator…

++ cell heap at 0x7fffe892b010, 240000000 bytes reserved
[allocator] initialized.
[compiler] inserting symbols…
[compiler] arithmetic…
[compiler] compare…
[compiler] flow…
[compiler] lists…
[compiler] strings…
[compiler] write/eval…
sledge knows 47 symbols. enter (symbols) to see them.
[fs] mounted: /framebuffer
[fs] mounted: /keyboard
[fs] mounted: /sd
sledge> (eval (read (recv (open "/sd/os/shell.l"))))
[open] found matching fs: /sd for path: /sd/os/shell.l
[open] open_fn: 0x40ae10
filename: os/shell.l
[posixfs] trying to read file of len 13594…
[open] found matching fs: /framebuffer for path: /framebuffer
[open] open_fn: 0x40a956

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdf9da796 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
(gdb) bt
#0  0x00007fffdf9da796 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#1  0x00007fffdec3f306 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#2  0x00007fffdec41991 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#3  0x00007fffdeedc85a in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#4  0x00007fffdec410af in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#5  0x00007fffdec8425c in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#6  0x00007fffdeeddc9c in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#7  0x00007fffdec45266 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#8  0x00007fffdeed84df in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#9  0x00007fffdec3400d in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#10 0x00007fffdeb1823b in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#11 0x00007fffdeb1ddc5 in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#12 0x00007fffdeb1e43b in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#13 0x00007fffdf46a7cc in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#14 0x00007fffdf477b1f in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#15 0x00007fffdf451d1a in ?? () from /usr/lib/libnvidia-glcore.so.340.76
#16 0x00007ffff7832b3b in ?? () from /usr/lib/libSDL2-2.0.so.0
#17 0x00007ffff782fc3a in ?? () from /usr/lib/libSDL2-2.0.so.0
#18 0x00007ffff7828cfe in ?? () from /usr/lib/libSDL2-2.0.so.0
#19 0x00007ffff7882203 in ?? () from /usr/lib/libSDL2-2.0.so.0
#20 0x00007ffff7882fd0 in ?? () from /usr/lib/libSDL2-2.0.so.0
#21 0x000000000040a899 in sdl_init (fullscreen=0) at ../devices/sdl2.c:34
#22 0x000000000040a964 in fbfs_open () at ../devices/sdl2.c:60
#23 0x000000000040a29c in fs_open (path=0x7fffe89312b0) at stream.c:47
#24 0x00007ffff7fc6014 in ?? ()
#25 0x0000000000000000 in ?? ()
(gdb) x/i $pc
=> 0x7fffdf9da796:  movaps %xmm0,-0x7f(%rax)
(gdb) p/x $rax-0x7f
$1 = 0x7fffffff7ba8

[mntmn]

Thanks for this report! I experienced almost the same issue when working on an OS X port pull-request yesterday. I have to redesign the stack allocation so that it is always aligned.

[robryk]

It might be worthwhile to do that only when calling a C function (as
opposed to one created out of whole cloth by JIT).

On Thu, Sep 17, 2015 at 11:39 AM, mnt.mn notifications@github.com wrote:

Thanks for this report! I experienced almost the same issue when working
on an OS X port pull-request yesterday. I have to redesign the stack
allocation so that it is always aligned.

—
Reply to this email directly or view it on GitHub
#5 (comment).

[mntmn]

True, although it concerns only C functions that (somewhere down the line) use 128-bit registers afaik. I think I don't want stack alignment on every alloc_int call, but for example in filesystem calls that interact with the Host OS (in your case, OpenGL).

[mntmn]

Fixed in latest commit. Can you confirm this?

[robryk]

Verified at a49f069