Last Comment Bug 741056 - Crash when visiting https sites via proxy that needs authentication
: Crash when visiting https sites via proxy that needs authentication
Status: VERIFIED FIXED
: crash, regression, reproducible
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 14 Branch
: All Windows 7
: -- critical with 1 vote (vote)
: mozilla14
Assigned To: Patrick McManus [:mcmanus]
:
: Patrick McManus [:mcmanus]
Mentors:
: 739024 739027 739147 739661 740319 (view as bug list)
Depends on:
Blocks: 739027 739142 739762
  Show dependency treegraph
 
Reported: 2012-03-31 02:03 PDT by Yuan Pengfei
Modified: 2012-04-12 02:55 PDT (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch 0 (1.61 KB, patch)
2012-04-02 19:11 PDT, Patrick McManus [:mcmanus]
honzab.moz: review+
Details | Diff | Splinter Review
Windows Error Message (4.45 KB, image/png)
2012-04-03 09:17 PDT, Gerd
no flags Details

Description Yuan Pengfei 2012-03-31 02:03:16 PDT
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
Comment 1 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-03-31 02:33:57 PDT
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.
Comment 2 Yuan Pengfei 2012-03-31 03:25:07 PDT
bp-f2f2fe7b-dc14-40fa-bd7c-7fd322120331
Comment 3 Scoobidiver (away) 2012-03-31 05:55:20 PDT
(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?
Comment 4 Yuan Pengfei 2012-03-31 06:27:07 PDT
bp-305e2a04-4a47-47e5-9b13-268052120331
Comment 5 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-03-31 09:59:33 PDT
Hmm, are you using nightly builds? Those crash stacks are missing a surprising amount of recognizable names.
Comment 6 Yuan Pengfei 2012-03-31 17:04:20 PDT
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.
Comment 7 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-03-31 17:10:55 PDT
Oh, that's fantastic! We've been looking for steps to reproduce these crash stacks; thank you very much!
Comment 8 Patrick McManus [:mcmanus] 2012-04-01 08:39:39 PDT
(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?
Comment 9 Yuan Pengfei 2012-04-01 19:02:15 PDT
(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.
Comment 10 Gerd 2012-04-02 09:11:28 PDT
Bug confirmed here, too. It already appeared in the tinderbox builds dated 27-MAR-2012.
Comment 11 Gerd 2012-04-02 09:15:41 PDT
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.
Comment 13 Patrick McManus [:mcmanus] 2012-04-02 09:39:27 PDT
Thanks Gerd, I'm doing 741106 now and this one is next to look at in detail.
Comment 14 Patrick McManus [:mcmanus] 2012-04-02 11:36:24 PDT
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
Comment 15 Patrick McManus [:mcmanus] 2012-04-02 12:19:04 PDT
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)
Comment 16 Patrick McManus [:mcmanus] 2012-04-02 19:11:02 PDT
Created attachment 611691 [details] [diff] [review]
patch 0

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.
Comment 17 Patrick McManus [:mcmanus] 2012-04-02 19:15:22 PDT
try for comment 16 https://tbpl.mozilla.org/?tree=Try&rev=f1b130336861
Comment 18 Gerd 2012-04-03 05:07:49 PDT
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.
Comment 19 Patrick McManus [:mcmanus] 2012-04-03 05:18:41 PDT
(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
Comment 20 Patrick McManus [:mcmanus] 2012-04-03 05:41:03 PDT
*** Bug 739147 has been marked as a duplicate of this bug. ***
Comment 21 Patrick McManus [:mcmanus] 2012-04-03 06:06:47 PDT
*** Bug 739024 has been marked as a duplicate of this bug. ***
Comment 22 Patrick McManus [:mcmanus] 2012-04-03 08:35:43 PDT
Thee is a suggestion in bug 739027 (#1 top crasher) that this bug is the real source of 739027.

I'm unsure.
Comment 23 Gerd 2012-04-03 09:10:44 PDT
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.
Comment 24 Gerd 2012-04-03 09:17:29 PDT
Created attachment 611841 [details]
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.
Comment 25 Scoobidiver (away) 2012-04-03 09:23:06 PDT
(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.
Comment 26 alex_mayorga 2012-04-03 11:17:12 PDT
(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 27 Patrick McManus [:mcmanus] 2012-04-03 12:57:54 PDT
*** Bug 739661 has been marked as a duplicate of this bug. ***
Comment 28 Honza Bambas (:mayhemer) 2012-04-03 16:57:17 PDT
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.
Comment 29 Patrick McManus [:mcmanus] 2012-04-04 06:55:48 PDT
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]
Comment 30 Volkmar Kostka 2012-04-04 08:30:26 PDT
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.
Comment 31 Volkmar Kostka 2012-04-04 08:59:03 PDT
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.
Comment 32 Patrick McManus [:mcmanus] 2012-04-04 09:11:44 PDT
(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?
Comment 33 Volkmar Kostka 2012-04-04 10:52:00 PDT
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.
Comment 34 Patrick McManus [:mcmanus] 2012-04-04 12:46:55 PDT
(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.
Comment 35 Volkmar Kostka 2012-04-04 14:33:28 PDT
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.
Comment 36 alex_mayorga 2012-04-04 14:50:50 PDT
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?
Comment 37 Patrick McManus [:mcmanus] 2012-04-04 17:05:57 PDT
(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.
Comment 38 Honza Bambas (:mayhemer) 2012-04-04 17:10:28 PDT
(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...
Comment 39 Volkmar Kostka 2012-04-05 02:54:51 PDT
 	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.
Comment 40 Volkmar Kostka 2012-04-05 03:14:09 PDT
Link to Dumpfile:
https://mediencenter.t-online.de/guestview/index/token/981e1b3ab84a0
Comment 41 Volkmar Kostka 2012-04-05 07:14:35 PDT
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
Comment 42 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-04-05 07:20:44 PDT
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.
Comment 43 Patrick McManus [:mcmanus] 2012-04-05 07:25:02 PDT
(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.
Comment 45 alex_mayorga 2012-04-06 05:57:25 PDT
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!
Comment 46 Volkmar Kostka 2012-04-10 03:33:17 PDT
My high load profile works again.
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120409 Firefox/14.0a1 Firefox/14.0a1
Comment 47 Patrick McManus [:mcmanus] 2012-04-10 07:43:52 PDT
*** Bug 740319 has been marked as a duplicate of this bug. ***
Comment 48 Patrick McManus [:mcmanus] 2012-04-11 13:04:12 PDT
*** Bug 739027 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.