Bug 506952 (f12ffcrash)

Summary: xulrunner-1.9.1-0.22.beta4.fc12.x86_64 SIGABRTs firefox
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: xulrunnerAssignee: Gecko Maintainer <gecko-bugs-nobody>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: b1r63r, boutilpj, caillon, gecko-bugs-nobody, greenrd, igor.zubkov, jakub, jik, john.ellson, johnp, mattdm, mcepl, nicolas.mailhot, paul, redhat, ruslanpisarev, rwu, sg266, stransky, walters, yaneti, yunus.tji.nyan
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-07 09:26:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proprocessed jshash.cpp
none
preprocessed jsscript.cpp
none
prep. jsatom.cpp
none
prep. jsarea.cpp
none
mozilla hunspell patch none

Description Tom London 2009-06-19 14:04:10 UTC
Description of problem:
After installing xulrunner*-1.9.1-0.22.beta4.fc12.x86_64, firefox immediately SIGABRTs.

Reverting to xulrunner*-1.9.1-0.20.beta4.fc12.x86_64 "fixes".


[tbl@tlondon ~]$ firefox -g
MOZILLA_FIVE_HOME=/usr/lib64/firefox-3.5b4
  LD_LIBRARY_PATH=/usr/lib64/firefox-3.5b4:/usr/lib64/firefox-3.5b4/plugins:/usr/lib64/firefox-3.5b4
