Win2K does not have this problem Steps to Reproduce: -------------------- RH Linux 7.1 2001051108 Edit->Preferences->Font->DPI Change from 96 to anything(tested with 110) Click <ok> What Happens: ------------- Mozilla crashes

yep, i see this using 2001.05.14.12 verif comm bits on linux. unfortunately, didn't get trace info since talkback didn't seem to register properly. shiva, do you know anything about that? currently running a debug build, will try to get further trace info when that's done. cc'ing attinasi, mpt, timeless and hixie to see if they've heard of any recent crashers when fiddling with the Fonts pref panel. could this possibly be a dup or related to bug 80201 or bug 75662?

trace info: #0 0x857133f in ?? () #1 0x413dc579 in HandlePLEvent (aEvent=0x8796350) at nsPresShell.cpp:5616 #2 0x400e7b72 in PL_HandleEvent (self=0x8796350) at plevent.c:588 #3 0x400e80b9 in PL_ProcessEventsBeforeID (aSelf=0x80a2c28, aID=10467) at plevent.c:1254 #4 0x4063f6ef in processQueue (aElement=0x80a2c28, aData=0x28e3) at nsAppShell.cpp:475 #5 0x400b30bb in nsVoidArray::EnumerateForwards (this=0x8101ad0, aFunc=0x4063f6d4 <processQueue(void *, void *)>, aData=0x28e3) at nsVoidArray.cpp:313 #6 0x4063f729 in nsAppShell::ProcessBeforeID (aID=10467) at nsAppShell.cpp:483 #7 0x4064a6b2 in handle_gdk_event (event=0x81a7164, data=0x0) at nsGtkEventHandler.cpp:987 #8 0x407cb4db in ?? () from /usr/lib/libgdk-1.2.so.0 #9 0x407fb186 in ?? () from /usr/lib/libglib-1.2.so.0 #10 0x407fb751 in ?? () from /usr/lib/libglib-1.2.so.0 #11 0x407fb8f1 in ?? () from /usr/lib/libglib-1.2.so.0 #12 0x407205b9 in ?? () from /usr/lib/libgtk-1.2.so.0 #13 0x4063f4ac in nsAppShell::Run (this=0x8101ab8) at nsAppShell.cpp:360 #14 0x405f8335 in nsAppShellService::Run (this=0x80fdd08) at nsAppShellService.cpp:417 #15 0x805147b in main1 (argc=1, argv=0xbffff724, nativeApp=0x0) at nsAppRunner.cpp:1010 #16 0x805207d in main (argc=1, argv=0xbffff724) at nsAppRunner.cpp:1308

I get the same stack as sairuh does.

this does not crash on my redhat 7.1 machine with build 20010430 updating my build now to check out further

okay, it took me about three tries, but i made mac mozilla 2001.05.14.08 crash when changing the dpi setting. trace coming soon.

view manager stuff? over to joki for a look. Looking up roc's email.. ;-/

Changing component as it really isn't a prefs problem. Nothing indicates any event issues. Mac crashes in reflow. Layout seems likely.

Taking to investigate...

I've tried this about 25 times on my Mac (CVS build from 5/14) and it is not crashing. Is there a particular page you are on when this happens? I do nootice that we are reflowing the page, and for Mozilla.org, the reflow after the change in DPI value looks wrong, and refresh puts it back where it was (margins are iincreasing in the table). (I'll let karnaze know about the table reflow problem...)

marc, i was looking at http://www.mozilla.org

Thanks sairuh. I'm on Mozilla.org too. So are you still seeing it? I see now that this is reported on Linux, and I did try it a couple of times on Linux, but I'll try it some more. I still cannot get it to crash on my Mac though.

I am still seeing the crash on Linux 2001051612. I am just laucnching Mozilla and changing the DPI on the default page, www.mozilla.org. I do NOT see this problem with Win2K 2001051604. Like the new modern theme that is the default now though. :)

hi marc --yep, still seeing this crash using 2001.05.16.12 comm verif bits on linux and mac. same trace on mac [linux talkback still not working]. not sure if this makes a difference, but i've been able to get this crash more frequently when using the modern them --although it does occur with classic.

On Linux 2001051612 I crash 100% of the time. I run clasic most of the time, but did try out modern3 to see if it was a theme problem. Hasn't been mentioned before, but the pref does save. Guess this just confirms that it is not a prefs problem. Seems to happen when the page is reflowed with the new dpi.

I wonder if this only happens in a non-debug build...

still happens in a linux debug from last night --same trace as in my 5/14 comments.

attinasi: I see this with debug linux builds, like se's stack shows (line numbers)

I'm getting this on my Linux debug build. Thanks all.

I have a fix for this, but I don't fully understand it. David Baron made a comment in another bug that made me suspect that the ViewManager could be getting torn down (see bug 80203). Anyway, since the stack that se posted showed a viewmanager at the crash site, I looked and there is some strangeness there, reportedly to fix bug 54868. Basically, a reference is added to the pres shell's view manager before the reflow is posted. By removing that, and thus not accessing the view manager, the crash goes away. I'd like to investigate what is happening with the view manager before I post a patch though, this is all a little strange.

Uh, never mind, it still crashes, just took a few more tries than usual ;)

I applied dbaron's patch to nsCopySupport and this seems to have fixed it. I changed the DPI setting 10 times before I decided to post this, btw ;) David's change was to keep the presShell from leaking, and as he showed in bug 80203, leaking a presShell causes some dire badness. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsCopySupport.cpp&root=/cvsroot&subdir=mozilla/layout/base/src&command=DIFF_FRAMESET&rev1=1.4&rev2=1.5 Can someone please confirm this fix?

bstell- if you do not have other crasher, please help to verify this on your local build. Thanks

Note: patch got checked in today, so pull current copy of layout/base/src/nsCopySupport.cpp (or just update your build) to test this. My build's currently sunk :(

With Linux 2001052006 I am not seeing this crash any longer. The DPI pref has a completely new interface and has changed from text entry to a select. I still see the layout problem after changing the dpi(fixed by refereshing the page). Resolved?

I opened bug 81099 on the relayout problem. It si not limited to the DPI setting; change something else that causes a reframe (link underline, for example) and the same problem happens.

Greg, the DPI setting problem had nothing to do with the UI, really. It was what was happening after the DPI setting was changed and the UI was gone, in the resulting reflow. Anyway, applying the change I mentioned fixed this even if you did not get the new UI changes. Marking FIXED. If somebody sees this happeing still, please reopen ASAP - thanks.

Marking verified in the May 22nd build.