11222 - Assertion: "wrap around" and apprunner lockup

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[tor]

Attempting to visit http://www.projo.com/ (either from the commandline
or interactively) causes apprunner to print the following message and
then lockup.

Assertion: "wrap around" (i_Length - actualBytesRead <= i_Length) at file
/cs/src/mozilla/mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp,
line 141

apprunner then locks up, seemingly stuck in nsBuffer::GetReadSegment():

current thread: t@1
  [1] CreateMonitor(0x63efe8, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfe9238e0
  [2] PR_CEnterMonitor(0x63efe8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe923b18
=>[3] nsAutoCMonitor::nsAutoCMonitor(this = 0xffbeeb28, lockObject = 0x63efe8),
line 194 in "nsAutoLock.h"
  [4] nsBuffer::GetReadSegment(this = 0x63efe8, segmentLogicalOffset = 0,
resultSegment = 0xffbeebd4, resultSegmentLen = 0xffbeebd0), line 244 in
"nsBuffer.cpp"
  [5] nsBuffer::Search(this = 0x63efe8, string = 0xfc708807 "\n", ignoreCase =
0, found = 0xffbeeca0, offsetSearchedTo = 0xffbeec9c), line 388 in
"nsBuffer.cpp"
  [6] nsHTTPResponseListener::ParseHTTPHeader(this = 0x63ee68, aBuffer =
0x63efe8, aLength = 4294966884U, aBytesRead = 0xffbeed64), line 534 in
"nsHTTPResponseListener.cpp"
  [7] nsHTTPResponseListener::OnDataAvailable(this = 0x63ee68, channel =
0x63ef08, context = 0x63ea50, i_pStream = 0x52d3f0, i_SourceOffset = 0, i_Length
= 4294966884U), line 140 in "nsHTTPResponseListener.cpp"
  [8] nsOnDataAvailableEvent::HandleEvent(this = 0x63e928), line 348 in
"nsAsyncStreamListener.cpp"
  [9] nsStreamListenerEvent::HandlePLEvent(aEvent = 0x63e928), line 149 in
"nsAsyncStreamListener.cpp"
  [10] PL_HandleEvent(0x63e928, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfeba3d98
  [11] PL_ProcessPendingEvents(0xb2100, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfeba3b5c
  [12] nsEventQueueImpl::ProcessPendingEvents(this = 0x9c958), line 118 in
"nsEventQueue.cpp"
  [13] event_processor_callback(data = 0x9c958, source = 6, condition =
GDK_INPUT_READ), line 149 in "nsAppShell.cpp"
  [14] gdk_io_invoke(0x140f28, 0x1, 0xa4660, 0x1, 0xfe611930, 0xffbef0b0), at
0xfe63fb20
  [15] g_main_dispatch(0xffbef120, 0xfe613d70, 0x0, 0xfe613cb0, 0xfe611930,
0x3), at 0xfe5ea7b4
  [16] g_main_iterate(0xffffffff, 0x1, 0xfe5eba4c, 0xfe613d78, 0xfe613ce0,
0xfe613d6c), at 0xfe5eaee4
  [17] g_main_run(0xa3748, 0xa3748, 0xfe611930, 0xfe613d70, 0xaab00,
0xfe63faa4), at 0xfe5eb0d8
  [18] gtk_main(0xfe6740a8, 0xfe87d5e0, 0xfe865b1c, 0xa3748, 0x0, 0xfe67105c),
at 0xfe77baa8
  [19] nsAppShell::Run(this = 0x90f98), line 371 in "nsAppShell.cpp"
  [20] nsAppShellService::Run(this = 0xc2490), line 467 in
"nsAppShellService.cpp"
  [21] main1(argc = 2, argv = 0xffbef634), line 744 in "nsAppRunner.cpp"
  [22] main(argc = 2, argv = 0xffbef634), line 811 in "nsAppRunner.cpp"

Comment 1

[Warren Harris]

I've seen this too -- and I inserted the assertion so that we can catch it.

Comment 2

[Paul MacQuiddy]

This hangs Linux, crashes Mac, and loads OK in Windows. Here's the Mac stack
trace, for what it's worth.

Call Stack:    (Signature = .__ptr_glue 376b2233)

   .__ptr_glue


   http.shlb + 0x8300 (0x0ace7f40)


   Network.shlb + 0xc08 (0x0b7a5b78)


   Network.shlb + 0x1f8 (0x0b7a5168)


   PL_HandleEvent()


   PL_ProcessPendingEvents()


   nsEventQueueImpl::ProcessPendingEvents()
                                            [nsEventQueue.cpp, line 117]

   EventDispatchingFunc()
                                            [nsEventQueueService.cpp, line 352]

   _hashEnumerate()
                                            [nsHashtable.cpp, line 81]

   PL_HashTableEnumerateEntries()


   nsHashtable::Enumerate()
                                            [nsHashtable.cpp, line 210]

   nsEventQueueServiceImpl::ProcessEvents()
                                            [nsEventQueueService.cpp, line 363]

   nsToolkit::RepeatAction()
                                            [nsToolkit.cpp, line 144]

   NETLIB_DLL + 0x1bb4 (0x0b9b8564)


   nsMacMessagePump::DispatchEvent()
                                            [nsMacMessagePump.cpp, line 329]

   nsMacMessagePump::DoMessagePump()
                                            [nsMacMessagePump.cpp, line 230]

   nsAppShell::Run()
                                            [nsAppShell.cpp, line 90]

   nsAppShellService::Run()
                                            [nsAppShellService.cpp, line 464]

   main1()
                                            [nsAppRunner.cpp, line 744]

   main()
                                            [nsAppRunner.cpp, line 811]

   .__start

Comment 3

[Daniel Bratell]

I got something similar on Windows. I lookad at
nsHTTPResponseListener::ParseHTTPHeader(...) which seems to cause the problem in
my case and it failed to look at the buffer length (aLength) when reading into
the buffer which causes this abnormalty. I think
nsHTTPResponseListener::ParseStatusLine(...) has the same problem.

I'm cc-ing rpotts since he was the one writing it so he can propably tell me if
I'm wrong.

Quite uninteresting stack trace:
NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x0a462ee4, const char * 0x0a462ebc, const char
* 0x0a462e74, int 141) line 176 + 13 bytes
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const
0x0af120a0, nsIChannel * 0x0bfae2e0, nsISupports * 0x0bfaf1f0, nsIInputStream *
0x0af12200, unsigned int 257367, unsigned int 26) line 141 + 37 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0c520ee0)
line 350
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0c520ee4) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x0c520ee4) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ad90f0) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x007908ec, unsigned int 49397, unsigned int 0,
long 11374832) line 932 + 9 bytes
USER32! 77e71820()
00ad90f0()