DISPLAY=:0.0
FONTCONFIG_PATH=/etc/fonts:/usr/lib64/firefox-3.5b4/res/Xft
DYLD_LIBRARY_PATH=/usr/lib64/firefox-3.5b4:/usr/lib64/firefox-3.5b4
     LIBRARY_PATH=/usr/lib64/firefox-3.5b4:/usr/lib64/firefox-3.5b4/components:/usr/lib64/firefox-3.5b4
       SHLIB_PATH=/usr/lib64/firefox-3.5b4:/usr/lib64/firefox-3.5b4
          LIBPATH=/usr/lib64/firefox-3.5b4:/usr/lib64/firefox-3.5b4
       ADDON_PATH=/usr/lib64/firefox-3.5b4
      MOZ_PROGRAM=/usr/lib64/firefox-3.5b4/firefox
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
which: no ddd in (/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/tbl/bin)
/usr/bin/gdb /usr/lib64/firefox-3.5b4/firefox -x /tmp/mozargs.Ot2vAV
GNU gdb (GDB) Fedora (6.8.50.20090302-33.fc12)
Copyright (C) 2009 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Missing separate debuginfo for /usr/lib64/firefox-3.5b4/firefox
Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/f0/15276a8ecf80f380c92c9475547eea1729f199.debug
(gdb) run
Starting program: /usr/lib64/firefox-3.5b4/firefox 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef8ff910 (LWP 7782)]
[New Thread 0x7fffeeefe910 (LWP 7783)]
[New Thread 0x7fffee4fd910 (LWP 7784)]
*** buffer overflow detected ***: /usr/lib64/firefox-3.5b4/firefox terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x39ca0f7537]
/lib64/libc.so.6[0x39ca0f5590]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff78bf686]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff78bf77e]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff78bf972]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff786d93b]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff786db13]
/usr/lib64/xulrunner-1.9.1/libmozjs.so[0x7ffff78adc8e]
/usr/lib64/xulrunner-1.9.1/libmozjs.so(JS_CompileUCScriptForPrincipals+0x6c)[0x7ffff7853af1]
/usr/lib64/xulrunner-1.9.1/libmozjs.so(JS_CompileScriptForPrincipals+0x56)[0x7ffff785692b]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6686ab7]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6687e70]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6efb3b4]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6efb74a]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6efb85d]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff6efc6bc]
/usr/lib64/xulrunner-1.9.1/libxul.so(NS_InitXPCOM3_P+0x831)[0x7ffff6ed6ad0]
/usr/lib64/xulrunner-1.9.1/libxul.so[0x7ffff661a568]
/usr/lib64/xulrunner-1.9.1/libxul.so(XRE_main+0x27d1)[0x7ffff661d9c5]
/usr/lib64/firefox-3.5b4/firefox[0x4022ab]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x39ca01ea2d]
/usr/lib64/firefox-3.5b4/firefox[0x401c59]
======= Memory map: ========
00400000-00415000 r-xp 00000000 fd:00 53741                              /usr/lib64/firefox-3.5b4/firefox
00614000-00615000 rw-p 00014000 fd:00 53741                              /usr/lib64/firefox-3.5b4/firefox
00615000-00616000 rw-p 00000000 00:00 0 
00814000-00816000 rw-p 00014000 fd:00 53741                              /usr/lib64/firefox-3.5b4/firefox
3098800000-3098c4b000 r-xp 00000000 fd:00 53193                          /usr/lib64/libgtk-x11-2.0.so.0.1702.0
3098c4b000-3098e4a000 ---p 0044b000 fd:00 53193                          /usr/lib64/libgtk-x11-2.0.so.0.1702.0
3098e4a000-3098e55000 rw-p 0044a000 fd:00 53193                          /usr/lib64/libgtk-x11-2.0.so.0.1702.0
3098e55000-3098e57000 rw-p 00000000 00:00 0 
3099000000-30990a9000 r-xp 00000000 fd:00 53192                          /usr/lib64/libgdk-x11-2.0.so.0.1702.0
30990a9000-30992a9000 ---p 000a9000 fd:00 53192                          /usr/lib64/libgdk-x11-2.0.so.0.1702.0
30992a9000-30992ae000 rw-p 000a9000 fd:00 53192                          /usr/lib64/libgdk-x11-2.0.so.0.1702.0
3099400000-309940b000 r-xp 00000000 fd:00 53189                          /usr/lib64/libpangocairo-1.0.so.0.2400.2
309940b000-309960a000 ---p 0000b000 fd:00 53189                          /usr/lib64/libpangocairo-1.0.so.0.2400.2
309960a000-309960b000 rw-p 0000a000 fd:00 53189                          /usr/lib64/libpangocairo-1.0.so.0.2400.2
3099800000-3099876000 r-xp 00000000 fd:00 12549                          /usr/lib64/libcairo.so.2.10800.8
3099876000-3099a76000 ---p 00076000 fd:00 12549                          /usr/lib64/libcairo.so.2.10800.8
3099a76000-3099a79000 rw-p 00076000 fd:00 12549                          /usr/lib64/libcairo.so.2.10800.8
309b000000-309b007000 r-xp 00000000 fd:00 59648                          /usr/lib64/libgailutil.so.18.0.1
309b007000-309b206000 ---p 00007000 fd:00 59648                          /usr/lib64/libgailutil.so.18.0.1
309b206000-309b207000 rw-p 00006000 fd:00 59648                          /usr/lib64/libgailutil.so.18.0.1
309b400000-309b433000 r-xp 00000000 fd:00 59649                          /usr/lib64/libgnomecanvas-2.so.0.2600.0
309b433000-309b633000 ---p 00033000 fd:00 59649                          /usr/lib64/libgnomecanvas-2.so.0.2600.0
309b633000-309b635000 rw-p 00033000 fd:00 59649                          /usr/lib64/libgnomecanvas-2.so.0.2600.0
309b800000-309b86a000 r-xp 00000000 fd:00 59650                          /usr/lib64/libbonoboui-2.so.0.0.0
309b86a000-309ba69000 ---p 0006a000 fd:00 59650                          /usr/lib64/libbonoboui-2.so.0.0.0
309ba69000-309ba6e000 rw-p 00069000 fd:00 59650                          /usr/lib64/libbonoboui-2.so.0.0.0
309bc00000-309bc0d000 r-xp 00000000 fd:00 55082                          /usr/lib64/libtdb.so.1.1.5
309bc0d000-309be0c000 ---p 0000d000 fd:00 55082                          /usr/lib64/libtdb.so.1.1.5
309be0c000-309be0d000 rw-p 0000c000 fd:00 55082                          /usr/lib64/libtdb.so.1.1.5
309c400000-309c403000 r-xp 00000000 fd:00 15624                          /usr/lib64/libcanberra-gtk.so.0.0.5
309c403000-309c603000 ---p 00003000 fd:00 15624                          /usr/lib64/libcanberra-gtk.so.0.0.5
309c603000-309c604000 rw-p 00003000 fd:00 15624                          /usr/lib64/libcanberra-gtk.so.0.0.5
309c800000-309c80f000 r-xp 00000000 fd:00 59667                          /usr/lib64/libcanberra.so.0.1.5
309c80f000-309ca0e000 ---p 0000f000 fd:00 59667                          /usr/lib64/libcanberra.so.0.1.5
309ca0e000-309ca0f000 rw-p 0000e000 fd:00 59667                          /usr/lib64/libcanberra.so.0.1.5
309d400000-309d495000 r-xp 00000000 fd:00 59651                          /usr/lib64/libgnomeui-2.so.0.2400.1
309d495000-309d694000 ---p 00095000 fd:00 59651                          /usr/lib64/libgnomeui-2.so.0.2400.1
309d694000-309d69a000 rw-p 00094000 fd:00 59651                          /usr/lib64/libgnomeui-2.so.0.2400.1
31d9c00000-31d9c19000 r-xp 00000000 fd:00 105879                         /lib64/libnssutil3.so
31d9c19000-31d9e18000 ---p 00019000 fd:00 105879                         /lib64/libnssutil3.so
31d9e18000-31d9e1d000 rw-p 00018000 fd:00 105879                         /lib64/libnssutil3.so
31d9e1d000-31d9e1e000 rw-p 00000000 00:00 0 
31da000000-31da12a000 r-xp 00000000 fd:00 105988                         /lib64/libnss3.so
31da12a000-31da329000 ---p 0012a000 fd:00 105988                         /lib64/libnss3.so
31da329000-31da330000 rw-p 00129000 fd:00 105988                         /lib64/libnss3.so
31da330000-31da331000 rw-p 00000000 00:00 0 
31da400000-31da427000 r-xp 00000000 fd:00 112228                         /lib64/libsmime3.so
31da427000-31da626000 ---p 00027000 fd:00 112228                         /lib64/libsmime3.so
31da626000-31da62a000 rw-p 00026000 fd:00 112228                         /lib64/libsmime3.so
31da800000-31da82d000 r-xp 00000000 fd:00 112227                         /lib64/libssl3.so
31da82d000-31daa2d000 ---p 0002d000 fd:00 112227                         /lib64/libssl3.so
31daa2d000-31daa2f000 rw-p 0002d000 fd:00 112227                         /lib64/libssl3.so
31daa2f000-31daa30000 rw-p 00000000 00:00 0 
334f200000-334f204000 r-xp 00000000 fd:00 15720                          /lib64/libcap.so.2.16
334f204000-334f403000 ---p 00004000 fd:00 15720                          /lib64/libcap.so.2.16
334f403000-334f404000 rw-p 00003000 fd:00 15720                          /lib64/libcap.so.2.16
334f600000-334f63d000 r-xp 00000000 fd:00 19585                          /lib64/libdbus-1.so.3.4.0
334f63d000-334f83c000 ---p 0003d000 fd:00 19585                          /lib64/libdbus-1.so.3.4.0
334f83c000-334f83d000 r--p 0003c000 fd:00 19585                          /lib64/libdbus-1.so.3.4.0
334f83d000-334f83e000 rw-p 0003d000 fd:00 19585                          /lib64/libdbus-1.so.3.4.0
334fa00000-334fa1e000 r-xp 00000000 fd:00 27851                          /usr/lib64/libgdk_pixbuf-2.0.so.0.1702.0
334fa1e000-334fc1e000 ---p 0001e000 fd:00 27851                          /usr/lib64/libgdk_pixbuf-2.0.so.0.1702.0
334fc1e000-334fc1f000 rw-p 0001e000 fd:00 27851                          /usr/lib64/libgdk_pixbuf-2.0.so.0.1702.0
3350a00000-3350a26000 r-xp 00000000 fd:00 29613                          /usr/lib64/libdbus-glib-1.so.2.1.0
3350a26000-3350c25000 ---p 00026000 fd:00 29613                          /usr/lib64/libdbus-glib-1.so.2.1.0
3350c25000-3350c27000 rw-p 00025000 fd:00 29613                          /usr/lib64/libdbus-glib-1.so.2.1.0
3350e00000-3350e3b000 r-xp 00000000 fd:00 29798                          /usr/lib64/
Program received signal SIGABRT, Aborted.
0x00000039ca0332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Current language:  auto; currently minimal
Missing separate debuginfos, use: debuginfo-install e2fsprogs-libs-1.41.6-5.fc12.x86_64 libXi-1.2.99-2.20090619.fc12.x86_64 pixman-0.15.12-1.fc12.x86_64
(gdb) where
#0  0x00000039ca0332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00000039ca034b20 in *__GI_abort () at abort.c:88
#2  0x00000039ca07005d in __libc_message (do_abort=2, 
    fmt=0x7fffffff8da0 "4fc1f000 rw-p 0001e000 fd:00 27851", ' ' <repeats 26 times>, "/usr/lib64/libgdk_pixbuf-2.0.so.0.1702.0\n3350a00000-3350a26000 r-xp 00000000 fd:00 29613", ' ' <repeats 26 times>, "/usr/lib64/libdbus-glib-1."...)
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#3  0x00000039ca0f7537 in *__GI___fortify_fail (msg=0x39ca13436f "buffer overflow detected") at fortify_fail.c:32
#4  0x00000039ca0f5590 in *__GI___chk_fail () at chk_fail.c:29
#5  0x00007ffff78bf686 in strcpy (__src=<value optimized out>, __dest=<value optimized out>)
    at /usr/include/bits/string3.h:106
