search

shshankjain / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

webm decoder crash #178

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
With many threads (>=10), webm is spuratically crashing.

What is the expected behavior?
No crash

What do you see instead?
spuratic crashes

What version are you using?
v0.9.2-10-g7f1a908

On what operating system?
Windows 7

Can you reproduce using the ivfdec or ivfenc tools? What command line are
you using?
Probably repros in ivfdec, but I've been using media_bench. ie
media_bench.exe --loop=16 --video-threads=13 --stream=video tulip2.webm

Please provide any additional information below.
I've seen it with 10, 11, and 13 threads.
--loop plays the video over and over, making it easier to reproduce.
This did not happen in 0.9.1.  I suspect its the new 0.9.2 threading code.
Attached is a screenshot, and tulip video

Original issue reported on code.google.com by fbarch...@chromium.org on 16 Sep 2010 at 4:44

Attachments:

GoogleCodeExporter commented 9 years ago 
Does this happen on other platforms (Linux, Mac)?

How many cores does your machine have? What is the partition number in 
tulip2.webm?

Thanks.

Original comment by yunqingw...@google.com on 16 Sep 2010 at 5:35

GoogleCodeExporter commented 9 years ago 
Heh, the word is "sporadic".

Original comment by tdh...@gmail.com on 16 Sep 2010 at 6:06

GoogleCodeExporter commented 9 years ago 
It hasn't been observed on linux or mac.
8 cores/16 threads
4 partitions
Re sporadic. thanks.

Original comment by fbarch...@chromium.org on 16 Sep 2010 at 8:55

GoogleCodeExporter commented 9 years ago 
This also repros the problem
ivfdec.exe -t 13 --summary --noblit tulip.ivf

Original comment by fbarch...@chromium.org on 16 Sep 2010 at 9:27

Attachments:

GoogleCodeExporter commented 9 years ago 
If the file has 4 partitions, the decoder internally sets the # of threads to 
be 4 even though you input "-t 13". I will test it once we have the machine. 
Thanks.

Original comment by yunqingw...@google.com on 16 Sep 2010 at 9:34

GoogleCodeExporter commented 9 years ago 
also repros in ivfdec:

ivfdec.exe -t 11 --summary --noblit tulip.ivf
WebM Project VP8 Decoder v0.9.2-16-g9100073

Takes quite awhile... maybe 1000 interations

Original comment by fbarch...@chromium.org on 16 Sep 2010 at 10:52

Attachments:

GoogleCodeExporter commented 9 years ago 
Doing this in a loop, I reproduced the problem after 46 playbacks

ivfdec.exe -t 4 --summary --noblit tulip.ivf
WebM Project VP8 Decoder v0.9.2-16-g9100073

Unhandled exception at 0x0040d9c2 in ivfdec.exe: 0xC0000005: Access violation 
reading location 0x0065b05c.

Original comment by fbarch...@chromium.org on 20 Sep 2010 at 8:17

GoogleCodeExporter commented 9 years ago 
Frank,

I restructured multi-threaded decoder, which is in Gerrit now. You can pull 
patch from http://review.webmproject.org/#change,551

git fetch git://review.webmproject.org/libvpx refs/changes/51/551/5 && git 
checkout FETCH_HEAD

I tested it on gLucid, and see improvement for t=4. Thank you.

Yunqing

Original comment by yunqingw...@google.com on 20 Sep 2010 at 9:32

GoogleCodeExporter commented 9 years ago 
For what its worth, I ran 1 and 2 threads for more than 4 hours and couldnt 
reproduce it.

I'll request access to Gerrit.
In the meantime, check the result into HEAD once you're confident its safe, and 
I'll retest.

Original comment by fbarch...@chromium.org on 21 Sep 2010 at 1:00

GoogleCodeExporter commented 9 years ago 
I reviewed the commit and it looks good to me, so I approved the commit, it 
should be ready for merging into trunk now. 

I also suggest that we valgrind the decoder with different number of threads 
before and after the merge. 

This issue sounds similar to a stability issue happened some time ago, which 
was tracked down and fixed using valgrind on linux.

Original comment by ya...@google.com on 21 Sep 2010 at 7:00

GoogleCodeExporter commented 9 years ago 
The multi-thread change was merged into GIT, and ready for testing. The 
performance improvement is more noticeable while using threads=4.

Yunqing

Original comment by yunqingw...@google.com on 21 Sep 2010 at 12:06

GoogleCodeExporter commented 9 years ago 
Using v0.9.2-35-ga8a38bc
Bug is fixed, Thanks.

Original comment by fbarch...@chromium.org on 21 Sep 2010 at 8:48

GoogleCodeExporter commented 9 years ago 
I can see you got the new multi-thread code I put in this morning. Glad it 
works for you. Thanks for testing it.

Yunqing

Original comment by yunqingw...@google.com on 21 Sep 2010 at 9:16

GoogleCodeExporter commented 9 years ago 
I can also confirm performance scales up to 8 cores okay.

Original comment by fbarch...@chromium.org on 22 Sep 2010 at 2:04

GoogleCodeExporter commented 9 years ago 
That is great. Could you post the test results for 8 cores? Thanks.

Yunqing

Original comment by yunqingw...@google.com on 22 Sep 2010 at 12:09

GoogleCodeExporter commented 9 years ago

Original comment by jkoles...@google.com on 23 Sep 2010 at 2:06

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 8 Mar 2012 at 12:10