Closed Bug 651615 Opened 14 years ago Closed 11 years ago

Intermittent test_playback.html, 481921.html, 358679-1.xhtml | Assertion count 1 is greater than expected range (RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0')

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ehsan.akhgari, Assigned: cpearce)

References

Details

(Keywords: intermittent-failure)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1303327169.1303327588.32081.gz Rev3 Fedora 12 mozilla-central debug test crashtest on 2011/04/20 12:19:29 ###!!! ASSERTION: RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0', file pldhash.c, line 707 PL_DHashTableOperate [pldhash.c:707] nsTHashtable<nsBaseHashtableET<nsUint32HashKey, nsAutoPtr<nsOggCodecState> > >::GetEntry [nsTHashtable.h:170] nsClassHashtable<nsUint32HashKey, nsOggCodecState>::Get [nsClassHashtable.h:120] nsOggReader::FindEndTime [nsOggReader.cpp:1036] nsOggReader::GetBuffered [nsOggReader.cpp:1790] nsBuiltinDecoderStateMachine::GetBuffered [nsBuiltinDecoderStateMachine.cpp:1697] nsBuiltinDecoder::GetBuffered [nsBuiltinDecoder.h:445] nsBuiltinDecoderStateMachine::GetUndecodedData [nsBuiltinDecoderStateMachine.cpp:1008] nsBuiltinDecoderStateMachine::HasLowUndecodedData [nsBuiltinDecoderStateMachine.cpp:998] nsBuiltinDecoderStateMachine::DecodeLoop [nsBuiltinDecoderStateMachine.cpp:302] nsRunnableMethodImpl<void (nsBuiltinDecoderStateMachine::*)(), true>::Run [nsThreadUtils.h:346] nsThread::ProcessNextEvent [nsThread.cpp:618] NS_ProcessNextEvent_P [nsThreadUtils.cpp:250] nsThread::ThreadFunc [nsThread.cpp:272] _pt_root [ptthread.c:190] libpthread.so.0 + 0x5ab5 This is probably a thread safety issue. Does any one of you guys think that it's something you'd be interested to look into?
How frequent is this? Is it intermittent?
(In reply to comment #1) > How frequent is this? Is it intermittent? It is intermittent, and it happened for the first time today (that we know of!). But these types of bugs can usually be fixed by code inspection, I believe (although locking issues are usually hard to get right).
I'm assuming that this is the mCodecStates table. It's also possible that there isn't a real bug here, though. pldhash has a DEBUG-only member variable to guard against reentrancy from the various callbacks its API provides. If you do simultaneous table operations on multiple threads, you might also trigger these assertions intermittently due to races on accessing this variable. It also provides a PL_DHashMarkTableImmutable API so that if you intend to: * write to a table * declare at some point that it's immutable * read it on multiple threads without any locking you can do that without this problem. It looks like it's *possible* that's how mCodecStates is used, since it's only mutated in ReadMetadata (is that something done at the beginning)? Is it then read from multiple threads at the same time after being written? If so, exposing PL_DHashMarkTableImmutable on nsTHashtable and using it might be the fix here. But I don't know enough of what the ogg code is doing to know.
(In reply to comment #3) > It also provides a > PL_DHashMarkTableImmutable API so that if you intend to: > * write to a table > * declare at some point that it's immutable > * read it on multiple threads without any locking > you can do that without this problem. > > It looks like it's *possible* that's how mCodecStates is used, since it's only > mutated in ReadMetadata (is that something done at the beginning)? Is it then > read from multiple threads at the same time after being written? Yes, this is what the Ogg decoder is doing. We create a table of the streams muxed into an Ogg file at the start of file load, and then we never change that table again and read from that table in other threads. Sounds like using DHashMarkTableImmutable may be what we want. If we ever decided to support Ogg chaining properly, we'd need to revisit this, but lets cross that bridge when we come to it.
We copy the codec states we're interested in into mTheoraState, mVorbisState, etc. Can we access those directly instead of using the hash table here?
We'd need some way to detect when we jump into the next segment in a chained ogg in that case. We currently detect this (and abort) because the hash table contains an nsOggCodec state for all streams in the current segment, including inactive ones, so we know when we pass into the next segment in the chain because the we can't find an nsOggCodecState for the page at that offset. If we rely solely on mTheoraState and mVorbisState we can't distinguish some other inactive stream from the start of a new segment in a chain. I doesn't look like DHashMarkTableImmutable is exposed on nsClassHashTable. :( Maybe we need an array of serialnos for active streams in the segment instead.
(In reply to comment #6) > I doesn't look like DHashMarkTableImmutable is exposed on nsClassHashTable. :( > Maybe we need an array of serialnos for active streams in the segment instead. I meant to say an array containing the serialnos for all streams in the segment, including inactive ones.
Chris, have you made any progress here?
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that: * Haven't changed in > 6months * Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb} * Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive. I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases). Sorry for the spam! Filter on: #FFA500
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
https://tbpl.mozilla.org/php/getParsedLog.php?id=17832214&tree=Mozilla-Beta
Summary: Intermittent failure in layout/generic/crashtests/481921.html | RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0' → Intermittent 481921.html, 358679-1.xhtml | RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0'
https://tbpl.mozilla.org/php/getParsedLog.php?id=20477445&full=1&branch=mozilla-inbound
Blocks: 404077
No longer blocks: 438871
Summary: Intermittent 481921.html, 358679-1.xhtml | RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0' → Intermittent test_playback.html, 481921.html, 358679-1.xhtml | Assertion count 1 is greater than expected range (RECURSION_LEVEL(table_) > 0: 'RECURSION_LEVEL(table) > 0')
See Also: → 962663
Closing bugs where TBPLbot has previously commented, but have now not been modified for >3 months & do not contain the whiteboard strings for disabled/annotated tests or use the keyword leave-open. Filter on: mass-intermittent-bug-closure-2014-07
Status: REOPENED → RESOLVED
Closed: 13 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.