Stream of compressed images served from webcam stop being refreshed - can crash mozilla [@ nsMultiMixedConv::OnDataAvailable ]




16 years ago
7 years ago


(Reporter: Jerome Lacoste, Unassigned)




Firefox Tracking Flags

(Not tracked)


(crash signature)



16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3

The problem was first reported on mozillazine:

On our network, an Axis 2100 web cam serves images on its built-in Linux web server.
I access the images by opening a page that contains an IMG tag pointing to a
cgi-script on the server:
HEIGHT="240" WIDTH="320" ALT="Moving Image Stream">

The pages loads nicely but after a while ( < l min), the pages appear to freeze.
The images do not refreh and the browser stops reloading from the CGI. (this is
shown by the status bar, the stop-button and the throbber stop being refreshed).

The problem is exhibited on Mozilla 1.1 on Windows 2000, Windows NT 4.

In Mozilla 1.0, which was also tested on Linux Debian 3.0 (which I use to report
the problem), the problem is even worse.

On the other side Opera 6.01 on the same Debian machine does not have any
problem with the refresh.
(IE uses another mecanism - an ActiveX component - to get the images).

The web cam is supposed to work with Netscape clients (up to version 6). More
info at

I also had a crash on NT4 after a freeze, but I do not know yet if they are
related. I will post the talkback ID when I get it.

Reproducible: Always

Steps to Reproduce:
1. load page
2. wait for a while

Actual Results:  
Images stop being refreshed

Expected Results:  
Images are refreshed

Do not take care of my Debian specific User agent as the problem also appear on
non-modified Mozilla Windows build.

Comment 1

16 years ago
More information on the crash the other day: crash TB10684239W.

I spent some time tracking down the problem today. 
I recrashed mozilla. New TB10797167K.

The crash is not 100% reproductible, but the freeze is.

I am not 100% sure the bug I reported here and the crash are related, but they
seem to be: in both cases, the crash happened less than 2 seconds after thre
freeze of the image.

I will try to find a way to reproduce the crash consistently.

Added crash to summary, change severity to Critical
Severity: normal → critical
Summary: Stream of compressed images served from webcam stop being refreshed → Stream of compressed images served from webcam stop being refreshed - can crash mozilla

Comment 2

16 years ago
per comment of scratch, is a duplicate of bug 42224

Apparently crash is not fixed. And WONTFIX is not a solution for me. Opera works.
I wanted to use Mozilla to deploy our application, but I cannot put it on a
display without keyboard and mouse if the user must do a refresh every 30 seconds.
Sorry guys, that do not seem to be the correct solution for me.

Comment 3

16 years ago

*** This bug has been marked as a duplicate of 42224 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 4

16 years ago
doron, can you retreive Talkback data please: TB10797167K ?
Keywords: crash, stackwanted
Whiteboard: [has talkback ID] TB10797167K

Comment 5

16 years ago
Stack from TB10797167K:
line 527]
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 718]
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 878]
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 98]
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3000]
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerProxy.cpp, line 204]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 597]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 530]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line

Comment 6

16 years ago
reopening as I cannot find any similar stack (besides 100595 which crashes at
Jerome, can you reproduce this with a nighlty build too ?
Component: Browser-General → Networking: HTTP
Keywords: stackwanted
Resolution: DUPLICATE → ---
Summary: Stream of compressed images served from webcam stop being refreshed - can crash mozilla → Stream of compressed images served from webcam stop being refreshed - can crash mozilla [@ nsMultiMixedConv::OnDataAvailable ]
Whiteboard: [has talkback ID] TB10797167K


16 years ago
Ever confirmed: true

Comment 7

16 years ago
reassigning to darin.
Assignee: asa → darin

Comment 8

16 years ago
Reporter:  Do you see the problem with a nightly build (or even 1.1 ?)
The fix for bug 94734 probably fixes this, but didn't make it into 1.0.   It's
in 1.0.1 and 1.1 and later, though.

Comment 9

16 years ago

As said in my first report, 

> The problem is exhibited on Mozilla 1.1 on Windows 2000, Windows NT 4.
The correct User-Agent and build identifier can be found on bug 164005, as I
used the same browser to report another bug.
I copy them here:
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020818
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020818

The linux machine was used to report the bug.

Unfortunately I do not manage to reproduce it consistently (i.e. it takes me
time to reproduce it). And I cannot spend too much time at work for it.
I know that when Mozilla is freshly started I usualy have no problem. But I kept
the image stream on one tab and kept reloading it once in a while. I spend time
switching tabs also (I often have between 4 and 10 tabs open when I use the
Note: I also know that the profile I used in at least one of the crashed
sessions has some mime-types related problems. But I can't think how this could
be related related.

Question: do both talkback reports point to the same stacktrace?

I will see wether I have time to test with Mozilla 1.2a. If I could take the web
cam at home for a week-end...


Comment 10

16 years ago

We have plenty of problems with IE, and the only bug Mozilla  has (in our
project) is (currently) that one. My project leader told me that if this bug is
solved, we will distribute mozilla on production.

I tried using 1.2 nigthly and the browser crashed again. 
My version of the nigthly was: 
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20020930

Steps to reproduce
1 look at the image flow
2 image flow stops (there was a weird flickering of the whole screen at the same
3- refresh page to restart image flow
4- wait for 30 seconds
5- image flow stops
6- browser crashes 2 seconds after.

Unfortunately I wasn't running a talkback enabled build (why do you link
non-talkback enabled nightlies from the main page? Aren't there for tests
purposes?). I tried again with a talkback enabled build without luck. Perhaps
these builds are less crashable?

I am going to download one of the latest nightlies, now that the tree is beeing
branched and try to crash it again.

- this bug is obviously a duplicate of bug 42224, marked WONTFIX.
- I do not understand why a bug that creates crashes is marked WONTFIX. That is
purely wrong to me.
- I will try to contact Axis the maker of our network camera, to see if they
have a fix for the corrupted image stream.

Comment 11

16 years ago
Jerome: thanks for the feedback.  is it possible that you can provide an URL to
a live testcase?  or if you could simply get talkback to fire when you crash one
of the moz 1.2 nightlies that would be fine.  the stack in comment #5 isn't much
use w.r.t. moz 1.2 ... there have been some changes to the multipart stream
decoder since moz 1.0.  thx!

Comment 12

16 years ago

I am doing my best to reproduce the damn thing. 
The talkback IDs mentionned in comment 5 were obtained using mozilla 1.1.

See comment #1:
"The problem is exhibited on Mozilla 1.1 on Windows 2000, Windows NT 4."

(mozilla 1.1 on NT crashed and I used mozilla 1.0 on Debian to report the bug)

Comment 13

16 years ago
BTW if there is any log file I can create by enabling some trace functionality,
just tell me which settings should I use.

Comment 14

16 years ago

Possible talkback candidate: TB124000361X

I had 3 tabs opened on the different HTML pages containing link to images coming
from the server. I just opened a 4th tab for surfing and kaboom.

I will try to get others, but they aren't easy to come.

Comment 15

16 years ago
other candidates: TB12401028G TB12401460W
I've found a more reliable way of helping to reproduce:
there is a note in the trouble shooting section of the Axis 2100 v2.12 that says
that using different image resolutions on different clients stress more the
network camera. I opened 3 windows, one with 320x240 one with 640x480 (with a
META refresh tag) and one with javascrip refreshed image. It crashed within 5
minutes wihtout me having to press refresh. nice :)


16 years ago
Keywords: stackwanted

Comment 16

16 years ago
Jerome: Those talback stacks are the same as described in comment #5

Comment 17

16 years ago
stack from TB12401028G is:

line 543]
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 878]
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 98]
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3088]
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerProxy.cpp, line 204]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 645]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 578]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line

notice that the line number is different from that in comment #5.

Comment 18

16 years ago
here's the point in the code where we crash:

  if (!mNewPart && token > cursor) {

here's the local variables inside OnDataAvailable at the point of the crash:

  this = 0x00000c60
     (*this) = Data not available
  request = 0x03e2e3a0
     (*request) = Data not available
  context = 0x00000000
     (*context) = Data not available
  inStr = 0x0520e0c0
     (*inStr) = Data not available
  sourceOffset = 38554 (0x0000969a)
  count = 3157 (0x00000c55)
  channel = {nsCOMPtr<nsIChannel>}
  buffer = 0x03e2e3a0
     (*buffer) = Data not available
  read = 3157 (0x00000c55)
  tokenLinefeed = 3157 (0x00000c55)
  bufAmt = 3157 (0x00000c55)
  rv = 0 (0x00000000)
  bufLen = 3168 (0x00000c60)
  cursor = 0x03e2e3a0
     (*cursor) = Data not available
  token = 0x03e2eff3
     (*token) = Data not available
  token = 0x00000c55
     (*token) = Data not available
  done = 86040768 (0x0520e0c0)
  done = 1244364 (0x0012fccc)

|this| looks like a garbage pointer, which could explain the crash.  there also
unfortunately appear to be 2 addresses for |token|.  the first seems fine, but
the second looks like junk.  |cursor| seems reasonable.  i'm going to guess that
the problem is the |this| pointer.

also notice that unlike the stack trace in comment #5, this one doesn't involve
the imagelib validator.  otherwise, they are probably the same stack.


Comment 19

16 years ago
this crash (on line 543) is definitely occuring regularly (couple times per week).

-> moz 1.3 alpha
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha


16 years ago
Keywords: stackwanted


16 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 20

16 years ago
Just to say that I won't be able to help you anymore with that bug. Our Axis
camera had its software upgraded, which solved the streaming problem.

Comment 21

16 years ago
From Axis 2100 release notes:
"1. Image stream
Read blocked error causing interruptions in the image stream has been corrected.
2. Image buffer 
An error causing multiple transfers of cached images has been corrected."


15 years ago
QA Contact: asa → benc


15 years ago
Target Milestone: mozilla1.3beta → mozilla1.4alpha

Comment 22

15 years ago
not a topcrash... stack trace doesn't reveal anything obvious.  pushing out to
next milestone.
Severity: critical → major
Priority: P1 → P3
Target Milestone: mozilla1.4alpha → mozilla1.5alpha


15 years ago
Target Milestone: mozilla1.5alpha → Future

Comment 23

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: benc → networking
Target Milestone: Future → ---
If Darin can't figure it out, it's INCO.
Last Resolved: 16 years ago9 years ago
Resolution: --- → INCOMPLETE


7 years ago
Crash Signature: [@ nsMultiMixedConv::OnDataAvailable ]
You need to log in before you can comment on or make changes to this bug.