Arch Linux

Unassigning myself - this will likely never be fixed in gcc upstream...

Despite the comment: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c86
"I am in the process of updating i386 psABI to specify 16byte stack alignment." from January 18th?

I remain hopeful :p

This should be fixed by https://bugs.archlinux.org/task/27560

Wine now keeps the stack aligned, so 16byte alignment libs wine calls into should be protected from unaligned calls

I got bitten by this bug recently and I fixed my problem by recompiling lib32-openssl with -mstackrealign

Can this be applied to openssl and lib32-openssl or are there issues present with the proposed solution?

It was reported to be fixed within wine. So no, I wont alter openssl for this.

Alright, maybe the bug is still present in wine then because the issue is still present on a fully updated system.
Should this be closed?

@Pierre, I just tested, Picasa under wine will crash without -mstackrealign for lib32-openssl, but recompile lib32-openssl with -mstackrealign fixes the problem. Could you please add -mstackrealign in PKGBUILD for lib32-openssl?

Any updates? Thanks!

Is this occuring anywhere but picasa? Picasa ships its own compile of wine which is probably not compiled with the strack realignment. Changing the package to depend on, and use, arch's wine instead may fix it, but I don't know what patches google may have applied to the version they ship.

Of course, Google just killed Picasa for linux, so this will be shortly moot:
http://googleblog.blogspot.com/2012/04/spring-cleaning-in-spring.html

John, currently I only have problems with Picasa. Actually I don't have other applications requiring SSL.

I'm NOT using the Picasa wine package Google provided. Instead I just installed Picasa for Windows under wine. Thanks!

Not using picasa here.
I had problems running different windows applications which used ssl through wine, I can't remember which apps they were and I'm not on the same pc right now.

I talked about this with other devs. We are not going to recompile other packages with mstackrealign. This bug needs to be fixed within wine: http://bugs.winehq.org/show_bug.cgi?id=22316

The weird thing is that having -mstackrealign on wine *should* fix this everywhere, unless I'm not understanding it properly. All calls through wine should be aligned, whether necessary for sse calls or not, before calling into other libraries.

I was able to reproduce this with picasa - the stack trace goes through wininet, so it should have been aligned. It's possible there's something in wine's make scripts that arn't honoring CFLAGS for bits of code.

at least add -mstackrealign to openssl and glibc, i have this problem with teamviewer.. i don't think this bug will be fixed in gcc..
and  FS#27560  will *not* fix this everywhere, i will try to explain why. (if you don't understand please tell me to rephrase it because my english is not good)

these are the top lines of the wine crash report:

Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0xf75534ea).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:f75534ea ESP:0033c8fc EBP:00000001 EFLAGS:00010246( R- -- I Z- -P- )
EAX:7cc822f8 EBX:f75c7ff4 ECX:00000000 EDX:7de7c499
ESI:7eda222c EDI:ffffffd0
Stack dump:
0x0033c8fc: f73e46c0 00000000 f73e46c0 0033cadc
0x0033c90c: 75676572 0072616c ffa71cf2 ffa71cf1
0x0033c91c: ffa71cf1 ffa71cf1 ffa71cf1 ffa71cf1
0x0033c92c: ffa71cf2 00000000 00000000 00000000
0x0033c93c: 00000000 00000000 00000001 00000000
0x0033c94c: 7cccf830 7c000000 00000000 7ccd1bd0
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0xf75534ea __strcasestr_sse42_nonascii+0x5a() in libc.so.6 (0x00000001)
1 0x7de5f386 in libfreetype.so.6 (+0x62385) (0x00000001)
....
....


and here is the instruction that crashed it:

% gdb -q /usr/lib32/libc.so.6
Reading symbols from /usr/lib32/libc.so.6...(no debugging symbols found)...done.
(gdb) x/i __strcasestr_sse42_nonascii+0x5a
0x12f4ea <__strcasestr_sse42_nonascii+90>: vmovdqa 0x10(%esp),%xmm1
(gdb) quit


as you can you see ESP is 0x0033c8fc which is not 16bytes aligned, but all sse instructions need 16bytes alignment
this happens because wine calls a function from a library and that library calls a function from glibc, so the stack can change to a non-16bytes alignment (from the previous function).
so, glibc and openssl must be recompiled with -mstackrealign because they use sse instructions.

you can reproduce the problem with this assembly code:

.text
.globl _start
_start:
nop
andl $~0x10, %esp
subl $4, %esp
vmovdqa 0x10(%esp), %xmm1
movl $1, %eax
movl $0, %ebx
int $0x80

% as --32 a.s -o a.o
% ld -melf_i386 a.o -o a.out
% ./a.out
Segmentation fault

'subl $4, %esp' will break the alignment, if you remove it then it will not segfault.

i did some debugging and i found that it was glibc's fault.
they forgot to use _mm_loadu_si128 when they return an __m128i data type.

for some reason i cannot reproduce the openssl bug, if i reproduce it i will try to fix it.

http://sourceware.org/bugzilla/show_bug.cgi?id=14461

so, in the end it's not glibc's fault. but we can use my patch as a workaround, what do you think?

I am still unclear on where the stack is becoming misaligned. -mstackrealign on wine should cause wine to re-align the incoming stack from win32 code, which should prevent calls out of wine being misaligned. Perhaps wine also needs -mincoming-stack-boundary=2? Or has some fast call path that is bypassing the effects of mstackrealign?

thanks nephyrin, it works without my glibc patch!! :D
but first we must add the flags before the configure and also we must add -m32 flag because configure will exit with an error without it..

i attached a patch for the PKGBUILD..

So the fix for  FS#27560  put the CFLAGS in make's environment, which was not correctly applying -mstackrealign to the whole build, like I guessed above!

Does this patch still fix the issue for you? It should be slightly more correct (putting them in configure's environment) and not require the -m32 hack

no, we also need -mincoming-stack-boundary=2

So adding incoming-stack-boundary to the current CFLAGS after make does not fix it, but adding it before configure does?

btw, you forgot to put ${CFLAGS} :P

yes by adding "-m32 -mstackrealign -mincoming-stack-boundary=2" before 32bits configure, problem is solved

And why does it need to be exported before configure? The build should work just fine adding the flag after -mstackrealign, do you get a specific build error or does the crash still happen?

you are right, my mistake.
you can add it after make..

@Sven:
So as I near as I can tell from the barely-documented GCC notes on this, while -mstackrealign will re-align the incoming stack, it also needs to be aware that the incoming stack should be assumed to be 4-byte aligned or it will not always behave properly. This patch shouldn't have any significant performance impact above just -mstackrealign, though I don't pretend to understand GCC logic well enough to assert that it is fully solves the issue -- but it does fix a few more apps that were still failing after  FS#27560 

Alright thanks a lot guys. These changes will go into the repos with the next wine release which I anticipate today.