Closed Bug 741056 Opened 13 years ago Closed 13 years ago

Crash when visiting https sites via proxy that needs authentication

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
14 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla14

People

(Reporter: coolypf, Assigned: mcmanus)

References

Details

(Keywords: crash, regression, reproducible)

Crash Data

Attachments

(2 files)

patch 0
1.61 KB, patch
mayhemer
: review+
Details | Diff | Splinter Review
Windows Error Message
4.45 KB, image/png
Details
Last good: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1332462857 First bad: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1332464239 Steps to reproduce: 1. Setup to use a proxy that needs authentication 2. Visit https://bugzilla.mozilla.org/ 3. Crash before authentication dialog appears
Thanks for the detailed information, Yuan! One more helpful detail would be a link to a crash stack (see about:crashes). http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1d1614bb7b39&tochange=6018a0d6b33d Regression range points to the big pipelining patch landing, Patrick.
(In reply to Yuan Pengfei from comment #2) > bp-f2f2fe7b-dc14-40fa-bd7c-7fd322120331 Do you have a recent one because the build is quite old: 14.0a1/20120322175719?
Keywords: crash
Hmm, are you using nightly builds? Those crash stacks are missing a surprising amount of recognizable names.
Previous reports were from tinderbox-builds. The following is from a nightly. bp-900243ca-86c6-48f8-b564-fe1432120331 This bug seems 100% reproducible on win32 & win64.
Oh, that's fantastic! We've been looking for steps to reproduce these crash stacks; thank you very much!
Crash Signature: [@ nsXPConnect::Push(JSContext*) ]
Blocks: 739027
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → XPConnect
Ever confirmed: true
Keywords: regression, reproducible
QA Contact: networking.http → xpconnect
Version: Trunk → 14 Branch
(In reply to Yuan Pengfei from comment #6) > Previous reports were from tinderbox-builds. > The following is from a nightly. > bp-900243ca-86c6-48f8-b564-fe1432120331 > > This bug seems 100% reproducible on win32 & win64. thanks yuan. clean profile too?
(In reply to Patrick McManus [:mcmanus] from comment #8) > (In reply to Yuan Pengfei from comment #6) > > Previous reports were from tinderbox-builds. > > The following is from a nightly. > > bp-900243ca-86c6-48f8-b564-fe1432120331 > > > > This bug seems 100% reproducible on win32 & win64. > > thanks yuan. clean profile too? Clean.
Component: XPConnect → Networking: HTTP
QA Contact: xpconnect → networking.http
Bug confirmed here, too. It already appeared in the tinderbox builds dated 27-MAR-2012.
Amendment: Other steps to reproduce a crash: Open Help, About Nightly or open Tools, Addons, Extensions. Even with network.automatic-ntlm-auth.trusted-uris, network.negotiate-auth.delegation-uris, network.negotiate-auth.trusted-uris set so that there is no proxy authentication required, Firefox crashes.
Thanks Gerd, I'm doing 741106 now and this one is next to look at in detail.
Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe51ff700 (LWP 28358)] 0x00007ffff7bcdb3b in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 42 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/pt-raise.c (gdb) bt #0 0x00007ffff7bcdb3b in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 #1 0x000000000041ca3e in MOZ_Crash () at ../../pipemq/mfbt/Assertions.cpp:79 #2 0x000000000041ca96 in MOZ_Assert (s=0x7ffff59943a8 "count == 0 || start < Length() (Invalid start index)", file=0x7ffff5994310 "../../../dist/include/nsTArray.h", ln=961) at ../../pipemq/mfbt/Assertions.cpp:88 #3 0x00007ffff3ab58ce in nsTArray<nsAHttpTransaction*, nsTArrayDefaultAllocator>::RemoveElementsAt (this=0x7fffd4128418, start=0, count=1) at ../../../dist/include/nsTArray.h:961 #4 0x00007ffff3ab5615 in nsTArray<nsAHttpTransaction*, nsTArrayDefaultAllocator>::RemoveElementAt (this=0x7fffd4128418, index=0) at ../../../dist/include/nsTArray.h:969 #5 0x00007ffff3ab4bde in nsHttpPipeline::WriteSegments (this=0x7fffd41283e0, writer=0x7fffd4b02908, count=32768, countWritten=0x7fffe51feb44) at ../../../../pipemq/netwerk/protocol/http/nsHttpPipeline.cpp:774 #6 0x00007ffff3a6e60d in nsHttpConnection::OnSocketReadable (this=0x7fffd4b02900) at ../../../../pipemq/netwerk/protocol/http/nsHttpConnection.cpp:1369 #7 0x00007ffff3a6eeca in nsHttpConnection::OnInputStreamReady (this=0x7fffd4b02900, in=0x7fffdb8bb478) at ../../../../pipemq/netwerk/protocol/http/nsHttpConnection.cpp:1489 #8 0x00007ffff39c3919 in nsSocketInputStream::OnSocketReady (this=0x7fffdb8bb478, condition=0) at ../../../../pipemq/netwerk/base/src/nsSocketTransport2.cpp:256 #9 0x00007ffff39c7812 in nsSocketTransport::OnSocketReady (this=0x7fffdb8bb330, fd=0x7fffd41fd460, outFlags=1) at ../../../../pipemq/netwerk/base/src/nsSocketTransport2.cpp:1575 #10 0x00007ffff39cc915 in nsSocketTransportService::DoPollIteration (this=0x7ffff6d55280, wait=true) at ../../../../pipemq/netwerk/base/src/nsSocketTransportService2.cpp:762 #11 0x00007ffff39cc246 in nsSocketTransportService::Run (this=0x7ffff6d55280) at ../../../../pipemq/netwerk/base/src/nsSocketTransportService2.cpp:645 #12 0x00007ffff50b16e7 in nsThread::ProcessNextEvent (this=0x7ffff6d45bf0, mayWait=true, result=0x7fffe51fedef) at ../../../pipemq/xpcom/threads/nsThread.cpp:656 #13 0x00007ffff50473a9 in NS_ProcessNextEvent_P (thread=0x7ffff6d45bf0, mayWait=true) at nsThreadUtils.cpp:245 #14 0x00007ffff50b05d8 in nsThread::ThreadFunc (arg=0x7ffff6d45bf0) at ../../../pipemq/xpcom/threads/nsThread.cpp:289 #15 0x00007ffff7eaf103 in _pt_root (arg=0x7ffff6d27030) at ../../../../../pipemq/nsprpub/pr/src/pthreads/ptthread.c:187 #16 0x00007ffff7bc4d8c in start_thread (arg=0x7fffe51ff700) at pthread_create.c:304 #17 0x00007ffff6f6b04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
This is the non debug version. It looks like 739147 (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff5202a0c in nsHttpConnectionMgr::EnsureSocketThreadTargetIfOnline (this=0x7fffe1992a80) at ../../../../pipemq/netwerk/protocol/http/nsHttpConnectionMgr.cpp:121 #2 0x00007ffff52037f3 in nsHttpConnectionMgr::PostEvent (this=0x7fffe1992a80, handler= (void (nsHttpConnectionMgr::*)(nsHttpConnectionMgr *, PRInt32, void *)) 0x7ffff5205316 <nsHttpConnectionMgr::OnMsgCancelTransaction(PRInt32, void*)>, iparam=-2142568376, vparam=0x7fffd9073600) at ../../../../pipemq/netwerk/protocol/http/nsHttpConnectionMgr.cpp:205 #3 0x00007ffff5203a9a in nsHttpConnectionMgr::CancelTransaction (this=0x7fffe1992a80, trans=0x7fffd9073600, reason=2152398920) at ../../../../pipemq/netwerk/protocol/http/nsHttpConnectionMgr.cpp:319 #4 0x00007ffff5215e55 in CancelTransaction (this=0x7fffd7055000, status=2152398920) at ../../../../pipemq/netwerk/protocol/http/nsHttpHandler.h:165 #5 nsHttpChannel::Cancel (this=0x7fffd7055000, status=2152398920) at ../../../../pipemq/netwerk/protocol/http/nsHttpChannel.cpp:3804 #6 0x00007ffff521c983 in nsHttpChannel::ProcessFailedSSLConnect (this=0x7fffd7055000, httpStatus=<value optimized out>) at ../../../../pipemq/netwerk/protocol/http/nsHttpChannel.cpp:883 #7 0x00007ffff521f830 in nsHttpChannel::ProcessResponse (this=0x7fffd7055000) at ../../../../pipemq/netwerk/protocol/http/nsHttpChannel.cpp:1103 #8 0x00007ffff5220b85 in nsHttpChannel::OnStartRequest (this=0x7fffd7055000, request=0x7fffd709acf0, ctxt=<value optimized out>) at ../../../../pipemq/netwerk/protocol/http/nsHttpChannel.cpp:4316 #9 0x00007ffff51aae0f in nsInputStreamPump::OnStateStart (this=0x7fffd709acf0) at ../../../../pipemq/netwerk/base/src/nsInputStreamPump.cpp:444 #10 0x00007ffff51ab231 in nsInputStreamPump::OnInputStreamReady (this=0x7fffd709acf0, stream=<value optimized out>) at ../../../../pipemq/netwerk/base/src/nsInputStreamPump.cpp:399 #11 0x00007ffff5b4dcc2 in nsInputStreamReadyEvent::Run (this=<value optimized out>) at ../../../pipemq/xpcom/io/nsStreamUtils.cpp:193 #12 0x00007ffff5b5c81e in nsThread::ProcessNextEvent (this=0x7ffff6b1fe80, mayWait=true, result=0x7fffffffbadf) at ../../../pipemq/xpcom/threads/nsThread.cpp:656 #13 0x00007ffff5b31b63 in NS_ProcessNextEvent_P (thread=<value optimized out>, mayWait=true) at nsThreadUtils.cpp:245 #14 0x00007ffff5abd111 in mozilla::ipc::MessagePump::Run (this=0x7fffebf91240, aDelegate=0x7ffff6bd1120) at ../../../pipemq/ipc/glue/MessagePump.cpp:134 #15 0x00007ffff5b7a6df in RunHandler (this=0x7ffff6bd1120) at ../../../pipemq/ipc/chromium/src/base/message_loop.cc:201 #16 MessageLoop::Run (this=0x7ffff6bd1120) at ../../../pipemq/ipc/chromium/src/base/message_loop.cc:175 #17 0x00007ffff5a1ed1d in nsBaseAppShell::Run (this=0x7fffe6f026a0) at ../../../pipemq/widget/xpwidgets/nsBaseAppShell.cpp:189 #18 0x00007ffff58f51b8 in nsAppStartup::Run (this=0x7fffe6f199c0) at ../../../../pipemq/toolkit/components/startup/nsAppStartup.cpp:295 #19 0x00007ffff518c0f9 in XREMain::XRE_mainRun (this=0x7fffffffbe70) at ../../../pipemq/toolkit/xre/nsAppRunner.cpp:3770 #20 0x00007ffff518d16d in XREMain::XRE_main (this=0x7fffffffbe70, argc=<value optimized out>, argv=<value optimized out>, aAppData=0x40bc10) at ../../../pipemq/toolkit/xre/nsAppRunner.cpp:3847 #21 0x00007ffff518d2e1 in XRE_main (argc=4, argv=0x7fffffffe268, aAppData=0x40bc10) at ../../../pipemq/toolkit/xre/nsAppRunner.cpp:3923 #22 0x000000000040216c in do_main (argc=<value optimized out>, argv=<value optimized out>) at ../../../pipemq/browser/app/nsBrowserApp.cpp:190 #23 main (argc=<value optimized out>, argv=<value optimized out>) at ../../../pipemq/browser/app/nsBrowserApp.cpp:277 (gdb)
Blocks: 739147
Attached patch patch 0 — — Splinter Review
nsHttpPipeline::WriteSegments was updated to handle the IsProxyConnectInProgress() case where response(0) was null. however if the transaction completed (trans->IsDone()) it still removed response(0) unconditionally which is wrong and corrupting.
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #611691 - Flags: review?(honzab.moz)
In the latest hourly build available from https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1333438102/ , the bug still appears - Firefox almost immediately crashes when trying to access ANY web pages.
(In reply to Gerd from comment #18) > In the latest hourly build available from > https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla- > central-win32/1333438102/ , the bug still appears - Gerd, no code has been commited to mozilla-central yet for this bug so it won't be reflected in tinderbox yet. It still needs code review. (and the patch is only 12 hours old :)) Do you want to try the build in comment 17? it definitely fixes a relevant bug. I don't know if its the only one with this signature or not. -P
No longer blocks: 739147
Thee is a suggestion in bug 739027 (#1 top crasher) that this bug is the real source of 739027. I'm unsure.
Blocks: 739762
The regression window in the bug's description seems to be incorrect. As I remembered that I did not experience those crashes on 23-MAR-2012, I investigated a little bit further and found: Last build that works here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332497534 First build that does not work: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332503479 Interesting: Most of the times, the Crash Reporter does not appear. Firefox's window either disappears without any notification or the Windows standard message appears saying that Firefox had crashed.
Attached image Windows Error Message —
The error message which appears when trying to start the 1332503479 hourly build saying that "written" could not be performed on the memory address 0x00000080.
(In reply to Gerd from comment #23) > The regression window in the bug's description seems to be incorrect. Yours is in mozilla-central, the one in comment 0 is in mozilla-integration. The cset range gives http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab2ff3b5611f&tochange=c20ec27eb0e8 that is larger than the one in comment 1.
(In reply to Patrick McManus [:mcmanus] from comment #19) > Do you want to try the build in comment 17? it definitely fixes a relevant > bug. I don't know if its the only one with this signature or not. > > -P Glad to report it fixes the instant crashes reported on bug 739024 for the following URLs: - https://support.xobni.com/entries/20151838/ - https://www.google.com/
Comment on attachment 611691 [details] [diff] [review] patch 0 Review of attachment 611691 [details] [diff] [review]: ----------------------------------------------------------------- Good catch. r=honzab, but see the comment please. ::: netwerk/protocol/http/nsHttpPipeline.cpp @@ +771,5 @@ > if (rv == NS_BASE_STREAM_CLOSED || trans->IsDone()) { > trans->Close(NS_OK); > + > + // Release the transaction if it is not IsProxyConnectInProgress() > + if (Response(0)) { So, as I understand trans may not be in mResponseQ[0] because this is handling write of the CONNECT request and trans has been taken from mRequestQ? r+, but with one of the following changes: - the condition should rather be if (Response(0) == trans) and no ABORT, or - there has to be an explanation comment that trans can be just one of Response(0) or Request(0) when Response(0) is null and based on that can be removed only when there is (some) Response(0). I prefer the former.
Attachment #611691 - Flags: review?(honzab.moz) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/3f46053ab2b2 > So, as I understand trans may not be in mResponseQ[0] because this is > handling write of the CONNECT request and trans has been taken from > mRequestQ? yes. thanks! > > - the condition should rather be if (Response(0) == trans) and no ABORT, or [did this]
Seems to be related to the number of open tabs. I have one session with over 200 tabs and it crashes (nearly) immediately (two or three seconds) after clicking on "Restore". Where are the crash reports stored? I can not find them.
Sorry for spamming: The profile mentioned above crashes even at the restore page when nothing is done. > msvcr100.dll!memmove(unsigned char * dst=0x01d320d4, unsigned char * src=0x01d320d8, unsigned long count=0xfffffffc) Line 185 Asm Currently i can not load symbols for xul.dll and firefox.exe.
(In reply to Volkmar Kostka from comment #31) > Sorry for spamming: > The profile mentioned above crashes even at the restore page when nothing is > done. > I don't understand what build you are testing. Does it contain the patch for this bug (just pushed to mozilla-inbound this morning). If not, what is the relevance of your comment to this bug?
Blocks: 739142
Standard nightly. Probably not. Because i get these crashes several times a day and i have a system with VS2010 available i might be able to provide a full dump for analysis. To summarize: I have two systems available. One XP with two profiles, one W7/64 with one profile. On XP the profile with a low count of open tabs crash rarely but several times a day. The profile with a high number of open tabs crashes within several seconds after starting. On W7 the profile works but crashes about ten to twenty times a day. Both systems are eqipped with VS and are behind a proxy. So i might be able to provide in deep data of these crashes. But i might need access to the symbols of the nightly builds. I'm just offering my help.
(In reply to Volkmar Kostka from comment #33) > Standard nightly. > Probably not. > > Because i get these crashes several times a day and i have a system with > VS2010 available i might be able to provide a full dump for analysis. > awesome - if you could add the "Built From" information from about:buildconfig along with the rest of your report it will help us sort out what code your're runinng.. if we don't have that and there is a constant stream of changes going on then its really hard to know what your report is applicable to. (that information is much more directly useful than a nightly date). thanks for the help.
What information do you need (beside about:buildconfig)? I doubt i can attach a dump file (even if i can create one, usually the crash reporter does not leave one behind). Or is there a way to disable the crash reporter? As said best information can be provided when i have the debug information available.
Been using try build from comment #17 as it kept the "crashyness" at bay. Moments ago it caused this weird chromehang bp-26aa1e36-f423-44a5-ad7f-336362120404 hangmonitor.timeout;5 Should I file a new bug?
(In reply to alex_mayorga from comment #36) > Been using try build from comment #17 as it kept the "crashyness" at bay. > > Moments ago it caused this weird chromehang > bp-26aa1e36-f423-44a5-ad7f-336362120404 > > hangmonitor.timeout;5 > > Should I file a new bug? weird symbol-less stack. Not sure what to make of it or how to decide if it is related, honestly.
(In reply to Patrick McManus [:mcmanus] from comment #37) > (In reply to alex_mayorga from comment #36) > > Been using try build from comment #17 as it kept the "crashyness" at bay. > > > > Moments ago it caused this weird chromehang > > bp-26aa1e36-f423-44a5-ad7f-336362120404 > > > > hangmonitor.timeout;5 > > > > Should I file a new bug? > > weird symbol-less stack. Not sure what to make of it or how to decide if it > is related, honestly. Let's land this and get stacks with symbols if there is still an issue. But I sense this is unrelated...
mozglue.dll!MOZ_Crash() Line 70 + 0x5 bytes C++ mozglue.dll!MOZ_Assert(const char * s=0x0000000000000000, const char * file=0x0000000000000000, int ln=0x00000000) Line 88 + 0x5 bytes C++ > xul.dll!nsXPConnect::Push(JSContext * cx=0x0000000002216280) Line 2578 + 0x27 bytes C++ xul.dll!nsThread::ProcessNextEvent(bool mayWait=true, bool * result=0x000007fee5a3b700) Line 621 + 0x5b bytes C++ xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x0000000002238040) Line 135 C++ xul.dll!MessageLoop::RunHandler() Line 202 C++ xul.dll!MessageLoop::Run() Line 176 C++ xul.dll!nsBaseAppShell::Run() Line 191 C++ xul.dll!nsAppStartup::Run() Line 296 C++ xul.dll!XREMain::XRE_mainRun() Line 3773 C++ xul.dll!XREMain::XRE_main(int argc=0x6245b300, char * * argv=0x00000000002ef1b0, const nsXREAppData * aAppData=0x000000013f413620) Line 3849 + 0x8 bytes C++ xul.dll!XRE_main(int argc=0x00000001, char * * argv=0x0000000001e97690, const nsXREAppData * aAppData=0x000000000221d0c0) Line 3925 + 0x12 bytes C++ firefox.exe!wmain(int argc=0x00000001, wchar_t * * argv=0x0000000076785863) Line 107 + 0x1ea bytes C++ firefox.exe!__tmainCRTStartup() Line 552 + 0x19 bytes C kernel32.dll!BaseThreadInitThunk() + 0xd bytes ntdll.dll!RtlUserThreadStart() + 0x21 bytes --- e:\builds\moz2_slave\m-cen-w64-ntly\build\js\xpconnect\src\nsxpconnect.cpp - 000007FEE4FF1300 call NS_IsCycleCollectorThread_P (7FEE4C513C8h) 000007FEE4FF1305 test al,al 000007FEE4FF1307 jne nsXPConnect::Push+24h (7FEE4B05A24h) 000007FEE4FF130D lea rdx,[string "e:\\builds\\moz2_slave\\m-cen-w64-n"... (7FEE5BAAF40h)] 000007FEE4FF1314 lea rcx,[string "NS_IsMainThread()" (7FEE5BAAF88h)] 000007FEE4FF131B mov r8d,0E7Ah 000007FEE4FF1321 call qword ptr [__imp_MOZ_Assert (7FEE5892C60h)] about:buildconfig Build Machine w64-ix-slave17 Source Built from http://hg.mozilla.org/mozilla-central/rev/25ec8b71e8ce Build platform target x86_64-pc-mingw32 Build tools Compiler Version Compiler flags c;C:\mozilla-build\msys\mozilla-build\python\python2.6.exe -O e;C:\mozilla-build\msys\builds\moz2_slave\m-cen-w64-ntly\build\build\cl.py cl 16.00.30319.01 -TC -nologo -W3 -Gy -Fdgenerated.pdb -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy c;C:\mozilla-build\msys\mozilla-build\python\python2.6.exe -O e;C:\mozilla-build\msys\builds\moz2_slave\m-cen-w64-ntly\build\build\cl.py cl 16.00.30319.01 -TP -nologo -W3 -Gy -Fdgenerated.pdb -wd4800 -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy Configure arguments --target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-signmar --enable-js-diagnostics --- Looks like something is executed in the wrong thread to me. The dump file (300+ MB, 80+ MB zipped) is too large to be attached.
For the WriteSegments bug: msvcr100.dll!memmove(unsigned char * dst=0x01d34264, unsigned char * src=0x01d34268, unsigned long count=0xfffffffc) Line 185 Asm xul.dll!nsTArray_base<nsTArrayDefaultAllocator>::ShiftData(unsigned int start=0x00000000, unsigned int oldLen=0x00000000, unsigned int newLen=0x00000000, unsigned int elemSize=0x00000004, unsigned int elemAlign=0x00000004) Line 277 + 0xd bytes C++ xul.dll!nsHttpPipeline::WriteSegments(nsAHttpSegmentWriter * writer=0x0a9ff7c4, unsigned int count=0x00008000, unsigned int * countWritten=0x00000000) Line 781 C++ Seems the nsTArray_base<nsTArrayDefaultAllocator>::ShiftData() function does not handle a no-op correctly. --- about:buildconfig Build Machine w32-ix-slave38 Source Built from http://hg.mozilla.org/mozilla-central/rev/ed9cbe6a817e Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\m-cen-w32-ntly\build\build\cl.py cl 16.00.30319.01 -TC -nologo -W3 -Gy -Fdgenerated.pdb -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\m-cen-w32-ntly\build\build\cl.py cl 16.00.30319.01 -TP -nologo -W3 -Gy -Fdgenerated.pdb -wd4800 -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy Configure arguments --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-signmar --enable-js-diagnostics
Given that we have explicit assertions in nsTArray that would be screaming in this situation in a debug build, either the calling code in nsHttppipeline::WriteSegments should check for this problem or there's a deeper problem that gets us into an unexpected state here.
(In reply to Josh Matthews [:jdm] from comment #42) > Given that we have explicit assertions in nsTArray that would be screaming > in this situation in a debug build, either the calling code in > nsHttppipeline::WriteSegments should check for this problem or there's a > deeper problem that gets us into an unexpected state here. I'm pretty confident Volkmar's stacks are addressed by the patch that is sitting on inbound waiting for m-c merge.
https://hg.mozilla.org/mozilla-central/rev/3f46053ab2b2
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Apparently this fixes the instant crashes reported on bug 739024 for these URLs: - https://support.xobni.com/entries/20151838/ - https://www.google.com/ Tested on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120405 Firefox/14.0a1 ID:20120405105200 Thanks Patrick!
Status: RESOLVED → VERIFIED
Target Milestone: mozilla14 → ---
My high load profile works again. Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120409 Firefox/14.0a1 Firefox/14.0a1
Target Milestone: --- → mozilla14
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: