Closed Bug 727947 Opened 12 years ago Closed 11 years ago
Use-after-free after browser freeze
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11 Steps to reproduce: Note: This bug can be hard to reproduce - it may not work always and probably requires that space left on hard drive is < 4KB. Bug was reproduced on custom Firefox build with ASan in versions 11.01, 12.01 ( taken from https://people.mozilla.com/~choller/firefox/asan/20120119-9b5f1ccdb021+/ ). ASan symbols are from version 11.01 (had trouble with getting from 12.01). Step to reproduce a bug: 1. Open the testcase. 2. Wait a little bit, it will freeze a browser. 3. Close browser explicitly. 4. Open browser - it should crash. Probably testcase has nothing in common with use-after-free, most likely trigger are a browser freeze and session restore. Tested on Ubuntu 10.10, x64. Actual results: Firefox crashes with use-after-free. Expected results: It should not crash.
I have been testing the testcase and that requirement about hard drive space is not valid. Also, before browser crashes, one have to wait till ~5 seconds.
I was not able to reproduce this on Linux so far (tried 64 bit debug/opt trunk builds). I opened the testcase, waited a bit, hit ctrl+c to close browser and restarted. All I got was the session restore screen but no ASan errors. It could of course be a bug that is already fixed, or a Windows specific issue. @Arthur: What versions were you able to reproduce this on? In any case, a developer should look at the ASan trace because it might already give a good impression of what's going on, even if it's not reproducible immediately.
I was able to reproduce on ASanized versions 11.01, 12.01. Yes, bug is tricky, might not work always. If that makes sense to mention, instead of killing from console, I was clicking "Force Quit" button.
Ccing gcp and dcamp, as the crash could be related to some safe browsing component (the trace shows nsIUrlClassifierDBService).
guessing sg:moderate due to the unreliability.
Component: Untriaged → Security
Product: Firefox → Toolkit
QA Contact: untriaged → toolkit
Bug is still there, however, behavior seems to be a bit changed - Firefox will crash after every another crash. This happens only on Linux.
12 years ago
This crash is still present, and now I guess the best trigger is the unexpected Firefox quitting. For example, when running from console, just press Ctrl+C, next time when the browser is launched, it should crash.
Is there a way to get a deeper stack with these logs? Maybe I'm missing the obvious (I know nothing about ASan), but other than mentioning url-classifier in one of the paths it's awfully vague about what code or call stack is triggering the bad read. It would probably also be useful to know what the main thread stack is when this happens. Comment 0 seems to say this only happens when the filesystem is almost out of space? Is that definitely a required step to reproduce? If so that might help with finding this simply through code inspection. See also bug 775851 comment 1; this code has a number of built-in randomized delays (to avoid perf issues immediately upon startup / hammering Google's servers). If you're not already doing so, I'd suggest running Firefox with a new profile each time so that the DB updates happen quickly. EG, just run "rm -rf /tmp/foo; firefox -profile /tmp/foo;", lather-rinse-repeat.
Justin, there is no need filesystem to be out of space (see comment 2). Also, after fuzzing on build bcfe6817a213 it does not crashes with any similar ASan log anymore - I assume bug got fixed.
Unfortunately I was wrong about second part of comment 10 - still crashes, this time just not so frequently.
Potentially related to bug 795281.
Bug 795281 is now on m-i. Are you still able to reproduce this crash in a build with that fix?
After the couple of days of testing can't reproduce this bug - looks like is fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.