Closed Bug 464302 Opened 16 years ago Closed 16 years ago

test_seek* tests timing out during mochitest

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1b2

People

(Reporter: benjamin, Unassigned)

Details

(Keywords: fixed1.9.1)

Going over the past two days of tinderbox oranges, there were three test timeouts running various video tests: *** 27561 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/video/test/test_seek3.html | Test timed out (also seek1, seek2, seek7) 1. moz2-linux-slave07 2008/11/09 20:38:43 2. moz2-linux-slave08 2008/11/09 20:37:26 3. moz2-win32-slave07 2008/11/09 19:56:13 I think we need to fix this ASAP so that development doesn't grind to a halt on random orange trees.
Flags: blocking1.9.1+
Dupe of bug 461896 or bug 462933 ? (Also, if you file bugs about intermittent failures, please make them block bug 438871)
I would hope that the checkin for bug 462933 would make these fail less... Are they still failing intermittently?
The three I listed above are the ones that happened in the past few days. Since 462933 landed 2008/11/10 00:14, that may have fixed it. Please feel free to dup this if appropriate.
Should be fixed by bug 462933.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I have caught a couple of these on WinXP, here's a typical call stack for the decode thread: ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_ZwWaitForSingleObject@12() + 0xc bytes kernel32.dll!_WaitForSingleObjectEx@12() + 0x8b bytes kernel32.dll!_WaitForSingleObject@8() + 0x12 bytes nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x06cf0f9c, _MDLock * lock=0x06b26064, unsigned int timeout=4294967295) Line 280 + 0x14 bytes C nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x086bc370, PRCondVar * cvar=0x06cf0f28, PRLock * lock=0x06b26048, unsigned int timeout=4294967295) Line 204 + 0x17 bytes C nspr4.dll!PR_Wait(PRMonitor * mon=0x064eaf90, unsigned int ticks=4294967295) Line 175 + 0x1d bytes C xpcom_core.dll!nsAutoMonitor::Wait(unsigned int interval=4294967295) Line 340 + 0x11 bytes C++ xpcom_core.dll!nsPipeInputStream::Wait() Line 654 C++ xpcom_core.dll!nsPipeInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* writer=0x002d3cf0, void * closure=0x0a16a65c, unsigned int count=8192, unsigned int * readCount=0x09f2fd28) Line 778 + 0x8 bytes C++ xpcom_core.dll!nsPipeInputStream::Read(char * toBuf=0x0a16a65c, unsigned int bufLen=8192, unsigned int * readCount=0x09f2fd28) Line 828 C++ gklayout.dll!nsHttpStreamStrategy::Read(char * aBuffer=0x0a16a65c, unsigned int aCount=8192, unsigned int * aBytes=0x09f2fd28) Line 569 + 0x28 bytes C++ gklayout.dll!nsMediaStream::Read(char * aBuffer=0x0a16a65c, unsigned int aCount=8192, unsigned int * aBytes=0x09f2fd28) Line 845 + 0x24 bytes C++ gklayout.dll!nsChannelReader::io_read(char * aBuffer=0x0a16a65c, unsigned int aCount=8192) Line 80 + 0x17 bytes C++ gklayout.dll!oggplay_channel_reader_io_read(void * aReader=0x069f8ff0, void * aBuffer=0x0a16a65c, unsigned int aCount=8192) Line 122 C++ gklayout.dll!oggz_io_read(_OGGZ * oggz=0x0619de90, void * buf=0x0a16a65c, unsigned int n=8192) Line 71 + 0x16 bytes C gklayout.dll!oggz_read(_OGGZ * oggz=0x0619de90, long n=8192) Line 616 + 0x11 bytes C gklayout.dll!oggplay_step_decoding(_OggPlay * me=0x08c5ccf8) Line 506 + 0x11 bytes C gklayout.dll!nsOggDecodeStateMachine::DecodeFrame() Line 506 + 0xc bytes C++ gklayout.dll!nsOggDecodeStateMachine::Run() Line 995 + 0x8 bytes C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x09f2ff08) Line 511 C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x06123de0, int mayWait=1) Line 227 + 0x16 bytes C++ xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x06123de0) Line 254 + 0xb bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=0x086bc370) Line 436 + 0xf bytes C nspr4.dll!pr_root(void * arg=0x086bc370) Line 122 + 0xf bytes C msvcr80d.dll!_callthreadstartex() Line 348 + 0xf bytes C msvcr80d.dll!_threadstartex(void * ptd=0x06663da0) Line 331 C kernel32.dll!_BaseThreadStart@8() + 0x37 bytes The main thread is waiting for more events, there's no ogg stuff on its stack. nsPipeInputStream::ReadSegments() is waiting for more input. Based on the state of the channel listener and media stream, in this example it appears that we've read about 70K worth of data over the pipe, and then data has just stopped coming in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Does this really block beta 2? I don't think it does, despite being obviously troublesome.
I suggest we don't wait for it. This does make it harder to check new stuff in and have it stick though.
According to https://wiki.mozilla.org/Tinderbox/Nov-2008-Orange-Compendium, this hasn't hit Tinderbox for over a week since 462933 was checked in. I suggest we close this bug as fixed and open a new bug for comment #5 (not blocking beta2).
Chris, please file a new bug for comment #5. As we discussed it sounds like an httpd.js issue.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
(In reply to comment #9) > Chris, please file a new bug for comment #5. As we discussed it sounds like an > httpd.js issue. Agreed, see Bug 465921.
You need to log in before you can comment on or make changes to this bug.