Bug 104769

AFAIR this was already reported on the mailing list some years ago and the conclusion back then was "compiler bug". Any reason why you disagree with this? At least, changing the optimisation level to make a segfault go away sound like a compiler bug to me (or e.g. violation of aliasing rules, or something like that, but why would that be specific to 32 bit software?).

Also:

> Problem: TeamViewer 12 and Adobe acroread 9.x and probably other closed source applications do not start anymore

This only happens with closed source software and only on x86 (so 32 bit)?! Uhm...

Could someone come up with a self-contained test case with a free license (even WTFPL would be fine with me)?

(In reply to Uli Schlachter from comment #1)
> AFAIR this was already reported on the mailing list some years ago and the
> conclusion back then was "compiler bug". Any reason why you disagree with
> this? At least, changing the optimisation level to make a segfault go away
> sound like a compiler bug to me (or e.g. violation of aliasing rules, or
> something like that, but why would that be specific to 32 bit software?).

As such that could be a compiler bug, a library bug or an application bug. Without any informations, I would actually argue that compiler bug is the least likely of all three.

Without a source-level test case, it is almost impossible to say which is it.

Could you provide a link to the mailing list archive, where this bug was a topic?
We have not found any open source application which has the same problem. 
Was it reported upstream as gcc bug? 
If it is really a gcc bug, it would be interesting to locate it, because users reported about this problem in the latest gcc-6 and gcc-7.
We will continue to search an open source package with the same problem, so that we can track the problem better. Please let me know if there is other interesting information we should collect.

Some ideas:
 - bisect which exact compiler optimisation flag triggers it
 - compare the generated code with/without said flag
 - based on the findings - pin-point who's 'to blame'

The thread starts at https://lists.freedesktop.org/archives/xcb/2016-June/010795.html.
https://lists.freedesktop.org/archives/xcb/2016-June/010815.html concludes (I think) that according to gdb there should be no crash.
https://lists.freedesktop.org/archives/xcb/2016-June/010819.html says that nothing crashes with gcc 5.3.
https://lists.freedesktop.org/archives/xcb/2016-June/010828.html is the last mail in the thread where the reporter will provide further data "tomorrow" (that's almost two years ago).

To add to Emil's suggestions: Since the link above says that this was introduced with libxcb 1.12, you could also git bisect the xcb repository to find out where "things go downhill" (although this might be hard since other libraries might use newer libxcb features).

Commenter in https://bugs.gentoo.org/616402 (really annoying that bugs.gentoo.org isn't an allowed domain for "See Also") says that -mstackrealign fixes it.

Other related bugs: https://bugs.freedesktop.org/show_bug.cgi?id=15693
                    https://bugs.freedesktop.org/show_bug.cgi?id=86788

Other projects like pixman and Mesa have implemented workarounds.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxcb/issues/2.