Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please also install seamonkey-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install seamonkey

Then run seamonkey with a parameter -g. That will start seamonkey running inside of gdb debugger. Then use command run and do whatever you did to make seamonkey crash. When it happens, you should go back to the gdb and run

	(gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 325116 [details]
paste from gdb session

Created attachment 325117 [details]
paste from gdb (thread apply all backtrace)

Created attachment 325118 [details]
From BugBuddy "report"

seamonkey running in a "complete" gnome session, instead XFCE

I have the same problem with:

http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.14/gtk+-2.14.5.changes
http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.14/gtk+-2.14.5.md5sum

I think the problem is with "default" decoder (text/plain) for unknown document mime-type.

news !?

news ???

I can't reproduce it on my current system but I'm going to upgrade to F10. In meantime can you please check the upcoming seamonkey update? 

from ftp://ftp.mozilla.org/pub/seamonkey/nightly/candidates-1.1.14

(In reply to comment #11)
> I can't reproduce it on my current system but I'm going to upgrade to F10.
Can you explain what "my current system" means?
I've no issue on last F9 package-release, i have (serious, i think) problem on seamonkey of F10.
Serious -i mean- because a browser that crash on text/plain o unknown content-type is a very serious problem.

> In
> meantime can you please check the upcoming seamonkey update? 
> 
> from ftp://ftp.mozilla.org/pub/seamonkey/nightly/candidates-1.1.14
F10 re{pack|build}ed ?
ok, i will try.

(In reply to comment #12)
> > from ftp://ftp.mozilla.org/pub/seamonkey/nightly/candidates-1.1.14
> F10 re{pack|build}ed ?
> ok, i will try.

It's official mozilla binary independent to specific distro. If it doesn't crash for you, the problem is likely in Fedora.

well,

-  I dowloaded mozilla from: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.14/seamonkey-1.1.14.en-US.linux-i686.tar.gz unpacked in /usr/local  ( tar xvf seamonkey-1.1.14.....-i686.tar.gz -C /usr/local )

-  symlink in /usr/local/bin to have greater priority than "system" (aka fedora packaged) seamonkey

- Check with no "user profile" (moved .mozilla to another name):
    lenovo load quietly, gtk urls in #7 load quietly.    -> NO CRASH
- Check with my "user profile" (with a lot of addons installed):
    lenovo load quietly, gtk urls in #7 load quietly.    -> NO CRASH

for running seamonkey from mozilla tarball i installed also compat-libstdc++-33 'cause it needs libstdc++.so.5.

# repoquery --whatprovides libstdc++.so.5
compat-libstdc++-33-0:3.2.3-64.i386
# yum install compat-libstdc++-33
Plugin caricati:refresh-packagekit


Fedora10 seamonkey is compiled for libstdc++.so.6
   libstdc++.so.6(GLIBCXX_3.4)  

:|

Sorry, I cannot provide more information because the crash I reported no longer occurs for me on F10. I don't have access to the Pentium-M  machine and now only have x86_64 installs on Core 2 hosts rather than i386. The same website loads fine today with seamonkey-1.1.13-1.fc10.x86_64 but I do not know whether the site content has been changed since the original report...

rebuild (my) seamonkey-1.1.14-0.i386.rpm, obtained from seamonkey-1.1.13-1.fc10.src.rpm with replaced source tarball ( http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.14/seamonkey-1.1.14.source.tar.bz2 ). 

Well,  lenovo and gtk urls (see #7 )  crash it !!! :(

I can reproduce it on F10, thanks for the info.

It seems to be caused by gcc & -O2 optimalization ...still investigating.

The bug (or feature? ;-) seems to be between gcc-4.3.0-11 and gcc-4.3.2-7. 

gcc-4.3.0-11 & -O2 - code doesn't crash. (F9 gcc)
gcc-4.3.2-7 & -O2 - code crashes. (f10 gcc)

Is it fixable ? 
Or the best thing to to is "convert" (someway) seamonkey user profile to  firefox one and remove this seamonkey crap ?! :|

I have the same problem with the Seamonkey browser crashing.
Version information:

[root@localhost script]# rpm -q seamonkey
seamonkey-1.1.14-1.fc10.i386
[root@localhost script]# rpm -V seamonkey
[root@localhost script]# rpm -q gcc
gcc-4.3.2-7.i386
[root@localhost script]# rpm -V gcc
[root@localhost script]# 

Attached is the bug buddy report I recieved. I will also attach GDB output with debuginfo package installed.

Created attachment 327768 [details]
Bug Buddy

Attachment from Bug Buddy 
Text

Created attachment 327769 [details]
GDB Bug Buddy - Additional information provided

Running seamonkey -g did not drop me into gdb.

Running GDB straight with seamonkey-bin:

[root@localhost seamonkey-1.1.14]# gdb ./seamonkey-bin
GNU gdb Fedora (6.8-29.fc10)
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 "i386-redhat-linux-gnu"...
(gdb) run
Starting program: /usr/lib/seamonkey-1.1.14/seamonkey-bin 
/usr/lib/seamonkey-1.1.14/seamonkey-bin: error while loading shared libraries: libxpcom_core.so: cannot open shared object file: No such file or directory

Program exited with code 0177.
(gdb) thread apply all backtrace
No registers.
(gdb)

If I can further assist in this bug report let me know.
Thanks.

I seem to have the same problem in F10. 

seamonkey-1.1.14-1.fc10.i386 crashes but the seamonkey tar ball from seamonkey-project.org (Gecko/20081204 SeaMonkey/1.1.14) does not crash.

I checked that seamonkey-1.1.13-1.fc10.i386 also crashes.

(In reply to comment #24)
> I seem to have the same problem in F10. 
> 
> seamonkey-1.1.14-1.fc10.i386 crashes but the seamonkey tar ball from
> seamonkey-project.org (Gecko/20081204 SeaMonkey/1.1.14) does not crash.

as #18 #19, the guilty is gcc.

vanilla upstream SM 1.1.4 has not been compiled with gcc 4.3.2 and libc6 (-> #19).

Created attachment 328192 [details]
testcase

Here is minimal gcc testcase I can do. The pointers should be initialized to 0x1 but are NULL. Any changes to the main test file (type changes, some code removes) cause the code works as expected. NOTE - it's i386/F10 only.

Reproduced with:

[komat@localhost ~]$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)

seamonkey-1.1.14-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/seamonkey-1.1.14-2.fc10

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

seamonkey-1.1.14-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Even if it works with one gcc and doesn't with a different one, it could very well be an application bug, depending on undefined behavior (aliasing violation etc.).  If it works with -O0 and doesn't with -O2, can you:
1) try to compile with -O2 -fno-strict-aliasing instead of -O2
2) if 1) makes a difference, build with -W -Wall and see if there are aliasing
   warnings, fix them
3) depending on if 1) works, do either a binary search between object files
   compiled with -O2 -fno-strict-aliasing and -O2, or between -O0 and -O2 object
   files
