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

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect, P3)

Description

[Jerome Lacoste]

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:
http://www.mozillazine.org/talkback/read.php?f=2&i=2457&t=2457

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:
<img
SRC="http://192.168.1.116/axis-cgi/mjpg/video.cgi?resolution=320x240&dummy=garb"
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 http://www.axis.com/

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

[Jerome Lacoste]

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

Comment 2

[Jerome Lacoste]

per comment of scratch, is a duplicate of bug 42224
Cf. http://www.mozillazine.org/talkback/read.php?f=2&i=2466&t=2457

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

[Jerome Lacoste]

*** This bug has been marked as a duplicate of 42224 ***

Comment 4

[Olivier Cahagne]

doron, can you retreive Talkback data please: TB10797167K ?

Comment 5

[David Bradley]

Stack from TB10797167K:
nsMultiMixedConv::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/streamconv/converters/nsMultiMixedConv.cpp,
line 527]
ProxyListener::OnDataAvailable
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 718]
httpValidateChecker::OnDataAvailable
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 878]
nsStreamListenerTee::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 98]
nsHttpChannel::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3000]
nsOnDataAvailableEvent::HandleEvent
[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
1078] 

Comment 6

[Olivier Cahagne]

reopening as I cannot find any similar stack (besides 100595 which crashes at
FindToken)
Jerome, can you reproduce this with a nighlty build too ?

Comment 7

[Olivier Cahagne]

reassigning to darin.

Comment 8

[WD]

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

[Jerome Lacoste]

----------------
WD:

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
browser). 
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...

Jerome

Comment 10

[Jerome Lacoste]

ping!

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
time)
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

[Darin Fisher]

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

[Jerome Lacoste]

Darin,

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

[Jerome Lacoste]

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

[Jerome Lacoste]

Kaboom!

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

[Jerome Lacoste]

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 :)

Comment 16

[WD]

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

Comment 17

[Darin Fisher]

stack from TB12401028G is:

nsMultiMixedConv::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/streamconv/converters/nsMultiMixedConv.cpp,
line 543]
ProxyListener::OnDataAvailable
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 878]
nsStreamListenerTee::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 98]
nsHttpChannel::OnDataAvailable
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3088]
nsOnDataAvailableEvent::HandleEvent
[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
1336] 

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

Comment 18

[Darin Fisher]

here's the point in the code where we crash:

http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp#543

  if (!mNewPart && token > cursor) {

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

nsMultiMixedConv::OnDataAvailable
  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.

investigating...

Comment 19

[Darin Fisher]

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

-> moz 1.3 alpha

Comment 20

[Jerome Lacoste]

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

[Olivier Cahagne]

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."

http://www.axis.com/ftp/pub_soft/cam_srv/cam_2100/latest/relnote.txt

Comment 22

[Darin Fisher]

not a topcrash... stack trace doesn't reveal anything obvious.  pushing out to
next milestone.

Comment 23

[Darin Fisher]

-> default owner

Comment 24

[Jesse Ruderman on Windows]

If Darin can't figure it out, it's INCO.