Hi,
> Also I noticed that gstreamer is not very reliable, at least when using
> it from mplayer. It can freeze or reboot the device sometimes. That's not
> something that should be expected from high level API. If I detect some
> reliable pattern in reproducing these bugs, I'll report it to bugzilla
> for sure. But right now just using mplayer and lots of seeking in video
> can cause these bugs reasonably fast.
First I would recommend using just "top" to see whether mplayer
is either:
- Leaking memory
- Otherwise using too much memory
Either by itself or forcing gstreamer to do that.
If that is the case, the bug is in the mplayer (or gstreamer (plugin))
and it needs to be fixed. For debugging the leaks, I would recommend
using Valgrind on x86.
- Eero
PS. The applications in the device have been done so that they integrate
into the the device memory management framework; if they have dynamic
or large memory usage, before doing large allocs, they check whether
system has enough memory for those, they react to system low memory
notifications etc.
If an application forces the kernel to the OOM (out of memory)
situation, it will by default kill the application requesting
memory. However, if mplayer is run as root, its killing is
avoided (note most of the framework processes are run as normal
user). Also, if you're using Desktop while mplayer triggers
device OOM, it's Desktop using memory and kernel might kill it
(which reboots the device).
FYI: Only way to handle OOM correctly is to avoid triggering it,
trying something "fancy" (in kernel) in that situation is AFAIK
wraught with deadlocks.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
