Closed Bug 82003 Opened 23 years ago Closed 23 years ago

crash in nsMultiMixedConv when loading multipart pages

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: blizzard, Assigned: neeti)

Details

(Keywords: crash)

Build is from May 21, 2001.

This crash is reproducable 100% for me.  Unfortunately, it's on a password
protected page so I can't share the url.  Here's the stack trace.  The result is
a multipart page.

(gdb) where
#0  0x4054a8e1 in __libc_nanosleep () from /lib/i686/libc.so.6
#1  0x4054a761 in __sleep (seconds=300)
    at ../sysdeps/unix/sysv/linux/sleep.c:85
#2  0x080507ef in ah_crap_handler (signum=11) at nsSigHandlers.cpp:114
#3  0x401d2935 in pthread_sighandler (signo=11, ctx=
      {gs = 7, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh
= 0, edi = 1129778313, esi = 1129778313, ebp = 3221221672, esp = 3221221632, ebx
= 1079749092, edx = 1297550477, ecx = 1088421904, eax = 167772164, trapno = 14,
err = 4, eip = 1079049678, cs = 35, __csh = 0, eflags = 2163206, esp_at_signal =
3221221632, ss = 43, __ssh = 0, fpstate = 0xbfffee80, oldmask = 2147483648, cr2
= 1297550481}) at signals.c:97
#4  <signal handler called>
#5  chunk_free (ar_ptr=0x40e00010, p=0x43570c89) at malloc.c:3080
#6  0x4050fd59 in __libc_free (mem=0x43570c91) at malloc.c:3054
#7  0x401a3ffc in PR_Free () at eval.c:41
#8  0x400cc2fa in nsMemoryImpl::Free (this=0x80561f8, ptr=0x43570c91)
    at nsMemoryImpl.cpp:327
#9  0x400cc93b in nsMemory::Free (ptr=0x43570c91) at nsMemoryImpl.cpp:559
#10 0x408a883a in nsMultiMixedConv::OnDataAvailable (this=0x43fcffe0, 
    request=0x4258de68, context=0x0, inStr=0x4339fb38, sourceOffset=0, 
    count=1212) at nsMultiMixedConv.cpp:136
#11 0x40d9a0bf in nsDocumentOpenInfo::OnDataAvailable (this=0x4383efa0, 
    request=0x4258de68, aCtxt=0x0, inStr=0x4339fb38, sourceOffset=0, 
    count=1212) at nsURILoader.cpp:237
#12 0x408a31ba in nsStreamListenerTee::OnDataAvailable (this=0x437d9498, 
    request=0x4258de68, context=0x0, input=0x438b69e4, offset=0, count=1212)
    at ../../../dist/include/nsCOMPtr.h:649
#13 0x408c4836 in nsHttpChannel::OnDataAvailable (this=0x4258de68, 
    request=0x430a3550, ctxt=0x0, input=0x438b69e4, offset=0, count=1212)
    at ../../../../dist/include/nsCOMPtr.h:648
#14 0x40893b39 in nsOnDataAvailableEvent::HandleEvent (this=0x43b66b38)
    at nsStreamListenerProxy.cpp:173
#15 0x4089349b in nsARequestObserverEvent::HandlePLEvent (plev=0x43b66b38)
    at nsRequestObserverProxy.cpp:63
#16 0x400c4a87 in PL_HandleEvent (self=0x43b66b38) at plevent.c:590
#17 0x400c4995 in PL_ProcessPendingEvents (self=0x80ba3e8) at plevent.c:520
#18 0x400c5af7 in nsEventQueueImpl::ProcessPendingEvents (this=0x80ba5c0)
    at nsEventQueue.cpp:374
#19 0x40775af6 in event_processor_callback (data=0x80ba5c0, source=5, 
    condition=GDK_INPUT_READ) at nsAppShell.cpp:168
#20 0x40775845 in our_gdk_io_invoke (source=0x40e1cb38, condition=G_IO_IN, 
    data=0x40e12020) at nsAppShell.cpp:61
#21 0x4035ffae in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#22 0x40361783 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#23 0x40361d49 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#24 0x40361efc in g_main_run () from /usr/lib/libglib-1.2.so.0
#25 0x402768f3 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#26 0x40776026 in nsAppShell::Run (this=0x80f0f50) at nsAppShell.cpp:360
#27 0x4074be5a in nsAppShellService::Run (this=0x80e4918)
    at ../../../dist/include/nsCOMPtr.h:649
#28 0x0804fa37 in main1 (argc=2, argv=0xbffff81c, nativeApp=0x0)
    at ../../dist/include/nsCOMPtr.h:649
#29 0x080502d3 in main (argc=2, argv=0xbffff81c) at nsAppRunner.cpp:1391
#30 0x404ac177 in __libc_start_main (main=0x8050188 <main>, argc=2, 
    ubp_av=0xbffff81c, init=0x804be88 <_init>, fini=0x805211c <_fini>, 
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff80c)
    at ../sysdeps/generic/libc-start.c:129
Here's a fix for the crash.  The problem is that the variable 'cursor' is being
freed when it doesn't always point to the root of the memory as it was
allocated.  'buffer' is the variable that holds the location of the original
allocation.  Looking for r/sr for this.

Index: nsMultiMixedConv.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/streamconv/converters/nsMultiMixedConv.cpp,v
retrieving revision 1.54
diff -u -r1.54 nsMultiMixedConv.cpp
--- nsMultiMixedConv.cpp        2001/05/18 22:22:15     1.54
+++ nsMultiMixedConv.cpp        2001/05/21 22:24:54
@@ -127,13 +127,13 @@
             bufLen = read + mTokenLen + 1;
             char *tmp = (char*)nsMemory::Alloc(bufLen);
             if (!tmp) {
-                nsMemory::Free(cursor);
+                nsMemory::Free(buffer);
                 return NS_ERROR_OUT_OF_MEMORY;
             }
             nsCRT::memcpy(tmp, token, mTokenLen);
             nsCRT::memcpy(tmp+mTokenLen, "\n", 1);
             nsCRT::memcpy(tmp+mTokenLen+1, cursor, read);
-            nsMemory::Free(cursor);
+            nsMemory::Free(buffer);
             buffer = tmp;
         }
     }
Severity: normal → critical
Keywords: crash
nice catch! r=gagan
pulling in... low risk/high gain for 0.9.1
Target Milestone: --- → mozilla0.9.1
rs=darin
Checked in.  Thanks, guys!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
QA Contact: benc → junruh
You need to log in before you can comment on or make changes to this bug.