#6  SaveScriptFilename (__src=<value optimized out>, __dest=<value optimized out>) at jsscript.cpp:1104
#7  0x00007ffff78bf77e in js_SaveScriptFilename (cx=0x7ffff7bbd000, 
    filename=0x7ffff7c3bb88 "file:///usr/lib64/xulrunner-1.9.1/components/nsSearchSuggestions.js") at jsscript.cpp:1169
#8  0x00007ffff78bf972 in js_NewScriptFromCG (cx=0x7ffff7bbd000, cg=0x7fffeffb1a20) at jsscript.cpp:1491
#9  0x00007ffff786d93b in js_EmitFunctionScript (cx=0x7ffff7bbd000, cg=0x7fffeffb1a20, body=0x7fffeffb3298)
    at jsemit.cpp:3476
#10 0x00007ffff786db13 in js_EmitTree (cx=0x7ffff7bbd000, cg=0x7fffffff9730, pn=0x7fffeffb3378) at jsemit.cpp:4281
#11 0x00007ffff78adc8e in JSCompiler::compileScript (cx=0x7ffff7bbd000, scopeChain=<value optimized out>, 
    callerFrame=<value optimized out>, principals=<value optimized out>, tcflags=<value optimized out>, 
    chars=<value optimized out>, length=24228, file=0x0, 
    filename=0x7ffff7c3bb88 "file:///usr/lib64/xulrunner-1.9.1/components/nsSearchSuggestions.js", lineno=1, source=0x0)
    at jsparse.cpp:882
