I have plenty of swap, although it's clear the player is using most of the resident memory. What's going on?

Through the wizardry of Linux memory management the player is "mlocked" in. This means that all the memory that the player uses is forced to be resident in memory - no swapping or paging can take place. This is necessary since we spin the hard disk down and it would be rather inconvenient to have breaks in the music whilst it span back up to find part of the code it had paged out.

The crash you see is most likely inside the glibc version of malloc - it's definitely in a shared library since the address starts with a 4. There is a kernel bug that appears to affect all versions of 2.2.12 (and much earlier) which is why you see the crash dump. Unfortunately, the kernel and parts of glibc aren't really geared up to running an mlocked program that takes up virtually all the memory. We are working on various fixes for this problem but the proper solution requires major changes to the way Linux memory management works.

Is there any hope of running other programs at the same time as the player?

Maybe. You can reduce the amount of memory it uses for caching. Go into /empeg/var and create a file called 'config.ini'. In this file place the following lines:

[Startup]
ReduceCache=n

Where n is the amount you wish to reduce it by in chunks. Currently chunks are 32K+a tiny bit. The developer player only runs with 48 chunks which is why it caches regularly - to start with try reducing specifying ReduceCache=8 to see if that improves things.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)