User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ When accessing a malformed .html page, Deer Park 2 will segfault. I have attached the malformed .html file for your review. This only seems to affect the Linux version of Deer Park 2. Thanks, -- Tom Ferris Researcher www.security-protocols.com Key fingerprint = 0DFA 6275 BA05 0380 DD91 34AD C909 A338 D1AF 5D78 Reproducible: Always Steps to Reproduce: 1. Browse to the malformed .html via a webserver. Actual Results: Deer Park 2 will segfault. Expected Results: Should properly parse the .html page.

Place this on a webserver in order to re-produce the issue.

No crash on Mac (Aug 7 trunk), loading the attachment through Bugzilla.

(In reply to comment #2) > No crash on Mac (Aug 7 trunk), loading the attachment through Bugzilla. Any updates on this???

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050817 Firefox/1.0+ I see bug 305029 but I don't get a crash. I'll try to find someone who can test on Linux.

I have tried to reproduce this bug in both Deer Park alpha 2 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+) and the latest Firefox nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050817 Firefox/1.6a1), and I am unable to reproduce it in either build. I'm running Fedora Core 4 in case it matters.

Tom, since we can't reproduce the crash, can you attach a stack trace or give a Talkback ID?

No crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050817 Firefox/1.0+

I cannot reproduce this with a current trunk opt Seamonkey Linux build, a Seamonkey opt Linux nightly from 2005-07-12, a current trunk debug Firefox Lonux build, or a current trunk opt Firefox Linux nightly...

No crash or valgrind warnings on a Linux build of Aviary 1.0.1 branch (plus patch for bug 307259).

Er, sorry, that was a trunk build.

WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060111 Firefox/1.6a1. Tom, please reopen if you can still reproduce this bug in a current version (e.g. Firefox 1.5, a 1.5.0.x nightly, or a trunk nightly), and include a stack trace or Talkback ID or reduced testcase if you can.

i will look into it today.

I just verified that the bugs still works on the current 1.5 (build 2005111116) on linux only. This does not affect OS X, or win32. Please see the link below for the simplified testcase: http://www.security-protocols.com/moz/ff-linux-dos.html Thanks, -- Tom

mrbkap tried to reproduce this but wasn't able to. I filed bugs on some of the assertions and warnings he hit, and made them block this bug. He also hit an assertion in nsRenderingContextGTK::CreateDrawingSurface, but I can't reproduce that on Mac for obvious reasons, so I didn't file a bug on that. Tom, can you provide a stack trace or Talkback ID for the crash you're hitting? That might contain enough information for us to fix the bug even though we can't reproduce it.

To be clear, the gtk assertion I saw was only when I made the iframe's width extremely large (probably too large to contain in a PRUint32), not on the actual testcase. I was wondering if perhaps Tom was finding an out-of-memory edgecase in his crashes.

This testcase reminds me strongly of bug 303433, for what it's worth...

I just sent the crash report via talkback. The talkback ID is: TB14027492Z I hope this helps. ;)

Jay, is there a reason that the talkback from comment 17 has no stack? In any case, the relevant thing from that report is: Trigger Reason: SIGFPE: Floating Point Exception: (signal 8) So it's not a segmentation violation, for what it's worth.

bz: Talkback on Linux can be flaky sometimes, and as you said, the trigger reason is not a typical crash, so it is possible that Talkback doesn't know how to capture the stack for this particular crash. If anyone else is able to reproduce this again, please post your Talkback incident id so we can see if this is a common problem with Floating Point Exceptions.

Tom, assuming you still see this and Talkback still doesn't give you a useful stack, I suggest trying to reproducing it in gdb with a debug build of Firefox. I bet that would give you a useful stack, at least. You could also try running a build with symbols in Valgrind, but that's a bit more painful.

Tom, are you still seeing this problem in any current builds?

- crash confirmed Build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/2007052204 Minefield/3.0a5pre on Fedora FC 6 while executing the testcase from comment #1 minefield trunk crash with segfaul firefox /opt/firefox/run-mozilla.sh: line 131: 2940 Segmentation fault "$prog" ${1+"$@"} talkback is not comming up on this crash.

Not that it appears to help much, but ssidler got TB32405754W with a trunk build.

I just got TB32406162G with symbols.

Both Tomcat and ss crash on trunk, neither on 2.0.0.4--it's possible we're seeing a different problem altogether. This bug was originally written about what became the 1.8 branch. Boris's comment 18 from 2006 is a different kind of crash than comment 22 or comment 23

