Closed Bug 306493 Opened 19 years ago Closed 19 years ago

recent cvs build of firefox crashes [@ nsUnicodeToTamilTTF::SetOutputErrorBehavior] [@ nsUnicodeToJamoTTF::SetOutputErrorBehavior]

Categories

(Core :: Internationalization, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: william.fiveash, Assigned: smontagu)

References

Details

(Keywords: crash, fixed1.8, topcrash+)

Crash Data

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+

The latest cvs build of firefox (Aug 30, 2005) consistenly crashes on different
websites.  Note that I do use flashblock extension.  I will add the stack trace
and other info.  Also note that an older build of cvs firefox (Jul 11, 2005)
does not crash nearly as quickly.

Reproducible: Didn't try




At the top of the stack I see:

ffbfa8f0 libc.so.1`_lwp_kill+8(b, ffbfa9b0, 0, b, ffff0000, 1)
  %l0-%l3: ff252000        0        0      400
  %l4-%l7:        0      400        1        0
  __1cNnsProfileLockSFatalSignalHandler6Fi_v_+0xe8:
  call      +0x1cd74      <PLT=libc.so.1`raise>

ffbfa950 __1cNnsProfileLockSFatalSignalHandler6Fi_v_+0xe8(b, 200, 479c0, 0, a, 
dc)
  %l0-%l3:        0        0    4a83c        0
  %l4-%l7:        0        0        0    2b438
  libc.so.1`__sighndlr+0xc:jmpl      %i3, %o7

ffbfa9c0 libc.so.1`__sighndlr+0xc(b, 0, ffbfab20, 2b484, 0, 1)
  %l0-%l3:        0 ff369c44        0 ffbffeff
  %l4-%l7: ffbffeff      400        1        a
  libc.so.1`call_user_handler+0x3b8:
  call      +0xab88       <libc.so.1`__sighndlr>

ffbfaa20 libc.so.1`call_user_handler+0x3b8(b, ffbffeff, 0, 0, ff252000, ffbfab20
)
  %l0-%l3: ffbfab20        0        0        0
  %l4-%l7:        0     ffff ffbffeff        0
  
  libctl.so`__1cTnsUnicodeToSunIndicWSetOutputErrorBehavior6MipnRnsIUnicharEncod
  er_H_I_+0x44:jmpl      %l5, %o7

ffbfadd8 0(b2b648, 2, 0, 3f, 270, 3f0000)
  %l0-%l3:       1a        0 80000000       3f
  %l4-%l7:   160018        0   6da4e0   160018
  libgfx_gtk.so`__1cOGetFontXftInfo6FpnK_FcPattern__pnNnsFontXftInfo__+0x12c:
  call      -0x28c        <libgfx_gtk.so`__1cMGetConverter6FpkcppnRnsIUnicodeEnc
  oder__I_>

ffbfae38 
libgfx_gtk.so`__1cOGetFontXftInfo6FpnK_FcPattern__pnNnsFontXftInfo__+0x12c(1, 
95eaa8, 15c90c8, 15c90c0, faa13b00, ffbfaeb8)
  %l0-%l3:      274 756e6800        3 ff2313f4
  %l4-%l7: ff2314ac ff231434      43c        0
  libgfx_gtk.so`__1cQnsFontMetricsXftHDoMatch6Mi_v_+0x218:
  call      +0x3adc       <libgfx_gtk.so`__1cOGetFontXftInfo6FpnK_FcPattern__pnN
  nsFontXftInfo__>
Assignee: nobody → prabhat.hegde
Component: General → Layout: CTL
Product: Firefox → Core
QA Contact: general → arthit
Version: unspecified → Trunk
May be related to bug 295145, but I don't see how.
Actually, I think I do.  Nothing null-initializes mErrEncoder in the constructor
of any of these classes.
Blocks: 295145
Status: UNCONFIRMED → NEW
Ever confirmed: true
(But really they should just use nsCOMPtr.)
This should be fixed on the branch (by backing out bug 295145, if needed,
although the fix should be trivial).  Plussing.
Flags: blocking1.8b4+
Assignee: prabhat.hegde → smontagu
Component: Layout: CTL → Internationalization
QA Contact: arthit → amyy
Attachment #194421 - Flags: review?(jshin1987)
(hrm, I thought I mentioned nsCOMPtr in that bug, but clearly I did it on IRC
only...)
I applied the attached patch, rebuilt the cvs source and this appears to have
fixed the crash that I was seeing.  Thanks.
*** Bug 306838 has been marked as a duplicate of this bug. ***
Comment on attachment 194421 [details] [diff] [review]
nsCOMPtrification

r=jshin
Attachment #194421 - Flags: review?(jshin1987) → review+
Attachment #194421 - Flags: superreview?(dbaron)
Comment on attachment 194421 [details] [diff] [review]
nsCOMPtrification

sr=dbaron

(Does anyone actually use these?)
Attachment #194421 - Flags: superreview?(dbaron) → superreview+
Whiteboard: [has r+SR]
(In reply to comment #12)
> (From update of attachment 194421 [details] [diff] [review] [edit])
> sr=dbaron
> 
> (Does anyone actually use these?)
> 

The stacktraces are clearly visible in Talkback. See the ones from today (look
for SetOutputErrorBehavior)

- on Firefox 1.5 branch, it's position 4 & 35
- on Firefox trunk, it's position 6 & 7
- on Thunderbird 1.5 branch, it's position 14
- on Thunderbird trunk, it's position 6
Note that the talkback traces are all coming from Linux/86 platforms. It's not
just for Solaris.

> (Does anyone actually use these?)


I'm pretty sure that nobody calls these functions with a non-null aErrEncoder,
if nothing else because before bug 295145 these functions didn't work.
OS: Solaris → All
Hardware: Sun → All
Checked in on trunk.
Whiteboard: [has r+SR] → [has r+SR] fixed on trunk
Attachment #194421 - Flags: approval1.8b4?
This is the #1 topcrash in branch nightlies, so it would be nice if this were
fixed before Firefox 1.5 Beta 1.
Flags: blocking1.8b4?
Summary: recent cvs build of firefox crashes → recent cvs build of firefox crashes [@ nsUnicodeToTamilTTF::SetOutputErrorBehavior] [@ nsUnicodeToJamoTTF::SetOutputErrorBehavior]
Comment on attachment 194421 [details] [diff] [review]
nsCOMPtrification

this needs to land asap if it's gonna make the beta.
Attachment #194421 - Flags: approval1.8b4? → approval1.8b4+
Flags: blocking1.8b5+
Flags: blocking1.8b4?
Flags: blocking1.8b4+
*** Bug 307257 has been marked as a duplicate of this bug. ***
Adding crash, topcrash+ keywords for tracking since this is the current #1
topcrash on the branch...let's try to get this in for 1.5 beta 1.
Keywords: crash, topcrash+
Checked in on MOZILLA_1_8_BRANCH.
Keywords: fixed1.8
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [has r+SR] fixed on trunk
Crash Signature: [@ nsUnicodeToTamilTTF::SetOutputErrorBehavior] [@ nsUnicodeToJamoTTF::SetOutputErrorBehavior]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: