Closed Bug 100595 Opened 23 years ago Closed 22 years ago

crash [@ nsMultiMixedConv::FindToken] [was: sandiegozoo.org - this site crashes the browser, every time]

Categories

(Core :: Networking, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: pete, Assigned: darin.moz)

References

()

Details

(Keywords: crash, testcase, topcrash+, Whiteboard: [adt1 RTM][ETA 05/28])

Crash Data

Attachments

(7 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20010917
BuildID:    2001091703

I've tried going to this site through a link, and just typing it in to the
address bar. either way, it crashes before anything is displayed.

Reproducible: Always
Steps to Reproduce:
1. visit this link,
http://www.sandiegozoo.org/special/pandas/pandacam/index.html
wfm 2001091910 linux
Works for me: Windows NT SP6a, build 2001091703
Keywords: crash
i've just retried the link that was crashing for me, and it does
work for me now as well. no crash. perhaps the only way to track
down the problem is looking over the two "Talkback" reports that
were sent in when the browser died?
just to make me look foolish, mozilla struck again. right after my
previous comment, which mentioned it looked like it was working for
me, i hit the link one more time. it crashed the browser on me and 
i sent in the talkback info.

is there anything i should to when viewing this site that would
help anyone isolate this bug?
reproter: go to mozilladir\components,  open talkback.exe and get the
talkbackid's and post them here, thanks
Here are the 3 talkback crash reports. the last two were the
ones i got in the morning, the first one was from later that
day.

TB35618502Q
TB35603828G
TB35603735Y
Incident ID 35618502
Stack Signature nsMultiMixedConv::FindToken 4c0627e3
Bug ID
Trigger Time 2001-09-19 17:23:52
Email Address pete@visionart.com
User Comments I've already filed this as a bug, just when it seems it was
working for everyone, it crashed on me again. Seems to happen almost every time,
but turns out it did work for me once?
Build ID 2001091709
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
nsMultiMixedConv::FindToken
[d:\builds\seamonkey\mozilla\netwerk\streamconv\converters\nsMultiMixedConv.cpp,
line 973]
nsMultiMixedConv::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\streamconv\converters\nsMultiMixedConv.cpp,
line 504]
ProxyListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 402]
nsStreamListenerTee::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp, line 57]
nsHttpChannel::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2255]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 188]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
0x0017000f 
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc
darin
Assignee: neeti → darin
using a 20011001 build under linux, i cannot repro the crash.  instead we just
never load the zoocam.  using telnet i tried to load the zoocam page, but the
server never responded... it just closed the connection.  so, it looks like
reproducing this bug is going to be difficult.

reporter: can you still reproduce this crash using a recent nightly build?
yes, it still crashes. an all white blank page appears, then 2 seconds later it
crashes. this is with build #2001100203, from a couple days ago. i sent the
talkback info in, it is incident number TB36276774G.
*** Bug 98184 has been marked as a duplicate of this bug. ***
*** Bug 103407 has been marked as a duplicate of this bug. ***
Keywords: topcrash
Summary: this site crashes the browser, every time → this site crashes the browser, every time [@nsMultiMixedConv::FindToken]
i'll try to investigate this for 0.9.6
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
ok, i was able to repro this using an optimized winnt build... here's the packet
that causes us trouble:

T 216.120.90.235:80 -> 208.12.39.149:2069 [AP]
  HTTP/1.1 200 OK..Date: Thu, 11 Oct 2001 00:05:27 GMT..Server: Apache/1
  .3.9 (Unix)..pragma: no-cache..cache-control: private..Connection: clo
  se..Transfer-Encoding: chunked..Content-Type: multipart/x-mixed-replac
  e;boundary=CamZoneRS....123..HTTP/1.1 200 OK..Date: Thu, 11 Oct 2001 0
  0:05:27 GMT..Server: Apache/1.3.9 (Unix)..pragma: no-cache..cache-cont
  rol: private..Connection: close..Transfer-Encoding: chunked, chunked..
  Content-Type: multipart/x-mixed-replace;boundary=CamZoneRS....Content-
  type: image/jpeg.Content-length: 13810....35f2........JFIF............
  .C................................... $.' ",#..(7),01444.'9=82<.342...
  C...........2!.!22222222222222222222222222222222222222222222222222....
  ....@.."............................................................}.
  .......!1A..Qa."q.2....#B...R..$3br........%&'()*456789:CDEFGHIJSTUVWX
  YZcdefghijstuvwxyz....................................................
  ......................................................................
  ....w.......!1..AQ.aq."2...B.....#3R..br...$4.%.....&'()*56789:CDEFGHI
  JSTUVWXYZcdefghijstuvwxyz.............................................
  .......................................?...G&..j.=*..2...>..w..I9..j..
  RY.Y.^.F.4....f...;a... {..ü.y...b.Jk. .qU........`..p@?Z..}j\.;XE.H:.
  ji..7...PK$p'.,....b.....p....F.......$.......q...:,......p)...2.Io..P
  p..P..O.Gcd.........._u.....q.q>..k.?...i$.U.....E

there are actually a couple major problems with this packet.  first, the
server claims that the data will be sent using a chunked transfer encoding,
but it doesn't do the chunked encoding properly.  it appears that each
section of the multipart document is individually chunked.  this does not
follow the specifications for the chunked transfer encoding [see RFC2616].

the server should instead apply the chunked transfer encoding to the multipart
document.  this would achieve the desired (streaming) effect.

somehow, IE6 manages to handle this very badly formed document.  i don't think
the effort required to support this broken server will be worth it.

-> evangelism
Assignee: darin → bclary
Status: ASSIGNED → NEW
Component: Networking → English: US
Product: Browser → Tech Evangelism
QA Contact: benc → zach
Version: other → unspecified
actually, it appears that the server is not serving IE6 a multipart document.
i'm not sure why the server is not sending us the same kind of content...

oh, but upon inspection of the html source, it appears that the code is requesting
a different URL when used with IE.

and, with Netscape4x, the server does not send the Transfer-Encoding: chunked
header, so the 4x doesn't have any trouble loading the page.

so, it appears that the server just decides to send junk to mozilla :-/
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011  crash. 
Talkback ID #TB36635201G

Recommend setting OS to All.
ok, this is a problem with that server but I think mozilla should not crash !
we need to spawn a new bug off to deal with the crash and evang this site
Summary: this site crashes the browser, every time [@nsMultiMixedConv::FindToken] → sandiegozoo.org - this site crashes the browser, every time [@nsMultiMixedConv::FindToken]
Darin, 

I think we can evangelism the site although getting a Server to change it's
responses has more inertia than getting an author to change html.

Regardless of the validity of the Server response, I agree that Mozilla *should
not* crash. Please take this bug back as a product bug.  

I have created bug 104601 to handle the evangelism of the site and am giving
this bug back to you.
Assignee: bclary → darin
Component: English: US → Networking
Product: Tech Evangelism → Browser
QA Contact: zach → benc
Version: unspecified → other
ok... makes sense.
View Source Works.

view-source:http://www.sandiegozoo.org/special/pandas/pandacam/index.html

Maybe that'll help us figure out if this is coming from a crash we already know 
about.  :D
Disable JavaScript, page renders, no crash.  There's a lot of script in this 
page; the script is definitely responsible.

DOM, ECMA?
This is too good for me to miss. :D
Ok, here are the possible suspects.  First script:

<script language="JavaScript">

<!-- hide from JavaScript-challenged browsers



function openWindow(url, name) {

  popupWin = window.open
(url,'name', 'width=200,height=250,left=left');popupWin.focus();

}



// done hiding -->

</script>

Second script:
<script language="JavaScript">


<!-- hide me from antiquated technology

    function open_window(url) {
        mywin = window.open
(url,"mainadd",'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars
=1,resizable=1,width=300,height=300,alwaysRaised=yes');
        mywin.focus();
    }

// stop hiding me -->

</script>

Third script:
 <script language=JavaScript>
var framecount=0
var maxframes=300
function msiestreamer(theImage) {
   var now = new Date()

   ++framecount
   secs = now.getTime()
   if (framecount <= maxframes) {
      var camzone="http://zoorr.camzone.com/cams/zoocam/.camzone-ie?87+" + 
framecount + "+" +secs
      theImage.src=camzone
   } else {
      framecount=-1
      return
   }
}
if (navigator.appName == "Netscape")
  document.write('<img src="http://zoorr.camzone.com/cams/zoocam/.camzone?87" 
border=3 width=320 height=240 alt="CamZone">')
else
  document.write('<img NAME="ieanim" 
src="http://www.camzone.com/images/intro.jpg" width="320" height="240" 
alt="CamZone" border="3" onLoad="msiestreamer(this)">')
</SCRIPT>

Another possible (highly unlikely):
<a href="javascript:open_window('faqs.html')"><font size="1">Problems 
        viewing our cam?</font></a>

And again (unlikely)
 <script>

<!-- This script and many more are available free online at -->
<!-- The JavaScript Source!! http://javascript.internet.com -->

<!-- Begin
if (window != top) top.location.href = location.href;
// End --></script>

I haven't checked event handlers.  But considering the page crashes before we 
see anything, I think we can rule out most of them.
TB36970299Y on the crasher script.

All of a sudden, though, I'm having a lot of trouble trying to reproduce it.
Something very unusual just happened.  About five minutes after I posted the
attached crash case, my browser stopped crashing.  I was tinkering around,
trying to reduce the testcase even further.

So, for the moment, can someone besides me attempt to reconfirm the original
testcase for this bug as still crashing the nightlies?  If so, can that person
also attempt to confirm my own crash case?

For me, the documents now load normally.  An image from their videocam comes up
nonexistent.

In the meantime I just picked up another clue.

http://zoorr.camzone.com/cams/zoocam/.camzone?87

If you try to download that, Mozilla reports mime-type application/octet-stream.
 The image tag isn't supposed to accept that, I know.  Could that be it?
fwiw, wfm win98 2001101909

I tried the page and the attachment, several reloads ...
Ok, URL link just crashed on me again.  First sequence:

(a) Loaded page, image came up fine.
(b) Reloaded, image never showed.
(c) Reloaded, crash.

Came back to this bug, went to the link again, crash.

Came back to the link, was typing this up in another tab, about one minute
later, crash.

All this a little before 5am, same nightly as before.  Others having trouble
reproducing at this stage.  They have confirmed image sighted and
application/octet-stream mimetype, which is an unusual combination.

Talkback ID's
TB36971416X
TB36971450W
TB36971542E

Very unusual.
when viewing http://zoorr.camzone.com/cams/zoocam/.camzone?87 the first time, an
image appears in the navigator window and I am asked to open/save the type
application/octet-stream.  If I reload, I only see
"http://zoorr.camzone.com/cams/zoocam/.camzone?87" displayed in the navigator
window, and am again asked to open/save.  Then, in the history list, if I put
that url in, the comment next to in italics says, "Image 566553664x56142144
pixels".  Any time I go back to the main san diego zoo page and then return to
the image page, it loads.  If I hit refresh from the .camzone page, it just
gives me the URL.  This was very consistent.

Here's my help:about Mozzila info.  Mozilla 0.9.5
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011

I'm using 98SE, if it matters, and I have not upgraded IE at all, so IE
5.00-264.3500.  No service packs, either (for the OS, office, or IE).  I don't
have DevStudio installed, so system DLLs should all be virgin.
Oh, and quick update: If you get the image to display at
http://zoorr.camzone.com/cams/zoocam/.camzone?87 and then press back (presuming
back goes to the main panda cam page), then the image will display in the panda
cam page, presumably showing what they intended.
still win98 101909

I'm seeing what infinite_8_monkey is seeing, but have a bit more info here ...

The FIRST time I visited this site, the application/octet-stream file that the
server is trying to send (filename is .camzone) has a header of:
n-content-type&to=*/*eg

On every subsequent visit, the .camzone file (same MIME type) has a different
header:
Content-type: image/jpeg

Btw, the image sizes are different every time I reload.  Here is a short list of
a few image sizes:
9540416x9479856
9624896x9490592
9684128x9492528
9743440x9622608
9809056x9309168

(don't bother whipping out the calculator, there doesn't seem to be any pattern.)

After reloading this page many, many times, I eventually can no longer connect
to the site.  I just get a status message of "Connecting to zoorr.camzone.com"
and it eventually times out ...  When it does time out, I get no download window
or anything else (note, I also get no error message.)  I can still connect to
other sites just fine.  If I restart mozilla, I can reconnect to the site &
start the process again, where the image shows up properly.

I will attach the two different .camzone files if someone decides this is necessary.
Well, Darin, Ben, I hope you have enough to track down this bug.  I gave up hope
on this bug at 4:15 am.  :)

Based on the followup reports, I believe I can conclusively state faulty
JavaScript or DOM code is not at fault here.  This is a reversal of the opinion
I held earlier.

That being said, this is still a sporadic bug.  Given the variable results we've
had in downloading the file associated with the img tag, I think it should be
possible to recreate the conditions which cause this crash 100% of the time. 
It's going to require some server-side code -- something I'm actually not
qualified enough on.

I've added the two contributors directly after me as cc's.  They helped out a
lot in irc, helping me to reconfirm first the site's sudden lack of crashing,
then the wacky server image information.

Mr. Schuette tells me, although this is as yet unconfirmed, he was experiencing
damage with his profiles and associated histories after the crash.  He was
unable to consistently reproduce this effect, and no one else has as yet, among
the three of us, seen the same.  

-- quote --
I'm to the point now where if I completely exit mozilla, and come back, the link
would do nothing ... no download window, no nothing. So I cleared my disk cache,
exited, restarted.

...

Same thing ... nothing from that link ... I tried to go into my history to
delete it, and ... I can't. Not only that, I can't delete any of my histroy items.

...

So I exited, ran profilemanager, and created a new profile .... the new profile
can read the image once, just like I could with the other profile ... and then
the same functoinality ...

...

now the interesting thing is, if I delete the item from my history and reload,
the image shows properly again ...

-- /quote --

Also, this just popped up, confirmed, while I wrote this out:

-- quote --
(monkey)ok, so if I take the octest-stream that mozilla saves, strip off
everything before the jpg header, then save it as a .jpg file, then mozilla will
load it properly.

(Schuette) yep. that's what I did.

(monkey)I would suggest that the problem is in the jpeg handling code, dealing
with this random crap, whatever it is... Or at least that's a reasonable place
to look...

(Schuette)The jpg file sequence begins with 0A 0A ... strip off everything up to
that, you'll have a valid jpg

remove the first 45 bytes (so the first bytes are 0A 0A 00 20) from the
Content-type: image/jpg file, and you have a valid .jpg ..

-- /quote -- 

-- quote -- 
(Schuette) further into the 2nd file than I looked before (in my other comment),
there is a header for application/x-unknown-content-type .... the file I
referred to as "n-content-type&to=*/*" has the
application/x-unknown-content-type further into the header ....
-- /quote --

We're currently continuing this debate in #mozillazine.  However, I've opened up
an alternate channel, #bug100595, just in case the #mozillazine crowd wants to
punt us to the side.  :)
We now have a 100% reproducible testcase.  But it's not fun at first.

(1) Make sure you're running this on a localhost server with perl installed.
(2) Unzip the two files in the testcase, such that breakmoz.cgi is in your
cgi-bin directory.
(3) Adjust the shebang in line 1 to match the path to your perl interpreter as
needed.
(4) Edit the image path as given in lines 5 and 7 to point directly to the file.
(5) Navigate in Mozilla through your http://localhost to breakmoz.cgi and
execute the script.

"This browser will self-destruct in five seconds.  Good luck, Ethan."

If anyone needs help downloading and running a testbed Apache server, I
recommend the Firepages phpdev4 build, available at
http://www.firepages.com.au/devindex.htm .
Keywords: testcase
I'm sorry, I need to clarify for the people who will attempt fixing this bug
what happened, in one sentence.

The offending site is sending a videostream of multiple jpeg frames to an HTML
<img /> tag.

This tag is not designed to take multiple jpeg images, only one.  From what I
gather in the context (and I welcome monkey and Mike Schuette to correct me on
this), the multiple mime-types are what causes this topcrash.

Expected results:  A broken image.  Browser ignores the datastream, possibly
presenting the first image in the datastream and closing the rest of the
datastream immediately.

The new testcase, which monkey designed, presents the multiple mimetypes to the
browser via HTTP, where each individual "slide" is a copy of the original frame.  

Based on this summary, I would recommend the HTML parser attempt to handle this
incompatibility.
Considering the stack trace and Darin's comments above, I think that description
of the problem is wrong.
yes, exactly.  this is a case in which we should evangelize the server to NOT
send junk to mozilla.  also, a bclary points out, we should make sure mozilla
doesn't crash, even when sent junk.  a null check in the multipart stream
converter is probably all that is needed.
Status: NEW → ASSIGNED
their HTTP transaction is pretty bad with embedded newlines. In any case I think
I can make it not crash. (taking over)
Assignee: darin → gagan
Status: ASSIGNED → NEW
The last patch fixes the crash. Essentially when we prepend the boundary to the
buffer we blow away the buffer (and cursor was still pointing to it) With this
fix, the cursor starts to point at the correct buffer and hence not crash trying
to parse junk (freed up) data. Darin/Doug r,sr please.
Status: NEW → ASSIGNED
Comment on attachment 55804 [details] [diff] [review]
patch to prevent the crash

needed to reset the cursor to point to the new buffer.
Comment on attachment 55804 [details] [diff] [review]
patch to prevent the crash

sr=darin ...nice work tracking this down!  please add a comment to
the patch to indicate the importance of that line :)
Attachment #55804 - Flags: superreview+
Comment on attachment 55804 [details] [diff] [review]
patch to prevent the crash

nit - you could do:
cursor = tmp = buffer;
Attachment #55804 - Flags: review+
doug: I could! But I won't... cuz I like things a little elaborate :) 
darin: I will add that comment when I check it in.
both: thanks for the quick r/sr 
checked in version 1.67 of nsMultiMixedConv.cpp
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011102

Latest nightly is now showing no crash in the testcase I submitted above.  
Nice.  (Reported from IE6)
Per discussion in #mozillazine, taking the initiative to mark VERIFIED.  :)
Status: RESOLVED → VERIFIED
*** Bug 131761 has been marked as a duplicate of this bug. ***
Attached file Recent crash comments
I looks like this one may still have some issues.
I just attached talkback comments from recent crashes whose signature 
matches the one in this bug. M099 and N622 crashes report a number of webcam 
sites (like the crashes in this bug). The Trunk crashes are something else. 
Judging from the pain of the previous fix I am wary of reopening this one. Esp. 
if the fixes need to be site specific. 

Darin, Gagan, please comment and reopen if necessary. Thanks.
greer: do any of those crash reports include stack traces?  is there any common
failure point?  this could either be a new multipart stream converter problem or
some problem in image lib.  thx!
Darin, here are the latest crashes at this signature from Trunk and M1.0 Branch
builds. The stacks resemble the one in Asa's commnt #7. They differ from each
other in the third frame, one going through the image loader and the other
through the uri loader. Digging in the detailed links (included in the
attachment below each stack) Blake's crash says it was the result of a bad data
block size (null).
ok, reopening to investigate...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
-> me
Assignee: gagan → darin
Status: REOPENED → NEW
greer: should the topcrash keyword stay?
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla1.0.1
We need to keep the topcrash keyword for our tracking. The summary might be out 
of date however.
Summary: sandiegozoo.org - this site crashes the browser, every time [@nsMultiMixedConv::FindToken] → crash @nsMultiMixedConv::FindToken [was: sandiegozoo.org - this site crashes the browser, every time]
See also bug 42224 for problems with nsMultiMixedConv / JPEG push
*** Bug 99262 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0.1 → ---
talkback incident 6259787 shows that this is still happening with the very
latest 1.0 branch builds.

targeting mozilla 1.0.1
Whiteboard: [adt1 RTM]
Target Milestone: --- → mozilla1.0.1
Updating URL to http://webcam315.cede.psu.edu as original one no longer uses
multipart-mixed JPEG streaming, but rather javascript to "pull" individual frames.
so, i spent some time browsing through the talkback data, and i noticed that the
aLen parameter passed into FindToken is almost always something very very
large... usually something like: PRUint32(-1) or PRUint32(-5).  this indicates
that the variable bufLen in OnDataAvailable is getting incorrectly tweaked. 
investigating...
this patch is mostly cleanup, but i believe it fixes a number of places where
we were possibly accessing an array beyond its bounds.	i've also removed some
buffer allocations and copies, which should help with performance.
I've been streaming 3 cams simultaneously for about 20 minutes now (reloading
when broken or stopped), and there have been no crashes at all:
http://webcam315.cede.psu.edu/view/view.shtml
http://dormcam.mine.nu:8080/moztest.html
http://engwear.org/1999/frosh/fungja/push.html
(with darin's patch from comment #64 )
sorry for spam...
WD: great.. thx for the feedback!
Comment on attachment 84369 [details] [diff] [review]
v1 patch (multipart converter cleanup)

looks good.  I was most worried about breaking byte-range's, but that appears
to be working properly.  r=dougt.

please notify the plugin's team about this change.  Have them run regression
tests against acrobat.
Attachment #84369 - Flags: review+
Comment on attachment 84369 [details] [diff] [review]
v1 patch (multipart converter cleanup)

sr=rpotts@netscape.com
Attachment #84369 - Flags: superreview+
fixed-on-trunk
Whiteboard: [adt1 RTM] → [adt1 RTM][fixed trunk]
Keywords: adt1.0.0
Resolving as FIXED based on Darin's comment #70 From Darin Fisher, that this is
fixed on the trunk.

benc - Can you pls verify this on the trunk, and ensure it introduced no
regressions. thanks!
Blocks: 143047
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Whiteboard: [adt1 RTM][fixed trunk] → [adt1 RTM][fixed trunk] [ETA 05/28]
Making this topcrash+ since we have a testcase and it has been fixed on the Trunk.
Keywords: topcrashtopcrash+
Summary: crash @nsMultiMixedConv::FindToken [was: sandiegozoo.org - this site crashes the browser, every time] → crash [@ nsMultiMixedConv::FindToken] [was: sandiegozoo.org - this site crashes the browser, every time]
Is this Windows-only, or do I need to verify more platforms?
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch, pending Driver's
approval.
Ben: From looking at Talkback data, this looks like to be a Windows only crash.
i think that's because we have more windows testers.  this crash could have
easily occured under linux... the related code is completely cross-platform.
reopening to make this easier for me to track... i don't want this to miss 1.0.1
on account of not being on my radar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Comment on attachment 84369 [details] [diff] [review]
v1 patch (multipart converter cleanup)

a=chofmann for 1.0.1
Attachment #84369 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1"
keyword and add the "fixed1.0.1" keyword." in the comments.
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Keywords: fixed1.0.1
Whiteboard: [adt1 RTM][fixed trunk] [ETA 05/28] → [adt1 RTM][ETA 05/28]
Keywords: mozilla1.0.1+
Verified per Talkback. This one isn't showing up in post checkin data.
Status: RESOLVED → VERIFIED
+verified1.0.1.
Crash Signature: [@ nsMultiMixedConv::FindToken]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: