Your problem is described here
http://forums.anandtech.com/showthread.php?p=29103926
it looks like, your kernel is configured to disallow accessing certain memory regions through /dev/mem. The relevant kernel config option is:
Quote:
config STRICT_DEVMEM
bool "Filter access to /dev/mem"
---help---
If this option is disabled, you allow userspace (root) access to all
of memory, including kernel and userspace memory. Accidental
access to this is obviously disastrous, but specific access can
be used by people debugging the kernel. Note that with PAT support
enabled, even in this case there are restrictions on /dev/mem
use due to the cache aliasing requirements.
If this option is switched on, the /dev/mem file only allows
userspace access to PCI space and the BIOS code and data regions.
This is sufficient for dosemu and X and all common users of
/dev/mem.
If in doubt, say Y.
|
Anyway, if an application crashes, take the standard approach and examine the core dump (enable with "ulimit -c 1") to extract some data about the crash. Furthermore you can attach to a running process with gdb: "gdb <executable> <pid>" and change data structures.
But I wonder how you will extract the data from the memory, if you forget to save your work. You must know the memory layout very well for this to work. Nevertheless, remember, that the physical memory layout may be different from the logical layout used by the application. For a core dump the recovery might be possible, if there are debug information available.
I currently see no other option to access the full memory from userspace.