Bug 468415 - invalid pointer handling for i386 & -O2 & -fPIC
Summary: invalid pointer handling for i386 & -O2 & -fPIC
Alias: None
Product: Fedora
Classification: Fedora
Component: seamonkey
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
: 478340 479104 479119 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-10-24 16:42 UTC by Need Real Name
Modified: 2018-04-11 09:55 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 498834 (view as bug list)
Last Closed: 2009-01-13 14:28:09 UTC

Attachments (Terms of Use)
paste from gdb session (395 bytes, text/plain)
2008-11-30 11:31 UTC, Giandomenico De Tullio
no flags Details
paste from gdb (thread apply all backtrace) (7.28 KB, text/plain)
2008-11-30 11:32 UTC, Giandomenico De Tullio
no flags Details
From BugBuddy "report" (23.64 KB, text/plain)
2008-11-30 11:34 UTC, Giandomenico De Tullio
no flags Details
Bug Buddy (648.98 KB, text/plain)
2008-12-23 20:30 UTC, Jasper Hartline
no flags Details
GDB Bug Buddy - Additional information provided (24.62 KB, text/plain)
2008-12-23 21:11 UTC, Jasper Hartline
no flags Details
testcase (53.06 KB, application/x-gzip)
2009-01-05 12:42 UTC, Martin Stransky
no flags Details

System ID Priority Status Summary Last Updated
Mozilla Foundation 351231 None None None Never

Description Need Real Name 2008-10-24 16:42:55 UTC
Description of problem:

Seamonkey browser crashes immediately upon loading http://www.lenovo.com, which normally is a "select country" page. Firefox on the same system does not crash on this page. Seamonkey on F9 systems I have access to do not crash in this way.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. start seamonkey
2. enter http://www.lenovo.com into location bar
3. watch browser window disappear
Actual results:

Browser crashes out instantly

Expected results:

Browser renders web page

Additional info:

This is rawhide i386 on an older single-CPU (Pentium M), 512 MB RAM, Dell laptop using the OSS "nv" graphics driver. Other web pages that I tried do load OK, so it is something in the Lenovo website content that is triggering it.

Comment 1 Matěj Cepl 2008-10-25 22:26:55 UTC
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.

Comment 2 Matěj Cepl 2008-11-24 16:18:40 UTC
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.

Comment 3 Bug Zapper 2008-11-26 04:12:03 UTC
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:

Comment 4 Giandomenico De Tullio 2008-11-30 11:31:59 UTC
Created attachment 325116 [details]
paste from gdb session

Comment 5 Giandomenico De Tullio 2008-11-30 11:32:57 UTC
Created attachment 325117 [details]
paste from gdb (thread apply all backtrace)

Comment 6 Giandomenico De Tullio 2008-11-30 11:34:48 UTC
Created attachment 325118 [details]
From BugBuddy "report"

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

Comment 7 Giandomenico De Tullio 2008-11-30 11:35:29 UTC
I have the same problem with:


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

Comment 8 Giandomenico De Tullio 2008-12-07 11:40:50 UTC
news !?

Comment 9 Giandomenico De Tullio 2008-12-11 21:57:56 UTC
news ???

Comment 11 Martin Stransky 2008-12-12 07:50:10 UTC
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