Once narrowed to one compilation unit, try to find out which function matters and if possible, create a self-contained testcase.

Ah, sorry, I see you've already done that, will look at this later.

Works with -O2 -fno-strict-aliasing for test.ii (nsCOMPtr.ii flags don't matter).
This is obvious aliasing violation, so seamonkey gets what it deserves.

#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
  // Our use of nsCOMPtr_base::mRawPtr violates the C++ standard's aliasing
  // rules. Mark it with the may_alias attribute so that gcc 3.3 and higher
  // don't reorder instructions based on aliasing assumptions for
  // this variable.  Fortunately, gcc versions < 3.3 do not do any
  // optimizations that break nsCOMPtr.
 
  #define NS_MAY_ALIAS_PTR(t)    t*  __attribute__((__may_alias__))
#else
  #define NS_MAY_ALIAS_PTR(t)    t*
#endif

and it is used in
  NS_MAY_ALIAS_PTR(nsISupports) mRawPtr.
This is just great misunderstanding of what may_alias attribute is though.

`may_alias'
     Accesses through pointers to types with this attribute are not
     subject to type-based alias analysis, but are instead assumed to
     be able to alias any other type of objects.  In the context of
     6.5/7 an lvalue expression dereferencing such a pointer is treated
     like having a character type.  See `-fstrict-aliasing' for more
     information on aliasing issues.  This extension exists to support
     some vector APIs, in which pointers to one vector type are
     permitted to alias pointers to a different vector type.

     Note that an object of a type with this attribute does not have any
     special semantics.
Especially read the last note.  As strict aliasing violations aren't reads/writes through the mRawPtr pointer, but reads/writes to the mRawPtr variable (sometimes written/read as void *, sometimes as nsISupports *, sometimes other pointers).  So, if you want to avoid strict aliasing violation, you'd need:
     if (((__builtin_expect((!((rv) & 0x80000000)), 1)))) {
-      nsISupports *p_tmp = out.mRawPtr;
-      printf("p_out = %p\n",p_tmp);
-      nsIOutputStream *p_stream1 = (nsIOutputStream *)p_tmp;
+      nsISupports *__attribute__((may_alias)) *p_tmp = &out.mRawPtr;
+      printf("p_out = %p\n",*p_tmp);
+      nsIOutputStream *p_stream1 = (nsIOutputStream *)*p_tmp;
       printf("p_stream1 = %p\n",p_stream1);
   }
(and all accesses, at least those which the compiler can see, some are hidden into begin_assignment) to mRawPtr would need to be done similarly).
And where you use begin_assignment or StartAssignment, you want to replace
all the method return values and all the casts NS_REINTERPRET_CAST, such that
they return {void,nsISupports,T} *__attribute__((__may_alias__)) {*,&,...}.

