Repro-file as attachment. This repro-file can be little flaky. The crash didn't reproduce on all my machines. I can provide few unminimized test cases if needed. ASAN-report (From m-c opt build): ==2654== ERROR: AddressSanitizer crashed on unknown address 0x7f24d1400000 (pc 0x7f24ec1010af sp 0x7fffd57ced10 bp 0x7fffd57cee30 T0) AddressSanitizer can not provide additional info. #0 0x7f24ec1010ae in CalculateUTF8Size::write(unsigned short const*, unsigned int) /home/attekett/firefox/src/../../../dist/include/nsUTF8Utils.h:574 #1 0x7f24ea4e88b0 in nsJSThunk::EvaluateScript(nsIChannel*, PopupControlState, unsigned int, nsPIDOMWindow*) /home/attekett/firefox/src/dom/src/jsurl/nsJSProtocolHandler.cpp:369 #2 0x7f24ea4eb81a in nsJSChannel::EvaluateScript() /home/attekett/firefox/src/dom/src/jsurl/nsJSProtocolHandler.cpp:731 #3 0x7f24ea4f0c4a in nsRunnableMethodImpl<void (nsJSChannel::*)(), true>::Run() /home/attekett/firefox/src/../../../dist/include/nsThreadUtils.h:367 #4 0x7f24ec0010fb in NS_ProcessNextEvent_P(nsIThread*, bool) /home/attekett/firefox/src/objdir-ff-asan/xpcom/build/nsThreadUtils.cpp:238 #5 0x7f24eb959e4c in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/attekett/firefox/src/ipc/glue/MessagePump.cpp:82 #6 0x7f24ec137413 in MessageLoop::RunInternal() /home/attekett/firefox/src/ipc/chromium/src/base/message_loop.cc:215 #7 0x7f24eb6a4a43 in nsBaseAppShell::Run() /home/attekett/firefox/src/widget/xpwidgets/nsBaseAppShell.cpp:163 #8 0x7f24e8d893ed in XREMain::XRE_main(int, char**, nsXREAppData const*) /home/attekett/firefox/src/toolkit/xre/nsAppRunner.cpp:3890 #9 0x7f24e8d89fa1 in XRE_main /home/attekett/firefox/src/toolkit/xre/nsAppRunner.cpp:4093 #10 0x409d33 in do_main(int, char**, nsIFile*) /home/attekett/firefox/src/browser/app/nsBrowserApp.cpp:185 #11 0x7f24f2f7276c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 Stats: 90M malloced (136M for red zones) by 383574 calls Stats: 4M realloced by 18849 calls Stats: 57M freed by 251889 calls Stats: 0M really freed by 0 calls Stats: 264M (67617 full pages) mmaped in 66 calls mmaps by size class: 8:360426; 9:32764; 10:12285; 11:8188; 12:3072; 13:1536; 14:768; 15:384; 16:896; 17:96; 18:32; 19:8; 20:4; mallocs by size class: 8:341076; 9:22721; 10:8428; 11:6214; 12:2064; 13:1202; 14:596; 15:269; 16:888; 17:91; 18:17; 19:4; 20:4; frees by size class: 8:227140; 9:12816; 10:4835; 11:3903; 12:1028; 13:968; 14:432; 15:155; 16:517; 17:81; 18:9; 19:2; 20:3; rfrees by size class: Stats: malloc large: 116 small slow: 1705 ==2654== ABORTING

Probably a dup of bug 832435

If this is a dupe of bug 832435 then it should be verified fixed. If it's not a dupe of then this and bug 832646 are probably the same.

Matt, can you figure out if this is a dupe or not?

I can't say if both bugs are the same crash, as I don't have test cases for both and therefore don't have the ability to compare call stacks. I can say that this reproduces on 2013-01-19, ASan, and appears to be fixed on or before 2013-01-31. I don't have access to ASan builds closer to 2013-01-22, which is when the fix for related bug 832435 was landed. So, based on that, I would say it's very possible that this is a dupe of 832435, and that the fix for that bug fixed this one.

This issue appears to be an issue Qanalyst is unable to verify unless there are some steps we could follow in order reproduce. For the time being marking QAExclude in QA Whiteboard.