Problem with process resources, not hardware limitations.
 

Hi All,

I am writting some application on embedded device, that has to use mplayer. I want to call mplayer by using system() call, which seems the easiest. However (of course when sufficient number of modules is loaded - significant part of memory is used), I get the error saying "Cannot allocate memory". So this is kind of reasonable I can't do it. However I can call mplayer from within a console and all is fine.
So I thought there may be some issues concerning process limits. So I tried to changed them (such as RLIMIT_NPROC, RLIMIT_AS and few more)(on application startup), by invoking setrlimit (also checked if they were changed by getrlimit, later) and this didn't help.

Maybe some of You do know the solution, how I can make mplayer playing, because this is not a limitation of the hardware, obviously.
Thank You for any response and hint.
Regards,
Krzysztof.

One general thought is that system() tends to work by running another instance of the shell, which may not be the best choice in a embedded situation. One thing you can try to troubleshoot, is to write a program that you run in place of mplayer, that instead displays current resource limits and resource utilization/availability.

It looks like you tried to summarize the situation, but the details may be needed to solve the problem.

For example, when you call mplayer from a console, do you have all the modules to which you referred, also loaded? Exactly which resource limits do you set? For example, in this situation changing NPROC should probably only be an afterthought.

This won't work, since even calling ifconfig doesn't work, when starting mplayer doesn't work.
When I observe "top" results, while playing with my application, mplayer loads correctly, if application takes less than 270m of VSZ. Otherwise, it fails to load with mentioned error.

So I just played around and tried some variations of values that differ with those on my pc (where application never fails).I know that they shouldn't be the same, because these are different types of hardware, but I gave it a try. Also I took into account descriptions in manual of setrlimit. But as I mention, none of them seemed to work.

Thank You for being concerned. If You have any ideas, please share them with me. All the best!
Krzysztof.

system() is effectively a wrapper for fork() and exec(), and system() creates a shell, then runs the command you request on that shell. Ergo, system() uses more memory than just using fork() and exec() directly on the specific command that you wish to run without running another copy of the shell.

So, first, try using fork() and exec() to directly execute a program, don't use system().

Secondly, realize that any thing such as we've been discussing to run another process, creates a duplicate of various memory consuming resources from the original process. You can control that duplication to some extent.

So if you just want to run mplayer, if you don't need all the resources you may have open right before running mplayer, do things such as, look at the man page on fcntl for the usage of FD_CLOEXEC. If you are using a third party GUI toolkit/library/etc., you may not know exactly what resources it uses, you can use something like lsof to determine what resources you may be able to dispense of in the process copy to save memory.

Sir, thank You for Your help.

I haven't solved it fully but it gave me some impuls and I am trying to get things done. Thank You once more, all the best.

How about peeling one layer of the onion? As already noted, system() starts a shell. What happens if you run a shellscript with the same command on the embedded system? Unless the system is very tight on resources, a system resource limit is unlikely, especially as you can run the command from a console. What sort of console -- terminal emulator under X or ... ? Perhaps there is something about the command environment that does not suit the command such as access to the necessary graphical environment. Assuming X, perhaps you need something like export DISPLAY='localhost:0.0' and for the X display user to authorise with Xauthority (sorry -- recollection of details hazy).

I have mplayer running happily from an execve(); it needed both of these two environment strings:

HOME=/home/userhome
DISPLAY=localhost:0.0

Steve

So the distribution is Angstrom and there is no graphical environment installed. Therefore, this limitation You wrote about is not about to happen, am I right? Thank You for ideas :)

IDK Angstrom but if there is no graphical environment, how can mplayer play video? Surely I am not understanding something here!

Ahhh, I see it. I use mplayer to play only audio. It's useful, since I can use it not only to play a host file, but also some stream.

Sorry for misleading You!