#12 0x00007ffff7853af1 in JS_CompileUCScriptForPrincipals (cx=0x7ffff7bbd000, obj=0x1e63, 
---Type <return> to continue, or q <return> to quit---
    principals=<value optimized out>, chars=<value optimized out>, length=<value optimized out>, 
    filename=<value optimized out>, lineno=1) at jsapi.cpp:4707
#13 0x00007ffff785692b in JS_CompileScriptForPrincipals (cx=0x7ffff7bbd000, obj=0x7fffeff64340, principals=0x7fffeff9bd08, 
    bytes=<value optimized out>, length=24228, filename=<value optimized out>, lineno=1) at jsapi.cpp:4662
#14 0x00007ffff6686ab7 in mozJSComponentLoader::GlobalForLocation (this=0x7ffff7c54370, aComponent=0x7ffff7ceebc0, 
    aGlobal=<value optimized out>, aLocation=<value optimized out>, exception=<value optimized out>)
    at mozJSComponentLoader.cpp:1304
#15 0x00007ffff6687e70 in mozJSComponentLoader::LoadModule (this=0x7ffff7c54370, aComponentFile=0x7ffff7ceebc0, 
    aResult=0x7fffffffa130) at mozJSComponentLoader.cpp:691
#16 0x00007ffff6efb3b4 in nsComponentManagerImpl::AutoRegisterComponent (this=0x7ffff7cc0520, 
    aComponentFile=0x7ffff7ceebc0, aDeferred=<value optimized out>, minLoader=0) at nsComponentManager.cpp:3042
#17 0x00007ffff6efb74a in nsComponentManagerImpl::AutoRegisterDirectory (this=0x7ffff7cc0520, 
    inDirSpec=<value optimized out>, aLeftovers=@0x7fffffffa3e0, aDeferred=@0x7fffffffa3d0) at nsComponentManager.cpp:2957
#18 0x00007ffff6efb85d in nsComponentManagerImpl::AutoRegisterImpl (this=0x7ffff7cc0520, inDirSpec=0x7ffff7cee2c0, 
    aLeftovers=@0x7fffffffa3e0, aDeferred=@0x7fffffffa3d0) at nsComponentManager.cpp:2916
#19 0x00007ffff6efc6bc in nsComponentManagerImpl::AutoRegister (this=0x7ffff7cc0520, aSpec=0x0)
    at nsComponentManager.cpp:3322
#20 0x00007ffff6ed6ad0 in NS_InitXPCOM3_P(struct nsIServiceManager **, struct nsIFile *, struct nsIDirectoryServiceProvider *, const nsStaticModuleInfo *, PRUint32) (result=0x7ffff77e5890, binDirectory=<value optimized out>, 
    appFileLocationProvider=0x7fffffffa4b8, staticComponents=<value optimized out>, componentCount=52)
    at nsXPComInit.cpp:688
