The "mLayerManager->Destroy()" call in nsWindow::Destroy() leads to accessing a deallocated frame. http://hg.mozilla.org/mozilla-central/diff/f7c05b60f1cc/widget/src/gtk2/nsWindow.cpp PREPARATIONS 1. build Firefox with --enable-valgrind etc. 2. download cross_fuzz v3 from http://lcamtuf.coredump.cx/cross_fuzz/ STEPS TO REPRODUCE 1. mkdir PROFILE 2. firefox -no-remote -profile PROFILE * in Preferences->Content, disable pop-up blocking * in Preferences->Advanced->Update, disable all updates * in Preferences->Privacy->History to "Never remember history" * in about:config - set javascript.options.methodjit.content to false - set javascript.options.methodjit.chrome to false 3. quit 4. firefox -g --debugger valgrind -no-remote -profile PROFILE \ "file:///CROSS_FUZZ_PATH/cross_fuzz_randomized_20110105_seed.html#139139139" 5. let it run until the "slow script" dialog appears: click the "Don't show this dialog again" checkbox click "Continue" when the dialog closes ==> BUG ACTUAL RESULT see attachment

Looks like this one bypasses frame-poisoning, deleted "this" in call to nsIFrame::GetStyleContext()

Marking this a blocker per above comments.

(In reply to comment #1) > Looks like this one bypasses frame-poisoning, deleted "this" in call to > nsIFrame::GetStyleContext() Mats certainly had frame poisoning disabled (because the frame arena was disabled) for the "valgrind log" part of the above, and possibly for all of it.

Bug 625249 is similar, I think.

> Mats certainly had frame poisoning disabled Yes, the relevant mozconfig options for this build: ac_add_options --enable-optimize="-fno-omit-frame-pointer -fno-asynchronous-unwind-tables -fno-inline -O -g -ggdb -DDEBUG_TRACEMALLOC_PRESARENA" ac_add_options --enable-debug ac_add_options --disable-jemalloc ac_add_options --enable-valgrind I'm pretty sure it's mitigated by frame poisoning in a default build.

I don't think this needs to block 2.0 since it's mitigated by frame poisoning in a release build. I think it's unlikely to occur under normal circumstances, i.e. when not running a fuzzer.

Removing sg: marking to trigger a re-triage based on the most recent comments.

(In reply to comment #6) > I think it's unlikely to occur under normal circumstances, > i.e. when not running a fuzzer. Attackers run fuzzers; just because random users aren't likely to be crashing left and right doesn't make it less of a potential security problem (if it is one, which in this case sounds like it isn't).

What I meant with the second sentence is that the non-security aspects of the crash (potential dataloss, annoyance etc) isn't a problem since the crash is unlikely to occur.

Is this still a problem in current builds?

(In reply to Daniel Veditz [:dveditz] from comment #10) > Is this still a problem in current builds?

No crash, but I'm seeing a lot of assertions. I'll report them separately. I'm guessing no one runs this old fuzzer on a regular basis... :-(