Comment 4

[Daniel Bratell]

Changing OS and Platform to "All"

Comment 5

[chris hofmann]

reassign gagan -> rpotts

Comment 6

[leger]

I tested this with Win95 and Mac 8.51 with 1999081608 build.  Page loads and
does not lock up, but it is slow and the layout is ugly.  Would not hold M9 for
this.

rpotts, unless you've got a fix in hand, I would move to M10.  Cool?

Comment 7

[rpotts (gone)]

I can't seem to reporduce this anymore...

I have a feeling that it was a dup of bug #7843.
-- rick

Comment 8

[tor]

On a build from a 7pm pst 8/24 cvs pull I'm seeing this assertation/lockup
behaviour about 90% of the time.  Same site - http://www.projo.com/  Stack
trace looks similiar to the original.

Comment 9

[Paul MacQuiddy]

tor, the change was made on a separate branch, not the one you checked out, I
believe. The change should be merged into the tip in the next day or
so. The page is loading for me fine right now, though the layout is a bit messed
up.

Therefore, I'm going to mark it resolved again, and I will let you verify, but
give it about two days.

Comment 10

[Paul MacQuiddy]

tor, M9 binaries are available. Let us know what you find, thanks. Also, the
changes have been checked into the tip now, so if you checkout, you should see
this fixed also.

Comment 11

[tor]

Assertion/lockup problem is gone in a 8/26 evening pull (post m9 merge).

Comment 12

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.