Bug 396609 – dev-libs/glib-2.30.2: after upgrading to it gobject-introspection and dbus-glib fail to build due segfaults and illegal instruction errors when compiled with -march=native (see comment #30)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Michael M. Tung 2011-12-31 15:52:23 UTC]

after ugrading to dev-libs/glib-2.30.2 several essential packages fail compiling; this renders useless important Gnome applications

Reproducible: Always

Steps to Reproduce:
1. emerge -av dev-libs/dbus-glib 
2. emerge -av dev-libs/gobject-introspection
3.
Actual Results:  
emerge -av dev-libs/dbus-glib for example gives illegal instruction errors and complains about missing files (the same package compiled flawlessly with dev-libs/glib-2.28.8)

emerging dev-libs/gobject-introspection results in a strange segmentation fault error



Expected Results:  
compilation without errors

[Comment 1 Michael M. Tung 2011-12-31 15:53:45 UTC]

Created attachment 297461 [details]
dbus-glib info

[Comment 2 Michael M. Tung 2011-12-31 15:55:05 UTC]

Created attachment 297463 [details]
gobject-introspection info

[Comment 3 Michael M. Tung 2011-12-31 15:55:35 UTC]

Created attachment 297465 [details]
dbus-glib log

[Comment 4 Michael M. Tung 2011-12-31 15:56:02 UTC]

Created attachment 297467 [details]
gobject-introspection log

[Comment 5 Rafał Mużyło 2011-12-31 16:53:14 UTC]

(In reply to comment #3)
> Created attachment 297465 [details]
> dbus-glib log

make[3]: *** [example-signal-emitter-glue.h] Illegal instruction

As for gobject-introspection, you've attached 'emerge --info' twice.

'-march=native' tends to be tricky if your processor is too recent when compared to your gcc version.

Also, due to how autotools handle set C{XX}FLAGS, it's a good idea to have '-O2' in them.

[Comment 6 Michael M. Tung 2011-12-31 18:09:19 UTC]

Hi! I changed the compile flags to

CFLAGS="-march=nocona -O2" CXXFLAGS="-march=nocona -O2"

and

sudo env CFLAGS="-march=core2 -O2" CXXFLAGS="-march=core2 -O2" emerge -av dbus-glib

since I have an Intel Core i7. The result is however the same error...

[Comment 7 Alexandre Rostovtsev (RETIRED) 2011-12-31 20:29:52 UTC]

An "illegal instruction" error usually indicates either wrong CFLAGS for your processor, or a problem with your hardware (for example, bad memory or overheating CPU), or a problem with your compiler and assorted tools (gcc, ccache, distcc, etc.). The first culprit I would recommend checking is ccache problems. Please disable ccache in make.conf, then re-emerge glib, and see if you can emerge dbus-glib and gobject-introspection.

[Comment 8 Rafał Mużyło 2011-12-31 22:53:38 UTC]

(In reply to comment #6)
> Hi! I changed the compile flags to
> 
> CFLAGS="-march=nocona -O2" CXXFLAGS="-march=nocona -O2"
> 
> and
> 
> sudo env CFLAGS="-march=core2 -O2" CXXFLAGS="-march=core2 -O2" emerge -av
> dbus-glib
> 
> since I have an Intel Core i7. The result is however the same error...

Well, duh...
Chances are "Illegal instruction" comes *not* from the package you're building, but from one of the packages already installed, at least if it's the "wrong C{XX}FLAGS" case.

[Comment 9 Michael M. Tung 2012-01-01 11:16:47 UTC]

Hi again and happy new year! Thanks for all the suggestions. - I recompiled glib with ccache disabled and with safe CFLAGS, however the same error persists afterwards with dbus-glib and gobject-introspection.

BTW, I have another Gentoo box (only dual core, not i7) and observe exactly the same errors. If I maintain the older glib package dev-libs/glib-2.28.8, everything works fine.

[Comment 10 Michael M. Tung 2012-01-01 12:31:24 UTC]

Hi, I have been doing some further experimenting. I copied the source code of dbus-glib-0.98, unpacked and compiled manually. No problem. Afterwards I copied  the CFLAGS from the manual configure to the emerge command: same error.

So the trouble appears not to be caused by the source code. If the problem lies in the orginal dev-libs/glib package (wrong CFLAGS, CCACHE etc), why does dbus-glib-0.98 compile manually?

Any other suggestions for testing?

Here are my two outputs:

MANUAL CONFIGURE/COMPILE:
...
make[5]: Leaving directory `/home/mike/dbus-glib-0.98/dbus/examples'
Making all in statemachine
make[5]: Entering directory `/home/mike/dbus-glib-0.98/dbus/examples/statemachine'
/bin/sh ../../../libtool --mode=execute ../../../dbus/dbus-binding-tool --prefix=sm_server --mode=glib-server --output=statemachine-server-glue.h statemachine-server.xml
/bin/sh ../../../libtool --mode=execute ../../../dbus/dbus-binding-tool --prefix=sm_object --mode=glib-server --output=statemachine-glue.h statemachine.xml
echo "#include <config.h>" > sm-marshal.c.tmp
glib-genmarshal --prefix=sm_marshal ./sm-marshal.list --header --body >> sm-marshal.c.tmp
mv sm-marshal.c.tmp sm-marshal.c
glib-genmarshal --prefix=sm_marshal ./sm-marshal.list --header > sm-marshal.h.tmp && mv sm-marshal.h.tmp sm-marshal.h
make  all-am
make[6]: Entering directory `/home/mike/dbus-glib-0.98/dbus/examples/statemachine'
...

EMERGE WHICH FAILS:
...
make[3]: Entering directory `/var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98-build/dbus/examples'
/bin/sh ../../libtool --mode=execute ../../dbus/dbus-binding-tool --prefix=some_object --mode=glib-server --output=example-service-glue.h /var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98/dbus/examples/example-service.xml
/bin/sh ../../libtool --mode=execute ../../dbus/dbus-binding-tool --prefix=test_object --mode=glib-server --output=example-signal-emitter-glue.h /var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98/dbus/examples/example-signal-emitter.xml
make[3]: *** [example-signal-emitter-glue.h] Segmentation fault
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [example-service-glue.h] Segmentation fault
make[3]: Leaving directory `/var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98-build/dbus/examples'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98-build/dbus'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-libs/dbus-glib-0.98/work/dbus-glib-0.98-build'
make: *** [all] Error 2

[Comment 11 Pacho Ramos 2012-01-02 12:07:31 UTC]

(In reply to comment #10)
> Hi, I have been doing some further experimenting. I copied the source code of
> dbus-glib-0.98, unpacked and compiled manually. No problem. Afterwards I copied
>  the CFLAGS from the manual configure to the emerge command: same error.
> 
> So the trouble appears not to be caused by the source code. If the problem lies
> in the orginal dev-libs/glib package (wrong CFLAGS, CCACHE etc), why does
> dbus-glib-0.98 compile manually?
> 

Probably because you are manually compiling it without any CFLAGS/CXXFLAGS/LDFLAGS setting, maybe downgrading CFLAGS to simply "-O2 -pipe" could help...

[Comment 12 Pacho Ramos 2012-01-03 01:00:58 UTC]

*** Bug 397331 has been marked as a duplicate of this bug. ***

[Comment 13 Pacho Ramos 2012-01-03 01:04:45 UTC]

After reading this bug, bug 397331 and http://forums.gentoo.org/viewtopic-t-897374-start-0.html , http://forums.gentoo.org/viewtopic-t-907234.html seems that this only occurs when compiling using portage, not manually compiling. Even first forum thread shows a backtrace that could involve sandbox here (but I think nobody has already tried to compile affected packages with sandbox disabled, even if I think I saw a similar report involving "sandbox" time ago :S)

Will CC portage and sandbox maintainer to try to know how to investigate more this problem to know the root cause :|

[Comment 14 Zac Medico 2012-01-03 01:18:42 UTC]

A user reports that rebuilding sandbox solved it:

http://forums.gentoo.org/viewtopic-p-6917620.html#6917620

[Comment 15 SpanKY 2012-01-03 01:59:41 UTC]

if you have bum CFLAGS that are causing SIGILL, then you'd have to rebuild everything that gets used in the portage stack such as sandbox

[Comment 16 Michael M. Tung 2012-01-03 10:40:50 UTC]

HURRAY! Re-emerging the sandbox package with the following crucial flags did the job:

env CFLAGS="-O2 -pipe" CXXFLAGS="-O2 -pipe" LDFLAGS="-O2 -pipe" emerge -av sandbox

Afterwards everything else (glib, dbus-glib, gobject-introspection, dev-cpp/glibmm dev-python/pygobject gnome-base/gvfs net-libs/glib-networking net-libs/libsoup...) compiled smoothly on both of my Gentoo platforms (dual core P9700 and quad i7) without further changes (ccache enabling turned out to be irrelevant).

Many thanks to you all for the help! Best, Mike

[Comment 17 Mark Purtill 2012-01-11 06:47:48 UTC]

Rebuilding sandbox as in comment #16 also worked for me.

The "bad" flag is -march=core2; changing just sandbox from CFLAGS="-march=core2 -ggdb -O2 -pipe" to CFLAGS="-ggdb -O2 -pipe" makes the crash go away.

[Comment 18 Rafał Mużyło 2012-01-17 01:03:14 UTC]

(In reply to comment #16)
> Afterwards everything else (glib, dbus-glib, gobject-introspection,
> dev-cpp/glibmm dev-python/pygobject gnome-base/gvfs net-libs/glib-networking
> net-libs/libsoup...) compiled smoothly on both of my Gentoo platforms (dual
> core P9700 and quad i7) without further changes (ccache enabling turned out to
> be irrelevant).
> 

(In reply to comment #17)
> Rebuilding sandbox as in comment #16 also worked for me.
> 
> The "bad" flag is -march=core2; changing just sandbox from CFLAGS="-march=core2
> -ggdb -O2 -pipe" to CFLAGS="-ggdb -O2 -pipe" makes the crash go away.

On that note: I don't have the cpu, but as I look on gcc manpages, 'corei7' and 'corei7-avx' are new in 4.6. Likely, 'core2' is simply incorrect for i7 in a few corner cases.

[Comment 19 Pacho Ramos 2012-01-17 10:56:41 UTC]

(In reply to comment #17)
> Rebuilding sandbox as in comment #16 also worked for me.
> 
> The "bad" flag is -march=core2; changing just sandbox from CFLAGS="-march=core2
> -ggdb -O2 -pipe" to CFLAGS="-ggdb -O2 -pipe" makes the crash go away.

What flag is passing "-march=native"? What does `echo "" | gcc -march=native -v -E - 2>&1 | grep cc1` say?

[Comment 20 Rafał Mużyło 2012-01-23 09:21:37 UTC]

*** Bug 399805 has been marked as a duplicate of this bug. ***

[Comment 21 Pacho Ramos 2012-01-30 11:16:44 UTC]

(In reply to comment #19)
> (In reply to comment #17)
> > Rebuilding sandbox as in comment #16 also worked for me.
> > 
> > The "bad" flag is -march=core2; changing just sandbox from CFLAGS="-march=core2
> > -ggdb -O2 -pipe" to CFLAGS="-ggdb -O2 -pipe" makes the crash go away.
> 
> What flag is passing "-march=native"? What does `echo "" | gcc -march=native -v
> -E - 2>&1 | grep cc1` say?

[Comment 22 Mark Purtill 2012-01-31 04:52:19 UTC]

(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > Rebuilding sandbox as in comment #16 also worked for me.
> > > 
> > > The "bad" flag is -march=core2; changing just sandbox from CFLAGS="-march=core2
> > > -ggdb -O2 -pipe" to CFLAGS="-ggdb -O2 -pipe" makes the crash go away.
> > 
> > What flag is passing "-march=native"? What does `echo "" | gcc -march=native -v
> > -E - 2>&1 | grep cc1` say?

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2

I've got a Intel Q6600 system, which I believe is a Core 2 processor.

[Comment 23 Pacho Ramos 2012-01-31 09:46:06 UTC]

(In reply to comment #22)
> /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v -
> -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param
> l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2
> 
> I've got a Intel Q6600 system, which I believe is a Core 2 processor.

Yes, core2 looks ok for that processor, maybe the problem is with other flags like -mcx16 -msahf...

Please try building with that CFLAGS and, then, try dropping them until finding the culprit. Will also CC gcc to check.

[Comment 24 Stuart Shelton 2012-02-03 08:51:14 UTC]

I have the same problem (by the looks of it) with =sys-devel/gcc-apple-4.2.1_p5666 on Mac OS 10.7 using Prefix.  I have an i7 processor and am using '-march=core2'.

Prefix doesn't support sandbox (no GNU C Library) - but the weird thing I see is that rebuilding via portage (where the source is removed and unpacked again) consistently fails in cases when this issue occurs, but if I do 'ebuild <path to ebuild> compile' after the build fails for the first time, then the build reliably succeeds!

[Comment 25 Samuli Suominen (RETIRED) 2012-02-20 15:44:07 UTC]

*** Bug 405013 has been marked as a duplicate of this bug. ***

[Comment 26 Pacho Ramos 2012-02-20 20:33:01 UTC]

*** Bug 405005 has been marked as a duplicate of this bug. ***

[Comment 27 SpanKY 2012-03-06 05:42:48 UTC]

is there anything left here ?  seems like once people picked the right compiler flags and rebuilt their packages, everything ran great.

[Comment 28 Bradley Broom 2012-03-16 12:48:50 UTC]

I experienced the OP's problem trying to compile dev-libs/gobject-introspection-1.30.0-r2 (and -r1). Recompiling sandbox, glib, glibc, and a few other tools did not help. 

I traced the underlying cause as far back as an incompatibility problem between g_file_open_tmp and sandbox (at least in this context). If the compile is done without the sandbox everything is fine, but if libsandbox.so is preloaded, the call to g_file_open_tmp segfaults. 

As a temporary hack, I replaced the use of g_file_open_tmp in gobject-introspection-1.30.0-r2: giscanner/scannerparser.y: gi_source_scanner_parse_macros with a simple hand-written replacement and this let both gobject-introspection and everything depending on it compile. (Unfortunately, I lost the source of this hack when I did the ebuild ... merge.) 

I hope this helps someone track down the real issue.

[Comment 29 Pacho Ramos 2012-04-01 17:34:47 UTC]

(In reply to comment #28)
> I experienced the OP's problem trying to compile
> dev-libs/gobject-introspection-1.30.0-r2 (and -r1). Recompiling sandbox,
> glib, glibc, and a few other tools did not help. 
> 
> I traced the underlying cause as far back as an incompatibility problem
> between g_file_open_tmp and sandbox (at least in this context). If the
> compile is done without the sandbox everything is fine, but if libsandbox.so
> is preloaded, the call to g_file_open_tmp segfaults. 
> 
> As a temporary hack, I replaced the use of g_file_open_tmp in
> gobject-introspection-1.30.0-r2: giscanner/scannerparser.y:
> gi_source_scanner_parse_macros with a simple hand-written replacement and
> this let both gobject-introspection and everything depending on it compile.
> (Unfortunately, I lost the source of this hack when I did the ebuild ...
> merge.) 
> 
> I hope this helps someone track down the real issue.

Your "emerge --info" please?

[Comment 30 BlinkEye 2012-05-01 06:41:58 UTC]

I had the same issue. The following solved it:

# mkdir -p /etc/portage/env/sys-apps
# echo 'CFLAGS="-O2 -pipe"' > /etc/portage/env/sys-apps/sandbox
# emerge sandbox
# emerge dev-libs/gobject-introspection


Comparing Michael M. Tung's 'emerge --info' and mine:

# emerge --info | grep -E 'Portage|System|CFLAGS|CXXFLAGS'
Portage 2.1.10.49 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.3, glibc-2.14.1-r3, 3.2.12-gentoo x86_64)
System uname: Linux-3.2.12-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.0.3
CFLAGS="-march=native"
CXXFLAGS="-march=native"

I'd say '-march=native' with gcc-4.5.3 on the i7 920 produces some unsafe CFLAGS for sandbox:

# echo "" | gcc -march=native -v -E - 2>&1 | grep cc1 
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=core2

[Comment 31 Pacho Ramos 2012-05-01 09:12:58 UTC]

Looks like march=native is picking wrong CFLAGS for i7 processors with gcc-4.5... probably solved in gcc-4.6, but it's still hardmasked :(

[Comment 32 Ryan Hill (RETIRED) 2012-05-07 21:06:39 UTC]

They look fine to me.

[Comment 33 Ryan Hill (RETIRED) 2012-05-07 21:14:00 UTC]

I can't reproduce this with

Portage 2.2.0_alpha101 (default/linux/amd64/10.0/developer, gcc-4.5.3, glibc-2.15-r1, 3.2.12-gentoo x86_64)
=================================================================
System uname: Linux-3.2.12-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_820_@_1.73GHz-with-gentoo-2.1
Timestamp of tree: Mon, 07 May 2012 20:30:01 +0000
ccache version 3.1.7 [enabled]
app-shells/bash:          4.2_p28
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.5.4-r4, 2.6.8, 2.7.3-r2
dev-util/ccache:          3.1.7
dev-util/cmake:           2.8.8-r2
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1
sys-apps/openrc:          0.9.9.3
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.5
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.3.6-r1, 4.4.7, 4.5.3-r2, 4.5.4_pre9999::toolchain, 4.6.3::tundra, 4.6.4_pre9999::toolchain, 4.7.0_pre9999::toolchain
sys-devel/gcc-config:     1.7
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 3.3 (virtual/os-headers)
sys-libs/glibc:           2.15-r1
Repositories: gentoo tundra gcc-porting toolchain dirtyepic
Installed sets: @system
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -g -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CXXFLAGS="-O2 -march=native -g -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps=y --quiet-build=n"
FEATURES="assume-digests binpkg-logs ccache clean-logs compress-build-logs compressdebug distlocks ebuild-locks fixlafiles multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms sign split-log splitdebug strict test test-fail-continue unknown-features-warn unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org/"
LANG="en_US.utf8"
LDFLAGS="-Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed"
LINGUAS="en en_CA en_US"
MAKEOPTS="-j16 V=1"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/dirtyepic/overlay /home/dirtyepic/svn/gcc-porting /home/dirtyepic/svn/toolchain /home/dirtyepic/svn/dirtyepic"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE_PYTHON="2.5 2.6 2.7"
Unset:  CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

[Comment 34 Pacho Ramos 2012-05-08 08:23:23 UTC]

(In reply to comment #30)
[...]
> # echo "" | gcc -march=native -v -E - 2>&1 | grep cc1 
> /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v -
> -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param
> l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192
> -mtune=core2

Please try to reproduce setting this flags and dropping some of them until you find the one breaking

[Comment 35 Mark Purtill 2012-05-09 02:50:24 UTC]

(In reply to comment #23)
> (In reply to comment #22)
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v -
> > -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param
> > l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2
> > 
> > I've got a Intel Q6600 system, which I believe is a Core 2 processor.
> 
> Yes, core2 looks ok for that processor, maybe the problem is with other
> flags like -mcx16 -msahf...
> 
> Please try building with that CFLAGS and, then, try dropping them until
> finding the culprit. Will also CC gcc to check.

Sorry, for some reason I didn't see this request when it first came out.  However, I wasn't using -march=native; I was using -march=core2 directly, so none of the other flags were present.  (As indicated in my comment #17, removing -march=core2 from the list made the problem go away, so that seems to be the culprit, at least for me.)

[Comment 36 Ryan Hill (RETIRED) 2012-05-09 05:00:00 UTC]

(In reply to comment #34)
> (In reply to comment #30)
> [...]
> > # echo "" | gcc -march=native -v -E - 2>&1 | grep cc1 
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v -
> > -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param
> > l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192
> > -mtune=core2
> 
> Please try to reproduce setting this flags and dropping some of them until
> you find the one breaking

Mine is identical:

dirtyepic@tundra ~ $ echo "" | gcc-4.5.3 -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=core2

Is rebuilding sandbox all it takes to reproduce this?  Can we get a backtrace?

[Comment 37 m.drochner 2012-05-30 15:27:28 UTC]

Created attachment 313615 [details, diff]
make g_open a wrapper

A similar problem was observed on NetBSD/pkgsrc, see
http://gnats.netbsd.org/45942

It was tracked down to be caused by an ABI problem which affects the amd64
architecture in particular (but not i386). Whether it leads to a crash
or not depends on the contents of the %eax register at the time of a call
of open(2) through a non-variadic pointer, thus a dependency on compiler flags.
The attached patch fixed the problem.
Note that the patch reveals some wrong calls to g_open() (with only 2 arguments)
in other gnome software. Since g_open() is documented to have 3 arguments,
these uses should be fixed.

hope this is useful
Matthias

[Comment 38 SpanKY 2012-05-31 00:35:12 UTC]

(In reply to comment #37)

i know some arches you can't mix variadic and non-variadic funcs as the ABI ends up passing things differently, but i didn't think x86_64 was in that boat.  i thought it passed args the same way regardless.  especially for the args that are static (such as the first two -- filename & mode).

can the OP confirm if this change makes a difference to them ?

[Comment 39 Bradley Broom 2012-08-28 16:27:09 UTC]

Recompiling sandbox with gcc-4.5.4 p1.0 (instead of 4.5.3) fixed it for me.

[Comment 40 SpanKY 2016-02-21 09:08:10 UTC]

should be resolved by using current stable versions of everything