Reproduction (for me 100%): 1. Addressbook 2. View | Show Name As, select any item in the submenu (e.g. "Last, First"). Actual result: crash

My own Mozilla build from Mai 6th (I think), Linux, optimized, non-debug. New (3th) Modern skin.

WFM, Build id: 2001050515 (0.9) on W98SE.

Work for me using build 2001051604 on win2000. Reporter, please try on a latest build. Fenella, can you try on the Linux build? Thanks.

Tried on my Mozilla debug build on Linux updated on 5/18. It works fine, no crash. Mark WFM.

Linux (2001-05-21-08 trunk) Win32 (2001-05-21-11 trunk) Mac (2001-05-17-08 trunk) I cannot reproduce this bug.

But I do see it. Mozilla nightly build, Linux gcc295, 20010527 (from UA string). It happens in the said manu and also in Mailnews HTML Composer, Options->Priority. It does not happen in Options->Format. Currently, it takes 1s after clicking on the radio menu item until the app crashes. The console output (snipped): Compose: ComposeStartup [nsIMsgIdentity: id1],[nsIMsgIdentity: id2],[nsIMsgIdentity: id3],[nsIMsgIdentity: id4],[nsIMsgIdentity: id5],[nsIMsgIdentity: id6],[nsIMsgIdentity: id7] [...] mailCharsetLoadListener: ISO-8859-1 Trying to position a sizeless window; caller should have called sizeToContent() or sizeTo(). See bug 75649. awClickEmptySpace /usr/local/package/mozilla/current/run-mozilla.sh: line 72: 23430 Speicherzugriffsfehler $prog ${1+"$@"} $ <path>/mozilla [...] profileName passed in: <snipped> failed to set webshell window imap://ben@smserver/INBOX imap://ben@smserver...skipping, already opened /usr/local/package/mozilla/current/run-mozilla.sh: line 72: 28080 Speicherzugriffsfehler $prog ${1+"$@"} $ <path>/mozilla [...] set focus on the recipient Set Message Format to 2 /usr/local/package/mozilla/current/run-mozilla.sh: line 72: 28099 Speicherzugriffsfehler $prog ${1+"$@"} (Speicherzugriffsfehler (German) = memory access error) REOPENing.

Oh, and the profile I use now is relatively new - created with that build.

It is also not spepcific to my system (to be exact: OS installation). I reported that bug with a RH6.x system, and now I am on a new Debian installation.

worksforme - buildid: 2001060804, win98.

Ben, please re-test this bug..

fenella, I already did retest and then reopened. Also, I am seeing the bug all the time during usage - View | Text Size | 150 % crashes it, but View | Text Size | Larger doesn't. Please try a gcc295 build.

From my user.js: user_pref("ui.key.accelKey", 18); user_pref("ui.key.menuAccessKey", 0); user_pref("mail.imap.noop_check_count", 1); user_pref("mailnews.headers.showUserAgent", true); user_pref("converter.html2txt.header_strategy", 2); user_pref("ui.submenuDelay", 0); user_pref("browser.cache.disk.enable", false); user_pref("browser.cache.disk_cache_size", 0); user_pref("image.animation_mode", "once"); user_pref("font.min-size.variable.", 14); user_pref("accessibility.accesskeycausesactivation", false);

Changing SUMMARY to reflect current understanding. Since Beonex uses gcc295 -O2 for building *shipping* binaries, this is a severe bug for us.

*** Bug 82962 has been marked as a duplicate of this bug. ***

REASSIGN.

So similiar to bug 61501, this problem seems to be caused by a mis-optimization of a nsCOMPtr declared in a while loop. Moving the nsCOMPtr declaration outside of the loop "fixes" the problem. Anyone care to update the c++ portability guide with this tidbit?

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

The patch fixes the problem for me. Thanks, cls, for providing a fix so quickly!

Patch has been checked in.

marking verified per Ben's comment.