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:126.96.36.199) Gecko/20060418 Firefox/188.8.131.52 I just compiled and started Firefox 184.108.40.206 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
I also see this on Sparc/Solaris, self-compiled Firefox 220.127.116.11 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.
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 18.104.22.168 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/22.214.171.124.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.
Created attachment 219135 [details] Backtrace As it seems, the problem is located in form history code.
*** Bug 334844 has been marked as a duplicate of this bug. ***
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.
Created attachment 219631 [details] [diff] [review] Patch Can you guys experiencing the crash give this patch a try?
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
Created attachment 219681 [details] [diff] [review] Patch, with nsAutoString&
Fixed on trunk.
Comment on attachment 219681 [details] [diff] [review] Patch, with nsAutoString& approved for 1.8.0 branch, a=dveditz for drivers.
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 126.96.36.199 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