Comment 12 Giandomenico De Tullio 2008-12-12 08:33:53 UTC
(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.

Comment 13 Martin Stransky 2008-12-12 08:41:05 UTC
(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.

Comment 14 Giandomenico De Tullio 2008-12-12 09:35:02 UTC

-  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
# yum install compat-libstdc++-33
Plugin caricati:refresh-packagekit

Fedora10 seamonkey is compiled for libstdc++.so.6


Comment 15 Need Real Name 2008-12-12 14:28:08 UTC
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...

Comment 16 Giandomenico De Tullio 2008-12-12 21:10:20 UTC
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 !!! :(

Comment 17 Martin Stransky 2008-12-14 16:10:46 UTC
I can reproduce it on F10, thanks for the info.

Comment 18 Martin Stransky 2008-12-16 16:51:10 UTC
It seems to be caused by gcc & -O2 optimalization ...still investigating.

Comment 19 Martin Stransky 2008-12-17 12:13:40 UTC
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)

Comment 20 Giandomenico De Tullio 2008-12-18 12:25:06 UTC
Is it fixable ? 
Or the best thing to to is "convert" (someway) seamonkey user profile to  firefox one and remove this seamonkey crap ?! :|

Comment 21 Jasper Hartline 2008-12-23 20:17:49 UTC
I have the same problem with the Seamonkey browser crashing.
Version information:

[root@localhost script]# rpm -q seamonkey
[root@localhost script]# rpm -V seamonkey
[root@localhost script]# rpm -q gcc
[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.

Comment 22 Jasper Hartline 2008-12-23 20:30:36 UTC
Created attachment 327768 [details]
Bug Buddy

Attachment from Bug Buddy 

Comment 23 Jasper Hartline 2008-12-23 21:11:14 UTC
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.

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

Comment 24 Mike 2008-12-27 23:14:11 UTC
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.

Comment 25 Mike 2008-12-28 00:06:35 UTC
I checked that seamonkey-1.1.13-1.fc10.i386 also crashes.

Comment 26 Giandomenico De Tullio 2008-12-28 09:20:26 UTC
(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).

Comment 27 Martin Stransky 2009-01-05 12:42:06 UTC
Created attachment 328192 [details]

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.

Comment 28 Martin Stransky 2009-01-05 12:43:08 UTC
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- --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)

Comment 29 Fedora Update System 2009-01-05 19:50:27 UTC
seamonkey-1.1.14-2.fc10 has been submitted as an update for Fedora 10.

Comment 30 Martin Stransky 2009-01-07 08:47:12 UTC
*** Bug 479104 has been marked as a duplicate of this bug. ***

Comment 31 Fedora Update System 2009-01-07 09:35:41 UTC
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.

Comment 32 Jakub Jelinek 2009-01-07 09:50:08 UTC
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
Once narrowed to one compilation unit, try to find out which function matters and if possible, create a self-contained testcase.

Comment 33 Jakub Jelinek 2009-01-07 09:54:40 UTC
Ah, sorry, I see you've already done that, will look at this later.

Comment 34 Jakub Jelinek 2009-01-07 11:13:15 UTC
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__))
  #define NS_MAY_ALIAS_PTR(t)    t*

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

     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__)) {*,&,...}.

Comment 35 Adam Pribyl 2009-01-07 12:08:45 UTC
Should I fill this then to mozilla.org bugzilla?

Comment 36 Martin Stransky 2009-01-07 12:19:16 UTC
*** Bug 479119 has been marked as a duplicate of this bug. ***

Comment 37 Adam Pribyl 2009-01-07 12:24:00 UTC
Is bug #478340 also a duplicate?

Comment 38 Martin Stransky 2009-01-07 12:29:57 UTC
Thanks for the explanation, moving back to seamonkey...

Comment 39 Kai Engert (:kaie) (inactive account) 2009-01-07 15:28:23 UTC
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.

Comment 40 Jacek Piskozub 2009-01-07 22:46:44 UTC
I filed the Mozilla bug


Comment 41 Jacek Piskozub 2009-01-08 08:31:37 UTC
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@gmail.com 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.

Comment 42 Jacek Piskozub 2009-01-08 08:40:10 UTC
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].

Comment 43 Martin Stransky 2009-01-13 14:28:09 UTC
closing as upstream

Comment 44 Martin Stransky 2009-01-13 14:33:01 UTC
*** Bug 478340 has been marked as a duplicate of this bug. ***

Comment 45 Fedora Update System 2009-01-15 02:51:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.