Summary: | x11-plugins/enigmail + mail-client/mozilla-thunderbird-2.0.0.17 - Using enigmail makes mozilla-thunderbird freeze/hang forever with gcc-4.3.2 and -O2 (due to -ftree-pre) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | matthias.grobarek |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | agaffney, blog, caster, creffett, eric.joshua.martin, esigra, fiona.klute, gentoo-bugzilla, grafgrimm77, Jimmy.Jazz, jlec, jochen+gentoo-bugs, john, keytoaster, klaas.decanniere, letonga, Manfred.Knick, matrix47, remi, toolchain, virdiq |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 198121 | ||
Attachments: |
strace -vFfto Thunderbird-Enigmail-strace.txt thunderbird
strace (same settings) my paludis --info mail-client/mozilla-thunderbird x11-plugins/enigmail nsPipeTransport::OpenInputStream() compiled with -Os nsPipeTransport::OpenInputStream() compiled with -Os -ftree-pre BZip'd .i file Patch to disable strict-aliasing for enigmail's IPC library |
Description
matthias.grobarek
2008-11-11 17:29:40 UTC
Created attachment 171444 [details]
strace -vFfto Thunderbird-Enigmail-strace.txt thunderbird
This is an strace log from running Thunderbird and then trying to open the OpenPGP Preferences. It begins about when I clicked the Preferences menu item, and I shortened it a bit in some places to make it more readable.
You can see that from time 16:58:12 on, Thunderbird is somehow caught in an infinite waiting loop.
*** Bug 246534 has been marked as a duplicate of this bug. *** I have the same problem since I upgraded to mail-client/mozilla-thunderbird-2.0.0.18 and recompiled x11-plugins/enigmail-0.95.7-r1 in the process. I also notice that the enigmail-0.95.7-r1 ebuild still has TBVER="2.0.0.17", but changing that to 2.0.0.18 doesn't help. Maybe there were changes to the enigmail-0.95.7-r1 ebuild without changing the version number? Enigmail worked fine until I recompiled it after installing thunderbird 2.0.0.18 yesterday. (In reply to comment #3) > Your emerge --info, please? And now, there wasn't any change as you can see here: http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-plugins/enigmail/enigmail-0.95.7-r1.ebuild?rev=1.4&view=log The interesting thing is that the guys who posted their emerge --info are running ~arch from what i can see, and both use amd64. I looked further into this issue and talked with jmbsvicetto about it. Both of us are running ~amd64. However, I ran into this bug, and he didn't. A difference between our systems was the GCC version used. Mine was 4.3.2, his was 4.2.4. I switched to 4.2.4 as well, re-emerged thunderbird and enigmail, and voila... it works fine. So apparently this is a gcc-4.3 issue. I use gcc-4.3 as well. I use 2.0.0.18 and 0.95.7-r2 as well. I just encountered a freeze when clicking on "settings" in the addon manager. # emerge --info WARNING: One or more repositories have missing repo_name entries: /usr/local/portage/profiles/repo_name NOTE: Each repo_name entry should be a plain text file containing a unique name for the repository on the first line. Portage 2.2_rc15 (default-linux/amd64/2007.0, gcc-4.3.2, glibc-2.7-r2, 2.6.25-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.25-gentoo-r6-x86_64-AMD_Athlon-tm-_64_Processor_3200+-with-glibc2.2.5 Timestamp of tree: Sun, 23 Nov 2008 20:45:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r9, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.4.7-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://130.59.10.34/mirror/gentoo/ http://130.59.10.35/mirror/gentoo/" LANG="de_DE.utf-8" LC_ALL="de_DE.utf-8" LDFLAGS="" LINGUAS="de cz it fr en zh_CN zh_TW" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/mnt/sda5/usr-tmp-portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/matsuu/secondlife" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X aac aalib accessibility acl alsa amd64 arts audiofile bash-completion berkdb bzip2 cairo cdr cjk cli cracklib crypt css cups dri dvd dvdr encode exif ffmpeg flac fortran gdbm geoip gnome gpm gtk gtk2 iconv immqt-bc ipv6 isdnlog java jpeg jpeg2k kde ldap lirc matroska midi mmx mozilla mp3 mplayer mtp mudflap musicbrainz mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pango pcre pdf perl png pppd python qt qt3 qt4 quicktime rar readline realmedia reflection samba sasl sdl session spl sse sse2 ssl svg tcpd theora tiff truetype type1 unicode vorbis xinerama xorg xosd xprint xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de cz it fr en zh_CN zh_TW" USERLAND="GNU" VIDEO_CARDS="nvidia vga vesa fbdev" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS $ strace -vFfto Thunderbird-Enigmail-strace.txt thunderbird No running windows found *** glibc detected *** strace: malloc(): memory corruption (fast): 0x00000000023b9ae0 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f62946dcb9d] /lib/libc.so.6[0x7f62946df2df] /lib/libc.so.6(__libc_malloc+0x90)[0x7f62946e04a0] strace[0x407fb0] strace[0x40574f] strace[0x403615] strace[0x4044dc] /lib/libc.so.6(__libc_start_main+0xf4)[0x7f629468b1f4] strace[0x402039] ======= Memory map: ======== 00400000-00446000 r-xp 00000000 08:11 3714005 /usr/bin/strace 00645000-00646000 r--p 00045000 08:11 3714005 /usr/bin/strace 00646000-00647000 rw-p 00046000 08:11 3714005 /usr/bin/strace 00647000-00655000 rw-p 00647000 00:00 0 023b9000-023da000 rw-p 023b9000 00:00 0 [heap] 7f6290000000-7f6290021000 rw-p 7f6290000000 00:00 0 7f6290021000-7f6294000000 ---p 7f6290021000 00:00 0 7f6294456000-7f629446c000 r-xp 00000000 08:11 67880 /lib64/libgcc_s.so.1 7f629446c000-7f629466b000 ---p 00016000 08:11 67880 /lib64/libgcc_s.so.1 7f629466b000-7f629466c000 r--p 00015000 08:11 67880 /lib64/libgcc_s.so.1 7f629466c000-7f629466d000 rw-p 00016000 08:11 67880 /lib64/libgcc_s.so.1 7f629466d000-7f62947ab000 r-xp 00000000 08:11 54391 /lib64/libc-2.7.so 7f62947ab000-7f62949ab000 ---p 0013e000 08:11 54391 /lib64/libc-2.7.so 7f62949ab000-7f62949af000 r--p 0013e000 08:11 54391 /lib64/libc-2.7.so 7f62949af000-7f62949b0000 rw-p 00142000 08:11 54391 /lib64/libc-2.7.so 7f62949b0000-7f62949b5000 rw-p 7f62949b0000 00:00 0 7f62949b5000-7f62949d0000 r-xp 00000000 08:11 52356 /lib64/ld-2.7.so 7f6294b91000-7f6294b93000 rw-p 7f6294b91000 00:00 0 7f6294bcc000-7f6294bcf000 rw-p 7f6294bcc000 00:00 0 7f6294bcf000-7f6294bd0000 r--p 0001a000 08:11 52356 /lib64/ld-2.7.so 7f6294bd0000-7f6294bd1000 rw-p 0001b000 08:11 52356 /lib64/ld-2.7.so 7fff9cbba000-7fff9cbd0000 rw-p 7ffffffe9000 00:00 0 [stack] 7fff9cbfd000-7fff9cbff000 r-xp 7fff9cbfd000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abgebrochen Created attachment 173077 [details]
strace (same settings)
Created attachment 173081 [details]
my paludis --info mail-client/mozilla-thunderbird x11-plugins/enigmail
Here's my output from "paludis --info mail-client/mozilla-thunderbird x11-plugins/enigmail". It's 275 lines, so I thought it might be better to post an attachment. This was created after upgrading to x11-plugins/enigmail-0.95.7-r2. Yes, I'm using GCC 4.3 on amd64.
I can confirm comment #5 that this bug is probably a GCC problem: Re-compiling Enigmail with GCC 4.1.2 (latest stable ebuild) resolved the issue for me (using mozilla-thunderbird-2.0.0.18 and enigmail-0.95.7-r1). Proposed fix: 1. emerge -a =gcc-4.1.2 2. Use gcc-config to switch to GCC 4.1.2, e.g.: gcc-config 1 3. source /etc/profile 4. emerge -a enigmail 5. If Thunderbird is still running, restart it. Maybe trying to build Enigmail with all GCC ebuilds between 4.1.2 and 4.3.2 could shed some light on when GCC broke (possibly valueable information for upstream), but I’m sorry I can’t be bothered to install five more GCC versions. confirmed. here enigmail works again when i compile it with the setting gcc-config x86_64-pc-linux-gnu-4.2.4 with gcc 4.3.2 it gives me freezes in thunderbird 2.0.0.18 (In reply to comment #13) > confirmed. > > here enigmail works again when i compile it with the setting > gcc-config x86_64-pc-linux-gnu-4.2.4 > > with gcc 4.3.2 it gives me freezes in thunderbird 2.0.0.18 > or with some other flags, like "x11-plugins/enigmail") export LDFLAGS="-Wl,-O1" export CFLAGS="`echo ${CFLAGS} | sed -e s/-O./-O0/`" ;; in your portage bashrc file I can confirm that : 1) just reading mails with GPG sigs is enough to trigger the bug 2) USE=-crypt works fine as a workaround (who needs GPG anyway :p) Thanks I found a temp fix without installing another version of gcc. I did this: CFLAGS="-march=amdfam10 -mtune=amdfam10 -msse3 -Os -pipe" emerge --oneshot enigmail My CFLAGS in my make.conf normally have -O2. I tested the fix from comment #16, works. Yep, I did CFLAGS="-march=k8 -Os" emerge --oneshot enigmail instead of CFLAGS="-march=k8 -O2" in the /etc/make.conf, and that fixed it. (In reply to comment #15) > I can confirm that : > 1) just reading mails with GPG sigs is enough to trigger the bug For me, merely replying to any email is enough to trigger the bug! I am also using ~amd64 and GCC 4.3.2 with CFLAGS="-mtune=k8 -O2 -pipe", thunderbird-2.0.0.18 and enigmail-0.95.7-r2. Rebuilding enigmail with CFLAGS="-mtune=k8 -Os -pipe" as suggested in comment #18 works for me too. I can verify that s/-O2/-Os/ does the trick here. Perhaps a simple 'replace_flags -O2 -Os' is needed? I've managed to track this down further to the -ftree-pre flag in combination with some flag(s) that are in -Os and -O2 but not in -O1. I've also tracked down the function in which it happens, which is nsPipeTransport::OpenInputStream(). I can move this into its own source file and compile all of Enigmail with -O2 except that file, which I compile with -Os and I don't experience the bug, but if I compile that file with -Os -ftree-pre then the buggy behaviour returns. I don't have time to investigate further now, but I'll attach assembler files for that one function (generated by gcc -S) compiled with both "-Os" and "-Os -ftree-pre". Created attachment 174916 [details]
nsPipeTransport::OpenInputStream() compiled with -Os
Compiling this into libenigmime.so leads to a working plugin.
Created attachment 174917 [details]
nsPipeTransport::OpenInputStream() compiled with -Os -ftree-pre
Compiling this into libenigmime.so leads to a broken plugin which gets stuck in poll().
FYI i've added the workaround to enigmail-0.95.7-r2, i'll leave the bug open so we can track what upstream does. I've tracked down the actual instructions where this breaks, so it looks to me like a GCC bug, but I'll create a test case to try to confirm this when I have more time. In the working assembly I posted, you can see that the line movq %rax, (%r14) executes well before movq 264(%rbx), %rsi (the first is just above .L9 and the second is about halfway between .L9 and .L5, and the jump just below .L9 is redundant if the code above executes, since the xor means the sign bit is never set). However, in the broken version these lines are in the opposite order, which is a problem because movq 264(%rbx), %rsi is reading this->mOutputStream into %rsi to be passed to mStdoutPoller->AsyncStart when it is called by call *24(%rax). But the movq %rax, (%r14) is writing this->mOutputStream with a value from the call to NS_NewPipe, so if the lines execute in the wrong order NULL is passed into AsyncStart as the outputStream parameter instead of the actual output stream created in NS_NewPipe. (In reply to comment #24) > FYI i've added the workaround to enigmail-0.95.7-r2, i'll leave the bug open so > we can track what upstream does. I can't see any difference between -r1 and -r2 to that end? > I can't see any difference between -r1 and -r2 to that end?
Sorry, it's there.
Yepp, it's in -r3, which apparently is in the tree now. Adding toolchain since this seems to be regression. Shouldn't we get a bug upstream (gcc) for this if indeed it is a regression? can someone try emerging with gcc-4.3.2 and their normal CFLAGS but with -fno-tree-pre added after the -O2 ? also, John: could you post the .i file for the .S ? in other words, find the statement that was compiling nsPipeTransport2 and rather than doing -S, do -E -dD that way we should be able to take the nsPipeTransport2.i file and compare: gcc -c -Os -ftree-pre nsPipeTransport2.i -o nsPipeTransport2.bad.o gcc -c -Os nsPipeTransport2.i -o nsPipeTransport2.good.o this will assist greatly in tracking down the issue in gcc The .i file's too big for bugzilla, so I've uploaded it here: http://files.theospears.com/nsPipeTransport2.i BTW, just playing with portage's CFLAGS won't work as the Mozilla build process strips everything but the -O flags. I forgot to say that I've also tested this on a 64-bit Core 2 Duo with -march=nocona and the bug is not present - it seems to only happen with -march=k8 and synonyms (also -march=native on my AMD machine). (In reply to comment #32) > I forgot to say that I've also tested this on a 64-bit Core 2 Duo with > -march=nocona and the bug is not present - it seems to only happen with > -march=k8 and synonyms (also -march=native on my AMD machine). > nocona still doesn't work for me. I'm compiling it with CFLAGS="-march=nocona -O2 -fno-tree-pre -pipe -fomit-frame-pointer" per vapier's request and I'll let people know when it's done. (In reply to comment #33) > (In reply to comment #32) > > I forgot to say that I've also tested this on a 64-bit Core 2 Duo with > > -march=nocona and the bug is not present - it seems to only happen with > > -march=k8 and synonyms (also -march=native on my AMD machine). > > > > nocona still doesn't work for me. I'm compiling it with CFLAGS="-march=nocona > -O2 -fno-tree-pre -pipe -fomit-frame-pointer" per vapier's request and I'll let > people know when it's done. > Uh, 2.0.0.17 isn't in portage anymore and I'm not having problems w/2.0.0.19. here's the output from genlop: mail-client/mozilla-thunderbird-2.0.0.19 Install date: Mon Jan 12 21:14:31 2009 USE="crypt -ldap -bindist -mozdom -replytolist" CFLAGS="-march=nocona -pipe -fPIC -Wno-return-type -w" x11-plugins/enigmail-0.95.7-r3 Install date: Mon Jan 12 21:18:05 2009 USE="" CFLAGS="-march=nocona -pipe -fPIC -Wno-return-type -w" if the file is too big, then compress it and attach it Created attachment 178328 [details]
BZip'd .i file
Eric, if you're just feeding those CFLAGS through portage then the Mozilla build files will strip both the -f flags, as mentioned in comment #31. Also, it's the Enigmail version that's important here, not the version of Thunderbird and that hasn't changed. Created attachment 196629 [details, diff]
Patch to disable strict-aliasing for enigmail's IPC library
The recent update combined with gcc 4.4 (current fix in the ebuild special-cases only 4.3) annoyed me again so I've looked into this a bit further and it seems to be a strict aliasing issue in the function I tracked down before.
This patch adds -fno-strict-aliasing to the CFLAGS and CXXFLAGS for the source directory containing the affected file, which fixes this bug for me.
(In reply to comment #38) > Created an attachment (id=196629) [edit] > Patch to disable strict-aliasing for enigmail's IPC library Thanks a lot! Created enigmail-0.95.7-r5.ebuild.diff for use with gcc-4.1.1: http://bugs.gentoo.org/show_bug.cgi?id=283864#c8 *** Bug 283864 has been marked as a duplicate of this bug. *** Is this still an issue with stable enigmail-1.x? I haven't seen this in any 1.x versions. (In reply to comment #42) > I haven't seen this in any 1.x versions. > 1.x is stable so closing, reopen with updated summary if problem is reproducible still. |