#21 0x00007ffff661a568 in ScopedXPCOMStartup::Initialize (this=0x7fffffffa9c0) at nsAppRunner.cpp:1008
#22 0x00007ffff661d9c5 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
    at nsAppRunner.cpp:3091
#23 0x00000000004022ab in mmap ()
#24 0x00000039ca01ea2d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, 
    ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fffffffdf78) at libc-start.c:220
#25 0x0000000000401c59 in mmap ()
#26 0x00007fffffffdf78 in ?? ()
#27 0x000000000000001c in ?? ()
#28 0x0000000000000001 in ?? ()
#29 0x00007fffffffe2c7 in ?? ()
#30 0x0000000000000000 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and kill it)? (y or n) y
[tbl@tlondon ~]$ 


Version-Release number of selected component (if applicable):
xulrunner-1.9.1-0.22.beta4.fc12.x86_64.rpm (and -devel)
firefox-3.5-0.21.beta4.fc12.x86_64

How reproducible:
Every time

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Patrick Boutilier 2009-06-20 12:18:29 UTC
Confirmed. Same problem here.

Comment 2 Steve 2009-06-20 15:38:33 UTC
Confirmed in 32-bit.

Comment 3 Yanko Kaneti 2009-06-21 14:36:41 UTC
*** Bug 507118 has been marked as a duplicate of this bug. ***

Comment 4 Matěj Cepl 2009-06-22 07:01:18 UTC
There are rumours (http://thread.gmane.org/gmane.linux.redhat.fedora.testers/73468), that this is a gcc problem. Jakub?

Comment 5 Jakub Jelinek 2009-06-22 07:21:22 UTC
Rumors, no proofs.
What is true is that I've extended -D_FORTIFY_SOURCE to check cases it didn't check before.  In gcc-4.4.0-{7,8} there has been a bug in it, so if a package has been built with one of these, it is very possible it fails and needs to be recompiled.  But if it still happens after being recompiled with gcc-4.4.0-9 and above, then it is either a package bug, or of course could still be a gcc bug.
I can look at it, but need for that:
1) preprocessed source in which this happens (in the case above jsscript.cpp)
2) exact gcc options it has been compiled with
3) some info from the debugger, how long the string being copied is
Kernel AFAIK doesn't use -D_FORTIFY_SOURCE (or has that changed?), so this shouldn't have anything to do with the kernel, and there haven't been any substantial changes in gcc since F11.

Comment 6 Martin Stransky 2009-06-22 09:12:32 UTC
Hm, seems to be here:

/* NB: This struct overlays JSHashEntry -- see jshash.h, do not reorganize. */
typedef struct ScriptFilenameEntry {
    JSHashEntry         *next;          /* hash chain linkage */
    JSHashNumber        keyHash;        /* key hash function result */
    const void          *key;           /* ptr to filename, below */
    uint32              flags;          /* user-defined filename prefix flags */
    JSPackedBool        mark;           /* GC mark flag */
    char                filename[3];    /* two or more bytes, NUL-terminated */
} ScriptFilenameEntry;

in jsscript.cpp:

ScriptFilenameEntry *sfe;

1104:  sfe->key = strcpy(sfe->filename, filename);

Can strcpy -> strncpy switch fix the fortify issue?

Comment 7 Jakub Jelinek 2009-06-22 09:28:51 UTC
This is not a self-contained testcase.  For
struct S
{
  void *p;
  int j;
  char b[3];
};

struct S *s;

int foo (void)
{
  return __builtin_object_size (s->b, 1);
}
gcc -O2 returns (size_t) -1, i.e. it doesn't know anything.
For
int bar (void)
{
  struct S *t = __builtin_malloc (sizeof (struct S));
  return __builtin_object_size (t->b, 1);
}
it returns 4 (still not 3, as the last field is assumed to be kind of poor man's
flexible array member and there is 1 byte padding at the end of the struct).
It is important to know if sfe above is an automatic variable or not and if gcc has a chance to find out what it points to and whether it could have been clobbered somewhere between the initialization and where object size is queried (e.g. from strcpy).

Comment 8 Martin Stransky 2009-06-22 09:57:05 UTC
ScriptFilenameEntry *sfe is an automatic variable.

The code is:

  sfe = (ScriptFilenameEntry *)
         JS_HashTableRawAdd(table, hep, hash, filename, NULL);
  if (!sfe)
      return NULL;
  sfe->key = strcpy(sfe->filename, filename);
  sfe->flags = 0;
  sfe->mark = JS_FALSE;

and:

