674032 - ShowModalDialog Crash

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[echo]

Attachment: repro (html source)

all is in the attachments

Comment 1

[echo]

Attachment: call_stack

Comment 2

[Mats Palmgren (inactive)]

Does it matter what's in the wttt.html file?

Comment 3

[echo]

it doesn't matter

Comment 4

[Justin Dolske [:Dolske]]

The call stack attached here isn't useful.

Can you reproduce this in a official Mozilla build, and if so does the Crash Reporter dialog come up? A crashID from a submitted report (via about:crashes) would be most helpful.

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: WinDbg Log

Attached a proper Stacktrace using WinDbg, since the Breakpad ID (https://crash-stats.mozilla.com/report/index/bp-8fefc4f6-24a6-42ff-8ace-3fa662110728) doesn't seem to load properly.

Against http://hg.mozilla.org/mozilla-central/rev/e4c8a1e7b373.

Comment 6

[echo]

//@Comment 4
//Oh no it isn't useless !
//Its litlle bit more abstractive ;>

Comment 7

[echo]

I have sending error when i try to submit report via crash error 
Do you can't cause crash at all ?
Try set brakepoint at nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int capacity = 0, unsigned int elemSize = 0)
,run repro and watch EAX 
My last value was 509650312  * 4 B i thing this is incorrect
I try later send crash report (when i fix my problem witch internet connection)

Comment 8

[echo]

I have "sending error" when i trying submit bug via crash report
Do you can't cause crash at all ?
Try set conditional brakepoint (ex EAX > 4000D or something like that)
at nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int capacity = 0, unsigned int elemSize = 0)
,run repro and watch EAX
My last value was 509650312  * 4 B i thing this is incorrect
I try later send crash report (when i fix my problem witch internet connection)

Sorry for spam if someone can please delete Comment 7 thx

Comment 9

[:aceman]

echo, what is your system? Is this Win XP only as set in the platform?

Comment 10

[echo]

Win32 XP home SP 3 PL

Comment 11

[:aceman]

While I could reproduce your bug 672797, I can't this one even on XP. What am I missing? For me, the ShowModalDialog opens just a standard Firefox window with the URL (wttt.html) file. Is that correct? Then I should right-click on the location bar and it should crash? Doesn't happen for me. But it seems XtC4UaLL has already confirmed it.

You think the amount of memory is relevant? That seems reasonable, it crashes in mozalloc_handle_oom, which seems to be a handler for out of memory condition.
Is your swap device full when it happens?

Comment 12

[echo]

ok maybe this can  help you

https://crash-stats.mozilla.com/report/pending/5abdcd1f-a9b0-4ae6-8aec-18fd42110805

Comment 13

[:aceman]

Your crash log is quite shorter :) However, the trace from 	nsAutoCompleteController::SetInput upward is the same.

Comment 14

[echo]

@Comment 11 aceman 2011-08-04 06:46:34 PDT 

1.About amount of memory
yes i thing the crash is  depit seend on amount of memory 
I watch firefox 4 source code and it seems in some cases
when allocation fail (at least in ff4) allocator call static function touchBadMemory 
this function crash browser by dereferencing null
in this bug sytuation is similar 
except that in our case debuger place before "null dereferencing" instruction
int3 instruction

2.About swap file (??)
In moment of last crash only 1 part of 3(1/3) of swap file  is used
System works  fine
So nothing special happen

Comment 15

[echo]

but i thing the reason of firefox trying  allocate so much memory 
is more Important  and Complicated than "crash"

Comment 16

[:aceman]

Can you tell how much memory it is using? If you have swap free it should still be able to allocate new memory. Maybe it needs some special kind of memory that is no longer available, like in some internal memory arena. But that is probably a bug.

Comment 17

[echo]

My notebook has only 512 MB RAM and 768 MB swap file 
in crash moment 2XX MB of  swap file was used    
and firefox try allocate  5xx xxx xxx Bytes or more 

One more thing i have pop-up blocker totaly disabled 

@Comment 11 aceman 2011-08-04 06:46:34 PDT
If you click at url of first modalDialog and nothing happen
close him and wait for another
then click one more time
Not always click at first modalDialog leads to crash
They are opened in loop so dont  give up ;p

