Reproduced with today's debug build of Viewer and Apprunner on the Mac. - go to mozilla.org - click on the Party link at the bottom of the page ==> the app freezes for a few seconds and then crashes It looks like we have an infinite recursion.

Added rickg and kipp to the CC list. Does it happen on Windows?

Is this a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=3853 ? fix was checked in for 3853 last night and will appear in the wed. morning builds.

- It's not a dup: it still happens in today's debug and optimized builds. - It doesn't happen on Windows.

I'm working on it on the Mac but it's not easy: the bug causes the debugger to crash.

The crash was coming from insufficient stack space. I bumped it to 128K from 64K in Viewer and AppRunner.

In the March 19th Mac Build (M3), the apprunner will not display the graphic and freezes.

Reproduced with today's build of AppRunner but not with Viewer (the problem seems slightly different from the straight and unrecoverable crash that we used to have, though). Clearing the resolution of fixed.

fixed (nsBlockFrame::Reflow was allocating a 4Kb nsLineLayout on the stack)

Fixed in the March 23 Mac Build.

I had to back out the fix in nsBlockFrame::Reflow because of performance degradation in deeply nested tables. Instead, I increased the stack size in Viewer and AppRunner. Reopening the bug and marking it fixed again so that it can re-verified with tomorrow's builds.

Pierre, is jacking up the stack size the right way to go? What about embedding applications -- this will be yet another thing they have to worry about, and that will only bite them after a few users start crashing hard.

On that particular problem, Kipp improved the stack use a little bit: the 4Kb object was reduced to 1.7. Still, when we reflow deeply nested tables, each level of recursion takes about 9K on the stack and it appears that overall we use much more than (9Kb * number of nested levels). I opened last week a separate bug report (#3989) to address the general problem of stack space, not just this particular crash. As you said, increasing the stack size shouldn't be the only solution. It hurts the memory footprint because we must be rather conservative in the estimated size and, as you mentionned, it is one more constraint for embedding apps. Problem: as Kipp wrote, Raptor is designed to use the stack heavily. The issue will be debated tomorrow. I added you to the CC list in bug #3989.

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

With the March 26th Mac Build, the mozilla.org image (center graphic) is not displayed in Apprunner.

It's another problem which happens from time to time on Mac and Unix, as reported by the Build team when doing their daily smoke tests. This crash described by this report has been fixed. If you have a consistent way to reproduce the missing image problem, please open a separate bug report.

Fixed in March 29th Build.