JS_HashTableRawAdd(JSHashTable *ht, JSHashEntry **hep,
                   JSHashNumber keyHash, const void *key, void *value)
{
    [...]

    /* Make a new key value entry */
    he = ht->allocOps->allocEntry(ht->allocPriv, key);
    if (!he)
        return NULL;
    he->keyHash = keyHash;
    he->key = key; 
    he->value = value;
    he->next = *hep;
    *hep = he;
    ht->nentries++;
    return he;
}

I'm going to find out what's behind "allocOps->allocEntry()", looks like some private allocator.

Comment 9 Jakub Jelinek 2009-06-22 10:05:42 UTC
Just to make sure, are you sure you can reproduce it when this code is compiled with gcc 4.4.0-9?

Comment 10 Martin Stransky 2009-06-22 10:11:49 UTC
I can't reproduce it with my current 4.4.0-4 (F11). Shall I update it and retest?

Comment 11 Martin Stransky 2009-06-22 10:25:44 UTC
ht->allocOps->allocEntry returns pointers to memory areas allocated by malloc.

Comment 12 Jakub Jelinek 2009-06-22 10:30:45 UTC
Just check if the rawhide xulrunner or whatever else owns the library that called strcpy which triggered __fortify_fail has been built with gcc-4.4.0-{7,8} (koji should know, look at root.log) and if yes, rebuild it.

