Closed Bug 208983 Opened 21 years ago Closed 11 years ago

Assertion failure in PL_DHashTableSetAlphaBounds()

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: kazhik, Unassigned)

Details

Assertion failure occurs in PL_DHashTableSetAlphaBounds()
when executing with -g.

****************************************
dist/bin/run-mozilla.sh -g dist/bin/mozilla-bin
MOZILLA_FIVE_HOME=/home/work/1.4/mozilla/dist/bin
 
LD_LIBRARY_PATH=/home/work/1.4/mozilla/dist/bin:/home/work/1.4/mozilla/dist/bin/plugins:/usr/local/lib/mre/mre-1.4
DISPLAY=:0.0
FONTCONFIG_PATH=/etc/fonts:/home/work/1.4/mozilla/dist/bin/res/Xft
DYLD_LIBRARY_PATH=/home/work/1.4/mozilla/dist/bin:/usr/local/lib/mre/mre-1.4
    
LIBRARY_PATH=/home/work/1.4/mozilla/dist/bin:/home/work/1.4/mozilla/dist/bin/components:/usr/local/lib/mre/mre-1.4
       SHLIB_PATH=/home/work/1.4/mozilla/dist/bin:/usr/local/lib/mre/mre-1.4
          LIBPATH=/home/work/1.4/mozilla/dist/bin:/usr/local/lib/mre/mre-1.4
       ADDON_PATH=/home/work/1.4/mozilla/dist/bin
      MOZ_PROGRAM=dist/bin/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/bin/gdb dist/bin/mozilla-bin -x /tmp/mozargs19122
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /home/work/1.4/mozilla/dist/bin/mozilla-bin 
Warning: MOZILLA_FIVE_HOME not set.
Warning: MOZILLA_FIVE_HOME not set.
[New Thread 1024 (LWP 19134)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 19134)]
0x403fe951 in __kill () from /lib/libc.so.6
Current language:  auto; currently c
(gdb) bt
#0  0x403fe951 in __kill () from /lib/libc.so.6
#1  0x400fa01b in raise (sig=6) at signals.c:65
#2  0x403ffd91 in abort () at ../sysdeps/generic/abort.c:88
#3  0x400bd1c7 in Letext () at prlog.c:516
#4  0x4074c98f in PL_DHashTableSetAlphaBounds (table=0x80bb1bc, 
    maxAlpha=0.875, minAlpha=-NaN(0x400000)) at pldhash.c:227
#5  0x40786394 in nsComponentManagerImpl::Init (this=0x80bb190)
    at nsComponentManager.cpp:748
#6  0x4074ba2c in NS_InitXPCOM2 (result=0xbffff488, binDirectory=0x0, 
    appFileLocationProvider=0x80cda68) at nsXPComInit.cpp:468
#7  0x0807529b in NS_InitXPCOM2 (result=0xbffff488, binDirectory=0x0, 
    appFileLocationProvider=0x80cda68) at nsXPCOMGlue.cpp:136
#8  0x080755de in GRE_Startup () at nsXPCOMGlue.cpp:240
#9  0x08066a8a in main (argc=1, argv=0xbffff534) at nsAppRunner.cpp:1572
#10 0x403ed13f in __libc_start_main (main=0x8066a2c <main>, argc=1, 
    ubp_av=0xbffff534, init=0x8062658 <_init>, fini=0x808ea08 <_fini>, 
    rtld_fini=0x4000c770 <_dl_fini>, stack_end=0xbffff52c)
    at ../sysdeps/generic/libc-start.c:129
(gdb)
****************************************
brendan, any ideas?  
This seems like a dup of something Seth was tracking.

It's easy to analyze:

#4  0x4074c98f in PL_DHashTableSetAlphaBounds (table=0x80bb1bc, 
    maxAlpha=0.875, minAlpha=-NaN(0x400000)) at pldhash.c:227
#5  0x40786394 in nsComponentManagerImpl::Init (this=0x80bb190)
    at nsComponentManager.cpp:748

minAlpha in frame #4 is indeed insane, a NaN value.  The call site from frame #5
is passing PL_DHASH_MIN_ALPHA(&mFactories, 2) as minAlpha.  How could that macro
 evaluate to NaN?  Probably only if mFactories has zero entrySize, which means
it has not been initialized.  Even then, with k=2 I would expect 0f/2 => 0f, not
NaN, but perhaps the stack backtrace lies.

Anyone who can reproduce this should debug it, print mFactories, and paste the
struct contents into this bug.

/be
Assignee: dougt → nobody
QA Contact: scc → xpcom
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.