I can use the browser and receive e-mails without problems. I can not reply-to or send any e-mail out without the application locking up. I can compose a new message and attach files but when trying to send it locks up the application. After the application locks up and I try to close the application, I receive a message that the program is not responding, asking me if I want to wait or force quit. Force quitting seamonkey causes any other open window on my desktop to close as well. This problem appeared after my recent upgrade to sys-devel/gcc-4.3.2. Prior to the upgrade the I had been using the application for years without issues. Reproducible: Always Steps to Reproduce: 1.Build www-client/seamonkey-1.1.16 with USE="-debug" 2.Open mail client and attempt to reply-to a message. 3.Compose a new message and attempt to send. Actual Results: Application lock up and you have to force quit. Expected Results: The application should function as designed to. If I build www-client/seamonkey-1.1.16 with USE="debug". The application functions as expected and runs smoothly. I discovered this by accident, after weeks of trying to sort out the problem, and no useful errors were being reported or logged to my system anywhere. Using [ebuild R ] www-client/seamonkey-1.1.16 USE="crypt gnome java postgres xinerama -debug -ipv6 -ldap -mozdevelop -moznocompose -moznoirc -moznomail -moznopango -moznoroaming -xforms" 0 kB /usr/bin/seamonkey -g No running windows found MOZILLA_FIVE_HOME=/usr/lib64/seamonkey LD_LIBRARY_PATH=/usr/lib64/seamonkey:/usr/lib64/seamonkey/plugins DISPLAY=:0.0 debugger=gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... (gdb) run Starting program: /usr/lib64/seamonkey/seamonkey-bin [Thread debugging using libthread_db enabled] [New Thread 0x7fd0b025f700 (LWP 16972)] [New Thread 0x417f2950 (LWP 16975)] [New Thread 0x41ff3950 (LWP 16976)] [New Thread 0x40896950 (LWP 16977)] [New Thread 0x427f4950 (LWP 16980)] [Thread 0x427f4950 (LWP 16980) exited] [New Thread 0x42ff5950 (LWP 16981)] [New Thread 0x427f4950 (LWP 16982)] [New Thread 0x437f6950 (LWP 16983)] [New Thread 0x43ff7950 (LWP 16984)] which: no soundwrapper in (/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/games/bin) [New Thread 0x447f8950 (LWP 16999)] [New Thread 0x44ff9950 (LWP 17000)] [New Thread 0x457fa950 (LWP 17001)] [New Thread 0x45ffb950 (LWP 17002)] [New Thread 0x467fc950 (LWP 17004)] [Thread 0x457fa950 (LWP 17001) exited] [Thread 0x467fc950 (LWP 17004) exited] Program terminated with signal SIGKILL, Killed. <--I had to force quit here after the app locked up. I had to kill the application after I attempted to replay-to a new incoming e-mail message.
Created attachment 195555 [details] emerge --info
What a frustrating and odd problem. Have you rebuilt your whole system with gcc 4.3.2, or could some seamonkey dependency have been missed? If you already have everything built with the same compiler: Could you attach the build log from when you rebuilt seamonkey with gcc 4.3.2? Perhaps there is a warning message from the compiler that might give a clue... Also, could you run the buggy (USE=-debug) build of seamonkey under strace to get a trace file of what happens right before a lockup?
(In reply to comment #2) > What a frustrating and odd problem. Have you rebuilt your whole system with gcc > 4.3.2, or could some seamonkey dependency have been missed? > > If you already have everything built with the same compiler: > > Could you attach the build log from when you rebuilt seamonkey with gcc 4.3.2? > Perhaps there is a warning message from the compiler that might give a clue... > > Also, could you run the buggy (USE=-debug) build of seamonkey under strace to > get a trace file of what happens right before a lockup? > I rebuilt my system files twice after switching to gcc-4.3.2*. Rebuilt gnome and xorg just to cover all my bases. I checked the dependencies for seamonkey and re-compiled them as well as the mozilla-launcher. I rebuilt seamonkey with -debug as requested and and created a strace file. The application continues to lockup with -debug. I wasn't able to retain the build log as my system seems to only maintain build logs for failed emerges. I will check the manual and see how to get and keep a build log, and attach asap.
Created attachment 195956 [details] strace output I did 2 strace runs, one using just -o and one using -fo. The -fo file is huge so will attach it later if necessary.
Created attachment 196027 [details] Build Log Seamonkey build log using -debug
This might be related to bug 265642. Can you try adding -fno-strict-aliasing to your CXXFLAGS and rebuilding?
(In reply to comment #6) > This might be related to bug 265642. Can you try adding -fno-strict-aliasing > to your CXXFLAGS and rebuilding? > I added -fno-strict-aliasing to my make.conf as suggested and it dose in fact fix the problem. However is this a flag that should be set globally or is there a way I can just set it for seamonkey.
(In reply to comment #7) > I added -fno-strict-aliasing to my make.conf as suggested and it dose in fact > fix the problem. > > However is this a flag that should be set globally or is there a way I can just > set it for seamonkey. I don't think there's a way to set CFLAGS on a per-package basis, but it looks like there's a patch ready to go for bug 265642, so once that's committed you should be able to remove -fno-strict-aliasing and build normally with no problems.
(In reply to comment #8) > (In reply to comment #7) > > I added -fno-strict-aliasing to my make.conf as suggested and it dose in fact > > fix the problem. > > > > However is this a flag that should be set globally or is there a way I can just > > set it for seamonkey. > > I don't think there's a way to set CFLAGS on a per-package basis, but it looks > like there's a patch ready to go for bug 265642, so once that's committed you > should be able to remove -fno-strict-aliasing and build normally with no > problems. > actually you can, it is a pita search the forums for posting on it. I am working to get nirbheek to commit the patch as soon as possible.
Fixed in-tree with -r1 Using commit message: ------------------------------------------------------------------------------ Fix crash without -fno-strict-aliasing, bug 265642 (Portage version: 2.2_rc33/cvs/Linux i686) ------------------------------------------------------------------------------