The new crash is in Cairo, over to Vlad for further triage. Is this one an exploitable crash?

I think that the branch and trunk crashes are very different. The trunk crash is fallout from bug 371135; a null surface is making its way to the spot indicated in talkback, and it's causing a crash when dereferenced.

I haven't compiled the the BeOS part, but I thought I'd include it anyway since it's trivial.

(In reply to comment #26) > The new crash is in Cairo, over to Vlad for further triage. Is this one an > exploitable crash? I don't think so, all the fixed spots (on trunk) would be null-ptr accesses. The testcases does not crash my 1.8, 1.8.0 branch debug builds (tried both gtk1/2).

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

Comment on attachment 269911 [details] [diff] [review] Patch rev. 1 Looks fine, just a few comments... r+ with these changes made. >@@ -1738,34 +1745,38 @@ nsWindow::OnExposeEvent(GtkWidget *aWidg > // operations below if that happened - it will lead to XError and exit(). > if (NS_LIKELY(!mIsDestroyed)) { > if (status != nsEventStatus_eIgnore) { > if (translucent) { > nsRefPtr<gfxPattern> pattern = ctx->PopGroup(); > ctx->SetOperator(gfxContext::OPERATOR_SOURCE); > ctx->SetPattern(pattern); > ctx->Paint(); > > nsRefPtr<gfxImageSurface> img = > new gfxImageSurface(gfxIntSize(boundsRect.width, boundsRect.height), > gfxImageSurface::ImageFormatA8); >- img->SetDeviceOffset(gfxPoint(-boundsRect.x, -boundsRect.y)); >+ if (img) { >+ img->SetDeviceOffset(gfxPoint(-boundsRect.x, -boundsRect.y)); Need to check if (img && !img->CairoStatus()) { ... } > >- nsRefPtr<gfxContext> imgCtx = new gfxContext(img); >- imgCtx->SetPattern(pattern); >- imgCtx->SetOperator(gfxContext::OPERATOR_SOURCE); >- imgCtx->Paint(); >- >- UpdateTranslucentWindowAlphaInternal(nsRect(boundsRect.x, boundsRect.y, >- boundsRect.width, boundsRect.height), >- img->Data(), img->Stride()); >@@ -5820,25 +5831,32 @@ nsWindow::GetThebesSurface() > mThebesSurface = nsnull; > > if (!mThebesSurface) { > GdkDrawable* d = GDK_DRAWABLE(mDrawingarea->inner_window); > gint width, height; > gdk_drawable_get_size(d, &width, &height); > if (!gfxPlatform::UseGlitz()) { > mThebesSurface = new gfxXlibSurface > (GDK_WINDOW_XDISPLAY(d), > GDK_WINDOW_XWINDOW(d), > GDK_VISUAL_XVISUAL(gdk_drawable_get_visual(d)), > gfxIntSize(width, height)); >- gfxPlatformGtk::GetPlatform()->SetSurfaceGdkWindow(mThebesSurface, GDK_WINDOW(d)); >+ if (mThebesSurface) { >+ if (mThebesSurface->CairoStatus() == CAIRO_STATUS_SUCCESS) { >+ gfxPlatformGtk::GetPlatform()->SetSurfaceGdkWindow(mThebesSurface, GDK_WINDOW(d)); >+ } >+ else { >+ mThebesSurface = nsnull; >+ } >+ } Would rather see this written as if (mThebesSurface && !mThebesSurface->CairoStatus()) { ... SetSurfaceGdkWindow } else { mThebesSurface = nsnull; } (Don't want to expose CAIRO_* constants; I just don't have a better solution yet)

Fixed the nits above as suggested and checked in: mozilla/widget/src/gtk2/nsWindow.cpp 1.222 mozilla/widget/src/xpwidgets/nsBaseWidget.cpp 1.159 mozilla/widget/src/beos/nsWindow.cpp 1.137 This is for the later Cairo crash which this bug mutated into. The branch crash that was originally reported is WFM as far as I can tell, I tested Linux and MacOSX branch builds. (It appears that one was Linux-only, comment 4 and comment 7) -> FIXED

verified using verified fixed using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre and the testcase - no crash on testcase --> Verified fixed

crash test landed http://hg.mozilla.org/mozilla-central/rev/18ef88791678