Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102304 Minefield/3.0a9pre. STR: 1. Go to a bugzilla search page. 2. Enter "CoreGraphics@0xa1d71" in the search field. I crash every time, 100% reproducible using today's build. This does not happen on Tiger. Here is my breakpad URL: http://crash-stats.mozilla.com/report/index/f3eab0f8-8190-11dc-9a35-001a4bd43ef6?date=2007-10-23-17

I can't reproduce this. Does it keep happening after you restart your computer? Does it keep happening with a clean profile?

Steven: yes, it happens with a clean profile as well as an existing profile. I have not restarted my computer yet. Typically I put the machine to sleep at night and rarely restart it. Google Desktop search is installed on this machine, but is disabled as not compatible with Minefield. I can restart my computer and see if it happens, and I can try to repro on the two lab machines as well.

> Google Desktop search is installed on this machine, but is disabled > as not compatible with Minefield. Is it possible to completely remove this (as opposed to just disabling it)? That might make a difference. And even though a clean profile makes no difference, I wonder what would happen if you ran a fresh (and therefore "clean") copy of the Minefield nightly.

Steven: I tested this on the lab machine running Leopard (new install), Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102304 Minefield/3.0a9pre. I still get the crash. There are no extensions in this profile and no Google Desktop installed on this machine.

I'm stumped. It might help if you described in more detail exactly what you do just before the crash happens. (For example, exactly which search page are you using, and are you logged in to bugzilla when you do the search?)

Here are my exact STR, sorry for not being more clear: 1. Logged into my bugzilla account. 2. Cut and paste CoreGraphics@0xa1d71 into the search box on the bottom of the main bugzilla home page. Click Find. Sometimes after it finds the search I have to copy and paste the text into the box and click Find again. 3. I crash.

Bingo! Now I crash, too. My stack trace isn't the same as yours ... but that doesn't mean much, since (like you) I'm working with a nightly (which doesn't have debugging symbols). I'll post more information as I find it.

Marcia, I don't see this crash with the previous Minefield nightly (2007-10-22-04-trunk). How about you? If I'm right this could be a very recent regression.

Marcia, I don't see this crash with the previous Minefield nightly (2007-10-22-04-trunk). How about you? If I'm right this could be a very recent regression. But I can't see any obvious culprits in the apparent regression window.

Steven: I do see it using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102204 Minefield/3.0a9pre. I will try to hunt down a regression range and see when it might have started happening.

I just crashed in the 10-22 nightly. There must be some STR subtleties that I'm still missing.

Maybe not. Sometimes the crash doesn't fire right away. In some cases I have to enter the text twice. I also have seen random crashes on this build when typing in form fields on yahoo.com and when loading a bugzilla query. BTW, I checked and this crash does not happen on the 1.8 branch. (In reply to comment #11) > I just crashed in the 10-22 nightly. There must be some STR > subtleties that I'm still missing. >

Marcia, please do try to find a regression window for this bug (in Minefield nightlies). I tried myself, but failed -- turns out I'm still not able to reproduce this bug reliably enough.

I will do my best to find a regression window. Currently I crash almost 100% on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102304 Minefield/3.0a9pre (I tried a Leopard PPC mac too with similar results on that build.). I crash sporadically on the 2007102204 build. It seems in that build I have to fiddle with the dropdown a bit before I click "Find" to trigger the crash, whereas on today's build it is really easy.

Guessing this is the same bug as 397293

With the patch for bug 397293, the crash does not occur. The console shows messages about invalid image 0 x 0 images: Wed Oct 24 18:26:30 johnmb17lan1.office.mozilla.or.jp firefox-bin[33479] <Error>: CGImageCreate: invalid image size: 0 x 0. Wed Oct 24 18:26:30 johnmb17lan1.office.mozilla.or.jp firefox-bin[33479] <Error>: CGImageCreate: invalid image size: 0 x 0. Once the patch for bug 397293 has been reviewed and checked in, we can lower the priority of this one and figure out why exactly the image allocation is failing, it's not immediately clear to me what's wrong here.

Anecdotally, this happens to me 4 or 5 times a day on nightlies on OSX 10.5, generating a stack trace like: http://crash-stats.mozilla.com/report/index/64b14457-826f-11dc-a4ee-001a4bd46e84?date=2007-10-24-20 I also, fwiw, have Google Desktop Client installed. I'll try turning that off for a while.

(In reply to comment #17) > I also, fwiw, have Google Desktop Client installed. I'll try turning that off > for a while. Oh, it is off, and I'm still crashing. nm!

With 10.5 GM build (9A581) and the latest trunk build this no longer occurs. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102804 Minefield/3.0a9pre