Closed Bug 334464 Opened 18 years ago Closed 18 years ago

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

Categories

(Toolkit :: Form Manager, defect)

HP
HP-UX
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: stefan_blobner, Assigned: mark)

References

Details

(4 keywords)

Attachments

(2 files, 1 obsolete file)

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:1.8.0.2) Gecko/20060418 Firefox/1.5.0.2

I just compiled and started Firefox 1.5.0.2 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
Component: General → Form Manager
QA Contact: general → form.manager
I also see this on Sparc/Solaris, self-compiled Firefox 1.5.0.2 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.
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 1.5.0.2 also crashes on your platform in that case?
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
 http://www.squarefree.com/burningedge/releases/1.5.0.2.html
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.
Attached file Backtrace
As it seems, the problem is located in form history code.
*** Bug 334844 has been marked as a duplicate of this bug. ***
Assignee: nobody → mark
Status: UNCONFIRMED → NEW
Ever confirmed: true
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/satchel/src/nsFormHistory.cpp&rev=1.30&mark=941-942#935

Needs 2-byte terminating NULs when initializing strings this way.  Probably better to init with an explicit length.
Blocks: 328982
Status: NEW → ASSIGNED
Attached patch Patch (obsolete) — Splinter Review
Can you guys experiencing the crash give this patch a try?
Attachment #219631 - Flags: review?(darin)
Comment on attachment 219631 [details] [diff] [review]
Patch

>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+
Flags: blocking1.8.0.3?
Keywords: regression
Attachment #219631 - Attachment is obsolete: true
Attachment #219681 - Flags: approval1.8.0.3?
Attachment #219681 - Flags: approval-branch-1.8.1?
Attachment #219681 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(bryner)
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 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+
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Attachment #219681 - Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+
the patch fixed the issue on HP-UX.
Also confirming fixed for Sparc/Solaris (with the first patch, but I guess that's OK).
Fixed on MOZILLA_1_8_BRANCH   for 1.8.0.3
     and MOZILLA_1_8_0_BRANCH for 1.8.1[a2]
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.
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.

Attachment

General

Created:
Updated:
Size: