Closed Bug 875079 Opened 12 years ago Closed 11 years ago

OmxDecoder is not destroyed when audio app is killed

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: diego, Unassigned)

References

Details

The crash in bug 864188 happens because the OMXCodec is shut down in an unexpected state. Bug 871018 has a patch to workaround this in OMXCodec, but the problem of the improper deinit of OmxDecoder still remains.
Just some more information about this bug: the problem here is that the app aborts itself at the beginning of a shutdown when it sees that the RPC channel to the main process is getting closed. The patch in bug 864188 fixes this by counting the is-closing state as being-still-open. It was rejected because this might have unknown consequences to the rest of the RPC channel. I found it hard to find reviewers for the patch, because there seems to be no-one who really understands the RPC-channel code. As a first step towards fixing this problem, I suggest documenting the RPC channel, it's states and behaviour.
To be clear, the change proposed in bug 864188 was not rejected simply because it's risky. It was a big change to the way our multiprocess architecture is set up... Currently when the parent closes the pipe to a child process it expects that process to die, more or less immediately. That could be because the parent has detected bad child behavior (maybe the child is hacked or something), or maybe memory is running low and we need to kill a process immediately. In either case the goal is to have a quick death, not to allow the child to continue to do other stuff for a while and then gracefully close. If normal child process shutdown is hitting this case then we could rework the parent/child shutdown sequence to make sure we keep the pipe open long enough for the child to finish its work. However, we have to keep in mind that child processes will not always have a graceful shutdown, so nothing vital should happen in the child.
Sounds like perhaps we needs a service on the main thread to ensure HW media resources clean up
s/main thread/main process
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.