Should I fill this then to mozilla.org bugzilla?

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

Is bug #478340 also a duplicate?

Thanks for the explanation, moving back to seamonkey...

A bug should be filed at bugzilla.mozilla.org against component XPCOM, with Jakub's explanations from comment 34, mentioning that it's about file nsCOMPtr.h

That file provides a core feature of Mozilla's code infrastructure, and is used everywhere.

I filed the Mozilla bug

https://bugzilla.mozilla.org/show_bug.cgi?id=472570

The feed back from the mozilla.org bug is:

  -------  Comment #1 From  Benjamin Smedberg [:bs] (bsmedberg)   2009-01-07 17:26:00 PST   (-) [reply] -------

We build with -fno-strict-aliasing by default. How are we ending up compiling
this code with aliasing enabled?

------- Comment #2 From Kai Engert (:kaie) (please mail me for urgent issues) 2009-01-07 17:35:37 PST (-) [reply] -------

Adding bryner as he last touched this, according to cvs blame.

------- Comment #3 From David Baron [:dbaron] 2009-01-07 17:54:52 PST (-) [reply] -------

(In reply to comment #0) [that is to comment #34 from this bug -JP]
> all the method return values and all the casts NS_REINTERPRET_CAST, such that

Given that you're referring to NS_REINTERPRET_CAST, which doesn't exist in
Gecko 1.9, I'm wondering if you're using a Gecko version with an nsCOMPtr.h
that doesn't include the fix to bug 351231. (https://bugzilla.mozilla.org/show_bug.cgi?id=351231)

=====end of mozilla.org feedback=====

As I myself do not fully understand comment #34, I believe Jakub should give them an answer. Preferably on the mozilla.org bug but as he has no account over there, I'll copy his answer if it is given here.

One more comment. 

It seems Seamonkey uses a Branch 1.8 version of the file (the trunk is 1.9 now) and they think they already fixed it on the trunk. So I am not certain they will fix it as a future upgrade of Seamonkey to the trunk code will fix it automatically [touch the wood].

closing as upstream

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

seamonkey-1.1.14-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.