Firefox abort when entering chars in form field on HP-UX




Form Manager
12 years ago
9 years ago


(Reporter: Stefan Blobner, Assigned: Mark Mentovai)


(4 keywords)

crash, fixed1.8.1, regression, verified1.8.0.4
Bug Flags:
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



12 years ago
User-Agent:       Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.8) Gecko/20051201 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv: Gecko/20060418 Firefox/

I just compiled and started Firefox on HP-UX. as soon as I enter the first character into a field on a form or into the search box, the browser aborts. the URL address line seems to work ok.

this behaviour is clearly reproducable on my environment. I can easily do any extra tests if you need this for troubleshooting.

Reproducible: Always

Steps to Reproduce:
1. start firefox
2. enter one character into the search box
3. firefox disappears


12 years ago
Component: General → Form Manager
QA Contact: general → form.manager
I also see this on Sparc/Solaris, self-compiled Firefox using GTK2 and XFT. Happens with fresh profile and safe mode. This bug was not present with Firefox 1.5 (same settings).
Trying to open Edit > Preferences results in a Bus Error, too. Again, this does not happen with Firefox 1.5.


12 years ago
Keywords: crash
Further investigation shows that Edit > Preferences > Privacy is the culprit, which happened to be selected the last time I used Firefox 1.5 (Preference tab selection is remembered).

Reporter, can you confirm that Firefox also crashes on your platform in that case?

Comment 4

12 years ago
Also on HP-UX Firefox aborts when trying to open the Edit > Preferences > Privacy tab.
Can you work out which of the privacy tabs is the culprit ? Does it matter ?
This could be a 64-bit platform problem ?

There is nothing obvious to cause this in the unofficial changelog
but some of the security bugs are still closed.
(In reply to comment #5)
> Can you work out which of the privacy tabs is the culprit ? Does it matter ?

At least it doesn't seem to matter which is selected. But since this bug is also about crashing when typing into a form input field, maybe it's Saved Forms.

> This could be a 64-bit platform problem ?

Don't know, I'm not even sure I'm building 64-bit.

I'm currently building a debug build but it will take some hours.
Created attachment 219135 [details]

As it seems, the problem is located in form history code.

Comment 8

12 years ago
*** Bug 334844 has been marked as a duplicate of this bug. ***


12 years ago
Assignee: nobody → mark
Ever confirmed: true

Comment 9

12 years ago

Needs 2-byte terminating NULs when initializing strings this way.  Probably better to init with an explicit length.
Blocks: 328982

Comment 10

12 years ago
Created attachment 219631 [details] [diff] [review]

Can you guys experiencing the crash give this patch a try?


12 years ago
Attachment #219631 - Flags: review?(darin)

Comment 11

12 years ago
Comment on attachment 219631 [details] [diff] [review]

>Index: mozilla/toolkit/components/satchel/src/nsFormHistory.cpp
>+  nsAutoString bigEndianByteOrder((PRUnichar*)"BBBB", 2);
>+  nsAutoString littleEndianByteOrder((PRUnichar*)"llll", 2);
> #ifdef IS_BIG_ENDIAN
>   nsAutoString nativeByteOrder(bigEndianByteOrder);
> #else
>   nsAutoString nativeByteOrder(littleEndianByteOrder);
> #endif

Can you change nativeByteOrder to be a reference type instead?

    nsAutoString &nativeByteOrder(bigEndianByteOrder);

That way you avoid an additional string copy.  r=darin
Attachment #219631 - Flags: review?(darin) → review+


12 years ago
Flags: blocking1.8.0.3?
Keywords: regression

Comment 12

12 years ago
Created attachment 219681 [details] [diff] [review]
Patch, with nsAutoString&
Attachment #219631 - Attachment is obsolete: true
Attachment #219681 - Flags: approval1.8.0.3?
Attachment #219681 - Flags: approval-branch-1.8.1?


12 years ago
Attachment #219681 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(bryner)

Comment 13

12 years ago
Fixed on trunk.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 219681 [details] [diff] [review]
Patch, with nsAutoString&

approved for 1.8.0 branch, a=dveditz for drivers.
Attachment #219681 - Flags: approval1.8.0.3? → approval1.8.0.3+


12 years ago
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Attachment #219681 - Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+

Comment 15

12 years ago
the patch fixed the issue on HP-UX.
Also confirming fixed for Sparc/Solaris (with the first patch, but I guess that's OK).

Comment 17

12 years ago
Fixed on MOZILLA_1_8_BRANCH   for
     and MOZILLA_1_8_0_BRANCH for 1.8.1[a2]
Keywords: fixed1.8.0.3, fixed1.8.1

Comment 18

12 years ago
Comment on attachment 219681 [details] [diff] [review]
Patch, with nsAutoString&

I made nativeByteOrder a non-reference on the 1.8.0 branch because it turned the 1.8.0 tinderbox red.  VC98?
verified on 180 branch - patch was checked in on the branch, and win/linux/mac builds work.
Keywords: fixed1.8.0.4 → verified1.8.0.4
The reference piece of this is causing Sunbird's Windows tinderbox to burn.

#build hasn't gotten that compiler upgraded, so we're backing out the reference on trunk (like was done on 1.8.0 and 1.8)

r=mento in irc
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.