Comment 18

[:aceman]

I should close the window? For how long? I can't see any other window opening again. Yes I disabled pop-up blocker and also "open new windows in a tab".
So Firefox takes around 500MB on your 512MB machine, not very good :)

Comment 19

[echo]

@aceman 2011-08-05 12:49:30 PDT 
In my system modalDialog is automaticly re-open after close
(to close browser or tab or window in most cases i must use taskmgr and kill
firefox process)
============================================================================= 

So you have windows xp,firefox 5.0.1 , popup-blocker=disabled
You run repro , correct modalDialog is opening,you click at url and nothing 
happen then you close modalDialog and this is end ?
Nothing more happen ?
Truly saying I dont have any idea why this repro doesn't work as it should in your system

Generally i thing is "desing error" and this error leads to many other bugs
include 
https://bugzilla.mozilla.org/show_bug.cgi?id=672797
https://bugzilla.mozilla.org/show_bug.cgi?id=674032
and potential "regression" of this
 https://bugzilla.mozilla.org/show_bug.cgi?id=616659

Comment 20

[:aceman]

Attachment: repro file (direct load)

Comment 21

[:aceman]

Oh, I now got it! This is ugly :)
I was getting the exact state as you describe in comment 19, because I was always loading the testcase from a local file. Now I attached it here and opened it as a webpage and then it works as you reported:
I get a normal FF window but also another one.
The other one was first a mini-one (50x20px) then it started to be big but really strange - 2 titlebars, firefox menu button (but shouldn't as I have normal menu).
And it reopened repeatedly as you say and also crashed:
https://crash-stats.mozilla.com/report/index/bp-00375b78-d89a-4703-b71c-b4e8c2110806

But once it didn't crash, it just hung. This time I hit the mouse on the wrong spot, not on the URL bar, but above it, I got the menu with "tabs on top" and then it hung. Was looping at 100% CPU and using RAM from 100MB to 200MB, looping between these limits. I had to kill is from task manager.

Comment 22

[:aceman]

Wonder why the stacktrace in comment 5 is so different from ours...

Comment 23

[:aceman]

I don't think this has anything to do with memory shortage. On my 1GB RAM machine, FF was taking 78MB (in Windows Task Manager) when it crashed. It is really some internal problem. The dialog window is really broken, it changes design each time it is spawned (sometimes with the FF button, sometimes without it). It doesn't know how it should draw so maybe the context menu then triggers some uninitialized variable. Wonder which component this could fall into.

Comment 24

[:aceman]

Forgot to mention: after closing the modaldialog for about 10 times, it no longer appeared. Instead, the original page (with wttt.html error) contained the popup-blocker bar stating it prevented to open 200 popup-windows. But the popup blocker is disabled in Options...

Comment 25

[echo]

@aceman 2011-08-07 03:58:54 PDT 
if allocators function automaticly try reserve additional memory 
when for example:
heap is in fragmented state or there is no free block 
witch required size or required size is biger 
than whole heap size then you can have right
(but in that case it must be internal error in some
of the firefox memory managment function 
because probably there is no other way to call 
mozalloc_abort,mozalloc_handle_oom etc [i thing])
But if its not then size of RAM and swap file doesn't matter (because heap has limited size)

Comment 26

[Boris Zbarsky [:bzbarsky]]

So the issue here, presumably, is that if we end up trying to open a browser window while the JS stack is very deep some random part of window init will fail due to running out of JS stack space and then things just get weird...

Comment 27

[:aceman]

Something like that. I couldn't check what FF is trying to do that fails, because
the link obj-firefox/dist/include/nsTArray.h:925 is not working in the crashlog. I have not yet downloaded the source to see manually. Only the mozalloc_oom.cpp and above works. Is that crashlog website working correctly?

Comment 28

[:aceman]

bz, I have found more reports of the bad window rendering I describe in comment 21 (double titlebar, bottom one with Firefox button). They are in bug 685507 and bug 694508. The first one is currently closed, but the real problem was not really identified. Do you know any Firebug people that could look into that?

Comment 29

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.