[Bug 33307] New: heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Bug #: 33307
           Summary: heap corruption with gcc 4.8.0
           Product: Wine
           Version: 1.5.27
          Platform: x86-64
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ntdll
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Fresh wine compiled with gcc 4.8.0 is quite unusable. Likely, gcc is a culprit.
But nevertheless it might indicate to some very sophisticated hidden bug in
wine64, so I post a bug here.

Compilation:

$ cd wine
$ mkdir build64
$ cd build64
$ ../configure --enable-win64 --prefix=/opt/wine64 --without-xinput2
--disable-tests
$ sudo make install

$ wine64 notepad
Bus error

Further investigation has led to the following:
$ WINEDEBUG=file,ntdll,heap wine64 notepad
...
err:heap:HEAP_ValidateInUseArena Heap 0x10000: block 0x106c0 tail overwritten
at 0x106e8 (byte 0/32 == 0x5c)
.....
wine64: ../../../dlls/ntdll/heap.c:455: HEAP_GetPtr: Assertion `0' failed.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #1 from Kirill K. Smirnov  2013-03-31 10:23:25 CDT ---
Addons:
1) wine32 is OK.
2) disabling optimization by -O0 "fixes" the bug.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download, source, win64
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Mike Lothian  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

jordan  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from jordan  2013-04-09 19:43:51 CDT ---
I can verify this...

after following Kirill's adivce, I was able to get wine64 to work.

Using -O0 flag seems to work, for wine64 for now.  Any optimization set beyond
that - results in wine64 being broken (with GG-4.8.0).

cheerz

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #3 from jordan  2013-04-09 22:37:14 CDT ---
(In reply to comment #1)
> Addons:
> - wine32 is OK.
> - disabling optimization by -O0 "fixes" the bug.

As i said, this also worked for me.

But i am curious - What is your system?

ie: Distro, CPU, etc..

thanks

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #4 from Alexandre Julliard  2013-04-10 03:59:15 CDT ---
*** Bug 33351 has been marked as a duplicate of this bug. ***

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #5 from Austin English  2013-04-10 22:20:59 CDT ---
A bisect against gcc may be useful.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #6 from jordan  2013-04-10 22:37:52 CDT ---
(In reply to comment #5)
> A bisect against gcc may be useful.

Hi Austin,

I might be able to try this over the weekend. I 've used git bisect a few
times, but haven't built gcc from git / sources before - so that's slightly
more disconcerting, but i'll see what i can do, i just need to set aside / find
some time to do so.

thanks

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #7 from Dan Kegel  2013-04-11 10:19:33 CDT ---
gcc uses a three-stage development schedule, and during stage 1, the tree
can be broken, so it might be hard to bisect gcc.

Does compiling with -O0 or -O1 instead of the default help?

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #8 from jordan  2013-04-11 10:39:57 CDT ---
(In reply to comment #7)
> gcc uses a three-stage development schedule, and during stage 1, the tree
> can be broken, so it might be hard to bisect gcc.
>
> Does compiling with -O0 or -O1 instead of the default help?

Hi Dan,

As noted in 2 of the above comments - yes, using -O0 does allow wine64 to work.
Myself and the O.P. both confirmed that... But I haven't tried -O1
specifically.

thanks

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #9 from Dan Kegel  2013-04-11 10:43:20 CDT ---
Try bisecting in optimization flags.
Assuming -O1 works, find out which optimization flags are on
in -01 vs. -O2, and turn half of those on, etc.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #10 from jordan  2013-04-11 10:45:54 CDT ---
(In reply to comment #9)
> Try bisecting in optimization flags.
> Assuming -O1 works, find out which optimization flags are on
> in -01 vs. -O2, and turn half of those on, etc.

Funny you mention that - I am compiling wine with -O1 right now ;)

..and yes, after that i will go through the different flags and see if i can
find a culprit.

I'll report back when i am done (this may take a while).

cheerz

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #11 from jordan  2013-04-12 07:05:56 CDT ---
@Dan

I ran out of time yesterday, but as a small update -O1 works fine and when i
get home i should be able to get through the rest of the flags. (i've already
went through about half of them).

cheerz

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #12 from jordan  2013-04-13 11:41:11 CDT ---
Okay, i am frustrated - it seems no matter how i compile Wine, with nay more
than -O1 optimization level, it fails to work properly. ~ it (wine64) fails in
different ways, depending on what additional flags are used.

I don't have enough experience to fix these issues.

I think it is going to require a more experienced programmer, who is familiar
with Wine's codebase and proper coding practices and isa using gcc-4.8.0

gcc-4.8.0 complains about a lot of stuff, when compiling wine and i personally
think there is a lot of errors/warnings that should be fixed, because i think
when using optimization levels > than -O1 - it is screwing up in multiple
places, not just specific to one or two flags.

anyway, for now i am just going to use -O1, since i have compiled wine 30+
times now, many ending in wine64 failing in different ways.

sorry I can't be of more help here - but i've already spent over 30hours trying
to find the source of the problem, to no avail.

cheerz

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #13 from Austin English  2013-04-14 19:19:42 CDT ---
I've got a bisect script running now, fyi. It's taking a while since the build
breaks in a few places, so quite a few commits are getting skipped..

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #14 from jordan  2013-04-14 23:01:51 CDT ---
(In reply to comment #13)
> I've got a bisect script running now, fyi. It's taking a while since the build
> breaks in a few places, so quite a few commits are getting skipped..

Hi Austin,

good luck and thanks for looking into this (and the update/coment), it's
appreciated.

Jordan

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #15 from Austin English  2013-04-17 11:54:44 CDT ---
So the bad commit is:
commit c8010b803d34fa7e096747067e33c650b36ecc06
Author: bernds 
Date:   Mon May 14 12:08:31 2012 +0000

* attribs.c (decl_attributes): Avoid emitting a warning if
        ATTR_FLAG_BUILT_IN.
        * doc/rtl.texi (CALL_INSN_FUNCTION_USAGE): Use lowercase for rtx
        codes.  Document meaning of sets inside CALL_INSN_FUNCTION_USAGE.
        * c-family/c-common.c (DEF_ATTR_STRING): Define and undefine as
        necessary.
        * builtin-attrs.def (DEF_ATTR_FOR_STRING): Define.  Use it to
        define a string "1".
        (ATTR_RET1_NOTHROW_NONNULL_LEAF): New attr definition.
        * builtins.def (BUILT_IN_MEMCPY, BUILT_IN_MEMMOVE, BUILT_IN_MEMSET,
        BUILT_IN_STRCPY): Use it for these functions.
        * postreload.c (reload_combine): Deal with SETs inside
        CALL_INSN_FUNCTION_USAGE.
        * caller-save.c (setup_save_areas, save_call_clobbered_regs):
        Look for REG_RETURNED notes and use a cheap restore if possible.
        * ira-int.h (struct ira_allocno): New member cheap_calls_crossed_num.
        (ALLOCNO_CHEAP_CALLS_CROSSED_NUM): New macro.
        * ira-build.c (ira_create_allocno, create_cap_allocno,
        propagate_allocno_info, propagate_some_info_from_allocno,
        copy_info_to_removed_store_destination, ira_flattening): Handle it.
        * ira-lives.c (pseudo_regno_single_word_and_live_p,
        find_call_crossed_cheap_reg): New static functions.
        (process_bb_node_lives): Look for SETs in CALL_INSN_FUNCTION_USAGE,
        and set ALLOCNO_CHEAP_CALLS_CROSSED_NUM if possible.  Also make
        a REG_RETURNED note in that case.
        * ira.c (setup_reg_renumber): Change assert to allow cases where
        allocnos only cross calls for which they are cheap to restore.
        * ira-costs.c (ira_tune_allocno_costs): Compare
        ALLOCNO_CALLS_CROSSED_NUM to ALLOCNO_CHEAP_CALLS_CROSSED_NUM rather
        than 0.
        * reg-notes.def (REG_RETURNED): New note.
        * cse.c (cse_insn): Likewise.
        * sched-deps.c (sched_analyze_insn): Likewise.
        * expr.c (init_block_move_fn): Set a "fn spec" attribute.
        * calls.c (decl_return_flags): New static function.
        (expand_call): Generate a SET in CALL_INSN_FUNCTION_USAGE for
        functions that return one of their arguments.
        * lto/lto-lang.c (handle_fnspec_attribute): New static function.
        (lto_attribute_table): Add "fn spec".
        (DEF_ATTR_STRING): Define and undefine along with the other macros.
        * regcprop.c (struct kill_set_value_data): New.
        (kill_set_value): Interpret data as a pointer to such a struct.
        Do nothing if the caller wants the register to be ignored.
        (copyprop_hardreg_forward_1): Handle SETs in CALL_INSN_FUNCTION_USAGE.

testsuite/
        * gcc.target/i386/retarg.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@187459
138bc75d-0d04-0410-961f-82ee72b054a4

after this commit, wine will fail to build (with default -O2 settings, gcc will
crash with an internal error). The compile itself is fixed by a later commit:
commit d73df2920c77116fd88e03cd95dd352f16511a3f
Author: bernds 
Date:   Mon May 21 21:37:01 2012 +0000

PR rtl-optimization/53373
        * caller-save.c (save_call_clobbered_regs): Look into a possible
        PARALLEL manually rather than using single_set on a call insn.
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@187745
138bc75d-0d04-0410-96

after this, wine will compile fine, but segfaults on launch.

A quick search on http://gcc.gnu.org/bugzilla/ doesn't show anything for that
commit. If someone else would file a bug upstream with this info, it would be
appreciated.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #16 from jordan  2013-04-17 12:42:04 CDT ---
(In reply to comment #15)
> after this, wine will compile fine, but segfaults on launch.
>
> A quick search on http://gcc.gnu.org/bugzilla/ doesn't show anything for that
> commit. If someone else would file a bug upstream with this info, it would be
> appreciated.

I will tackle the GCC bug report, if you like (?) .. most likely this evening,
sometime.

thanks Austin.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #17 from jordan  2013-04-18 19:50:26 CDT ---
FYI.

I've reported the gcc bug, included your last comment (Austin) and i have
provided a link on gcc bug tracker to this bug report;

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003

thanks again.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #18 from jordan  2013-04-18 20:10:14 CDT ---
I got a response on GCC bug tracker;
> IIRC this is usually due to mis writing of memcpy/memset where you return null
> rather than the dest (first argument).
> See PR56881 -> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881

the segfault appears to be a bug in wine afaict from looking at 56881 bug
report.

anyway, if there is anything more that i can do, let me know.

jordan

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #19 from Dan Kegel  2013-04-18 20:43:41 CDT ---
next step may be to bisect the wine sources (not in time, but in space)
by compiling half of them with the good compiler, and half of them with
the bad compiler, and narrowing down the file that triggers the problem
that way.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Robert Walker  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail].u
                   |                            |k

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #20 from Kirill K. Smirnov  2013-04-20 20:36:49 CDT ---
The couple of flags "-fno-builtin-memcpy -fno-builtin-memmove" produce usable
wine64 even with -O2 optimization level.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #21 from Kirill K. Smirnov  2013-04-20 21:14:47 CDT ---
"-fno-builtin-memcpy" is enough.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

sxe  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #22 from Dan Kegel  2013-04-22 00:23:59 CDT ---
I did some bisecting of the wine source.
Configuring with --disable-tests CC="ccache gcc-4.8" helps speed things up.

You have to test both with
  rm -rf ~/.wine; ./wine64 notepad
and
  rm -rf ~/.wine; WINEDEBUG=warn+heap ./wine64 notepad
because sometimes one will crash, sometimes the other will.
You also want to watch the log for strange warnings with munged paths.

-O2 fails; -O1 works; -O2 -fno-builtin-memcpy fails with warn+heap.
So it's not quite just -fno-builtin-memcpy.  But memcpy seems a big part of it.

Compiling everything with -O2, but with -O1 for kernel32, ntdll, and setupapi
seems to work, but has one heap warning.
Compiling everything with -O2 -fno-builtin-memcpy, but with -O1 for kernel32,
ntdll, and setupapi seems to work, with no heap warnings.

kernel32/process.c, and maybe build_argv() in particular, seem to be one
sensitive spot; when I was testing without warn+heap, that seemed to be the
worst bit.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Qian Hong  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

André H.  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #23 from André H.  2013-04-22 16:29:07 CDT ---
*** Bug 33419 has been marked as a duplicate of this bug. ***

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://gcc.gnu.org/bugzilla
                   |                            |/show_bug.cgi?id=57003

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #24 from Kirill K. Smirnov  2013-04-22 21:38:49 CDT ---
I've replaced every memcpy() in kernel32/process.c to memcpy_unaligned() and it
fixed munged paths - I do not get complaints about L"dows\syste\syswow64"
anymore. But heap corruption is still present.

Then I began to remove '_unaligned' suffix and see where munged paths show
themselves.
It turns to be a 965 line. This code works:

964:        memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );
965:        memcpy_unaligned( buffer + len, default_syswow64W,
sizeof(default_syswow64W) );
966:        DIR_SysWow64 = buffer;

and this not:

964:        memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );
965:        memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W)
);
966:        DIR_SysWow64 = buffer;

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #25 from Kirill K. Smirnov  2013-04-22 22:22:16 CDT ---
This code works too:
964:        memcpy_unaligned( buffer, DIR_Windows, len * sizeof(WCHAR) );
965:        memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W)
);
966:        DIR_SysWow64 = buffer;

It seems gcc incorrectly optimizes bulk of memcpy() function calls one after
another, not just single memcpy().

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Kirill K. Smirnov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #26 from Kirill K. Smirnov  2013-04-28 12:46:44 CDT ---
The gcc bug has been found and fixed, the patch has been applied:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=198321

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |UPSTREAM

--- Comment #27 from Jerome Leclanche  2013-04-28 12:51:51 CDT ---
Upstream.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #28 from Bruno Jesus  2013-04-28 13:16:06 CDT ---
Since the gcc bug was fixed I'm closing this.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

Jeff Cook  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #29 from Jeff Cook  2013-05-03 21:09:47 CDT ---
See also http://forum.winehq.org/viewtopic.php?f=8&t=18631 , which discusses
this same issue. A user there claims that he is still having problems.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

André H.  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #30 from André H.  2013-05-31 13:39:12 CDT ---
gcc 4.8.1 is released, can someone retest?

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #31 from Erik van Pienbroek  2013-05-31 13:54:44 CDT ---
(In reply to comment #30)
> gcc 4.8.1 is released, can someone retest?

In Fedora 19 we've been using recent gcc 4.8 snapshots and this issue has been
resolved for some time already. More details about this can be found at
https://bugzilla.redhat.com/show_bug.cgi?id=926972

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #32 from Jerome Leclanche  2013-06-04 11:42:05 CDT ---
This is fixed on Arch as well, so all good.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #33 from jordan  2013-06-04 11:51:46 CDT ---
(In reply to comment #32)
> This is fixed on Arch as well, so all good.

The Arch Wine maintainer is still using;

make CFLAGS+="-fno-builtin-memcpy" CXXFLAGS+="-fno-builtin-memcpy"

(which is to workaround this now closed bug / _non-issue_)

in his pkgbuild, which is odd given that i already told him that this problem
as been fixed. (?)...

But just to clarify, yes - Wine on Archlinux works fine (and has since april
25/26th), without any workaround on -O2 (like the above line).  I know this
because my build of wine does not contain the above line, and hasn't since
GCC-4.8.x update (with fix) hit Archlinux. ~ Wine64 works as expected (i use
mostly x64 windows apps these days).

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #34 from Jerome Leclanche  2013-06-04 11:52:49 CDT ---
(In reply to comment #33)
I'm using a custom pkgbuild, so I just meant compiling with arch's gcc works.
But do poke the maintainer again about this...

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #35 from jordan  2013-06-04 11:57:43 CDT ---
(In reply to comment #34)
> (In reply to comment #33)
> I'm using a custom pkgbuild, so I just meant compiling with arch's gcc works.
> But do poke the maintainer again about this...

Ah, i see, it just didn't seem aparent that you were using a custom build, by
what you wrote ~ I thought you may have been using Arch's Wine build, so i
thought it was important to point that bit out... but yeah, I will remind him.

[Bug 33307] heap corruption with gcc 4.8.0

http://bugs.winehq.org/show_bug.cgi?id=33307

--- Comment #36 from Jerome Leclanche  2013-06-15 10:06:57 CDT ---
Ive been building without mstackrealign for a while now. Was this fixed
upstream? the bug is still marked as new.

[Bug 33307] heap corruption with gcc 4.8.0

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=33307

Gabriel Ravier  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]