Comment 13 Martin Stransky 2009-06-22 10:40:12 UTC
The affected package (xulrunner*-1.9.1-0.22.beta4.fc12.x86_64) was built with gcc 4.4.0-9 (http://kojipkgs.fedoraproject.org/packages/xulrunner/1.9.1/0.22.beta4.fc12/data/logs/i586/root.log)

The working one (xulrunner*-1.9.1-0.20.beta4.fc12.x86_64) was built with gcc 4.4.0-3 
(http://kojipkgs.fedoraproject.org/packages/xulrunner/1.9.1/0.20.beta4.fc12/data/logs/i586/root.log)

Comment 14 Jakub Jelinek 2009-06-22 11:05:16 UTC
In that case, please attach preprocessed source and exact gcc cmdline options used to compile it.  I'll have a look.  And, try to find out how long the filename passed to strcpy actually is.

Comment 15 Martin Stransky 2009-06-22 13:01:00 UTC
*** Bug 507345 has been marked as a duplicate of this bug. ***

Comment 16 Martin Stransky 2009-06-22 13:29:30 UTC
Created attachment 348895 [details]
proprocessed jshash.cpp

Comment 17 Martin Stransky 2009-06-22 13:30:23 UTC
Created attachment 348896 [details]
preprocessed jsscript.cpp

Comment 18 Martin Stransky 2009-06-22 13:34:46 UTC
Created attachment 348897 [details]
prep. jsatom.cpp

Comment 19 Martin Stransky 2009-06-22 13:36:19 UTC
Created attachment 348898 [details]
prep. jsarea.cpp

Comment 20 Martin Stransky 2009-06-22 13:43:16 UTC
ht->allocOps->allocEntry can points to:

js_alloc_sftbl_entry
js_alloc_temp_entry

-----------------------------------------------------

js_alloc_sftbl_entry(void *priv, const void *key)
{
    size_t nbytes = __builtin_offsetof (ScriptFilenameEntry, filename) +
                    strlen((const char *) key) + 1;

    return (JSHashEntry *) malloc(((nbytes)>(sizeof(JSHashEntry))?(nbytes):(sizeof(JSHashEntry))));
}

-----------------------------------------------------
static JSHashEntry *
js_alloc_temp_entry(void *priv, const void *key)
{
    JSCompiler *jsc = (JSCompiler *) priv;
    JSAtomListElement *ale;

    ale = jsc->aleFreeList;
    if (ale) {
        jsc->aleFreeList = ((JSAtomListElement *) (ale)->entry.next);
        return &ale->entry;
    }

    do { JSArena *_a = (&jsc->context->tempPool)->current; size_t _nb = (((jsuword)(sizeof(JSAtomListElement)) + (&jsc->context->tempPool)->mask) & ~(&jsc->context->tempPool)->mask); jsuword _p = _a->avail; if ((0) || _p > _a->limit - _nb) _p = (jsuword)JS_ArenaAllocate(&jsc->context->tempPool, _nb); else _a->avail = _p + _nb; ale = (JSAtomListElement *) _p; ; } while (0);
    if (!ale) {
        js_ReportOutOfScriptQuota(jsc->context);
        return __null;
    }
    return &ale->entry;
}

and JS_ArenaAllocate() is in jsarena file:

__attribute__((visibility ("default"))) void *
JS_ArenaAllocate(JSArenaPool *pool, size_t nb);

-----------------------------------------------------

Comment 21 Martin Stransky 2009-06-22 13:47:17 UTC
gcc i586 flags:

c++ -fPIC-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -fstrict-aliasing

Comment 22 Matěj Cepl 2009-06-22 13:58:56 UTC
Still not sure whether it is gcc or firefox bug, but certainly it is way above bug triaging.

Comment 23 Yanko Kaneti 2009-06-22 14:49:01 UTC
*** Bug 507372 has been marked as a duplicate of this bug. ***

Comment 24 Jakub Jelinek 2009-06-22 23:15:39 UTC
Ah,
typedef __SIZE_TYPE__ size_t;

typedef struct S
{
  int i, j, k;
  char buf[3];
} T;

__attribute__((noinline)) void
foo (T *t)
{
  if (__builtin_object_size (&t->buf[0], 1) != (size_t) -1)
    __builtin_abort ();
  if (__builtin_object_size (&t->buf, 1) != (size_t) -1)
    __builtin_abort ();
}

int
main ()
{
  T t;
  foo (&t);
}
at -O2 only works with gcc, but not g++, as C++ inserts TYPE_DECL after the buf's FIELD_DECL.  So the check for last field should just walk that FIELD_DECL's TREE_CHAIN, looking for FIELD_DECLs, instead of checking that TREE_CHAIN is non-NULL.

Comment 25 Jonathan Kamens 2009-06-23 15:50:27 UTC
Rather than converting this into a gcc bug, shouldn't there be a separate gcc bug, with the xulrunner bug remaining as an xulrunner bug so that we remember to recompile a new xulrunner RPM when the gcc bug is fixed?

Or is it moot because we're going to have to recompile everything once the gcc bug is fixed?

Comment 26 Matěj Cepl 2009-06-23 17:14:42 UTC
(In reply to comment #25)
> Rather than converting this into a gcc bug, shouldn't there be a separate gcc
> bug, with the xulrunner bug remaining as an xulrunner bug so that we remember
> to recompile a new xulrunner RPM when the gcc bug is fixed?

Don't worry that Firefox maintainers are watching this bug carefully. They are.

Comment 27 Matěj Cepl 2009-06-23 17:14:59 UTC
(In reply to comment #25)
> Rather than converting this into a gcc bug, shouldn't there be a separate gcc
> bug, with the xulrunner bug remaining as an xulrunner bug so that we remember
> to recompile a new xulrunner RPM when the gcc bug is fixed?

Don't worry that Firefox maintainers are not watching this bug carefully. They are.

Comment 28 Jakub Jelinek 2009-06-23 23:15:48 UTC
Please rebuild xulrunner with gcc-4.4.0-10 in rawhide.

Comment 29 Martin Stransky 2009-06-24 10:40:35 UTC
rebuild in xulrunner-1.9.1-0.23.beta4.fc12

Comment 30 Yanko Kaneti 2009-06-24 11:40:25 UTC
fixed the startup crash for me but I get reproducible fortify fail opening this particular bugreport. (Logged in , hence with the comments box present and that hunspell stuff you can see below)
......

#3  0x0000003ccf6f7537 in *__GI___fortify_fail (
    msg=0x3ccf73436f "buffer overflow detected") at fortify_fail.c:32
#4  0x0000003ccf6f5590 in *__GI___chk_fail () at chk_fail.c:29
#5  0x00007ffff1537c12 in strcpy (__src=<value optimized out>, 
    __dest=<value optimized out>) at /usr/include/bits/string3.h:106
#6  HashMgr::add_word (__src=<value optimized out>, __dest=<value optimized out>)
    at hashmgr.cpp:191
#7  0x00007ffff1538313 in HashMgr::load_tables (this=0x324a430, 
    tpath=<value optimized out>, key=<value optimized out>) at hashmgr.cpp:527
#8  0x00007ffff1538473 in HashMgr::HashMgr (this=0x324a430, 
    tpath=0x7fffffff9360 "/usr/lib64/xulrunner-1.9.1/dictionaries/en_ZW.dic", 
    apath=<value optimized out>, key=0x0) at hashmgr.cpp:105
#9  0x00007ffff153cae5 in Hunspell::Hunspell (this=0x324a340, 
    affpath=0x3912d38 "/usr/lib64/xulrunner-1.9.1/dictionaries/en_ZW.aff", 
    dpath=0x7fffffff9360 "/usr/lib64/xulrunner-1.9.1/dictionaries/en_ZW.dic", key=0x0)
    at hunspell.cpp:87
#10 0x00007ffff1527ef2 in mozHunspell::SetDictionary (this=0x39d11d0, 
    aDictionary=<value optimized out>) at mozHunspell.cpp:157
#11 0x00007ffff151e737 in mozSpellChecker::SetCurrentDictionary (this=0x324a2b0, 
    aDictionary=@0x7fffffff9470) at mozSpellChecker.cpp:373
#12 0x00007ffff140afef in nsEditorSpellCheck::SetCurrentDictionary (
    this=<value optimized out>, aDictionary=<value optimized out>)
    at nsEditorSpellCheck.cpp:455
#13 0x00007ffff140c0e0 in nsEditorSpellCheck::InitSpellChecker (this=0x39d0e20, 
    aEditor=0x7ffff0dbeb3c, aEnableSelectionChecking=0) at nsEditorSpellCheck.cpp:212
#14 0x00007ffff1522fba in mozInlineSpellChecker::SetEnableRealTimeSpell (this=0x39cd190, 
    aEnabled=<value optimized out>) at mozInlineSpellChecker.cpp:726
#15 0x00007ffff116072e in nsEditor::SyncRealTimeSpell (this=0x2dcc390)
    at nsEditor.cpp:1341
#16 0x00007ffff115976b in nsEditor::PostCreate (this=0x228e) at nsEditor.cpp:246
.....

Comment 31 Jakub Jelinek 2009-06-24 12:18:40 UTC
struct hentry
{
  unsigned char blen; // word length in bytes
  unsigned char clen; // word length in characters (different for UTF-8 enc.)
  short    alen;      // length of affix flag vector
  unsigned short * astr;  // affix flag vector
  struct   hentry * next; // next word with same hash code
  struct   hentry * next_homonym; // next homonym word (with same hash code)
  char     var;       // variable fields (only for special pronounciation yet)
  char     word;      // variable-length word (8-bit or UTF-8 encoding)
};
...
    // variable-length hash record with word and optional fields
    struct hentry* hp = 
        (struct hentry *) malloc (sizeof(struct hentry) + wbl + descl);
    if (!hp) return 1;
    char * hpw = &(hp->word);
    strcpy(hpw, word);

That's intentionally not allowed with -D_FORTIFY_SOURCE=2, which doesn't allow crossing field boundaries for str*/stp* etc. functions (and still allows that for mem* etc.).  Change that to char word[1];, or char word[];, or char word[0].
In the latter two cases (flexible array member and zero length) you obviously need to check all the allocations, because sizeof(struct hentry) will decrease by 1, in the first case not.  Only arrays as last fields are flexible array members or handled as poor alternatives to flexible array members by gcc.

Comment 32 Yanko Kaneti 2009-06-24 13:07:26 UTC
I've cloned parts of this bug as hunspell bug 507829. The private xulrunner/mozilla copy is mostly identical to hunspell 1.2.8.

Comment 33 Yanko Kaneti 2009-06-25 03:17:43 UTC
*** Bug 507558 has been marked as a duplicate of this bug. ***

Comment 34 Yanko Kaneti 2009-06-25 14:50:16 UTC
Created attachment 349408 [details]
mozilla hunspell patch

This is Caolan McNamara's hunspell patch applied and rediffed over the private hunspell copy in mozilla/xulrunner. It also applies to mozilla trunk.

Or just +ac_add_options --enable-system-hunspell

Both cure that last fortify fail.

Comment 35 Martin Stransky 2009-06-25 14:55:47 UTC
Is the patch documented somewhere? Or rather, is it a part of any hunspell update? We need to propagate the patch to mozilla...

Comment 36 Yanko Kaneti 2009-06-25 15:09:42 UTC
See the hunspell bug. It was patched and built in koji yesterday, its in todays rawhide. Caolan filled 
http://sourceforge.net/tracker/?func=detail&aid=2812045&group_id=143754&atid=756397

Comment 37 Martin Stransky 2009-06-26 06:59:46 UTC
Filled upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=500607

Comment 38 Steve 2009-06-26 07:02:56 UTC
Fixed for me now.

Comment 39 Martin Stransky 2009-06-26 07:26:09 UTC
Closing as UPSTREAM.

Comment 41 Yanko Kaneti 2009-06-30 22:36:26 UTC
*** Bug 508773 has been marked as a duplicate of this bug. ***

Comment 42 Matěj Cepl 2009-06-30 23:35:26 UTC
*** Bug 508582 has been marked as a duplicate of this bug. ***

Comment 43 birger 2009-07-03 17:32:53 UTC
Seems stable again here as well.