Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

mmap() failed is popping up in my .xsession-errors in bursts. But there's no indication about what application it is failing with. How do I look into this after it has happened? I usually discover the failures only when I occasionally switch to my "tail -f .logs/*" workspace.

share|improve this question
up vote 7 down vote accepted

You can use SystemTap for this sort of thing.

  • First, set up your system. You need SystemTap, headers corresponding to your running kernel, and debug symbols for the same. On Debian, getting it working is something like:

    sudo apt-get install systemtap
    sudo apt-get install linux-headers-$(uname -r)
    sudo apt-get install linux-image-$(uname -r)-dbg

    It can be a bit tricky to get it to work, because the kernel headers and symbols need to match your running kernel exactly. Hopefully it's straightforward on Gentoo.

  • Then, save this file as mmap.stp:

    #! /usr/bin/env stap
    # -*- systemtap -*-
    global last_args
    probe syscall.mmap2 {
            last_args[tid()] = argstr;
    probe syscall.mmap2.return {
            errno = errno_p(returnval())
            if (errno != 0) {
                    printf("%s[%d] mmap2(%s) failed: %d (%s)\n",
                           execname(), pid(), last_args[tid()],
                           errno, errno_str(errno));
    probe begin {
    probe end {
  • Run it with

    sudo stap mmap.stp

After it compiles and prints begin, It will watch every mmap() system call and save its arguments. If an error occurs, you'll get output that includes the program name, process ID, arguments, and error code. For example, running this nonsensical program:

int main() {

gives the SystemTap output:

test[9601] mmap2(0x1, 4294967295, PROT_READ|PROT_WRITE|PROT_SEM|0x70, 0x0, 1, 0) failed: 22 (EINVAL)
share|improve this answer
This answer is awesome of course. I should report though that in my case it was a simple case of Thundebird hitting 2.7G VIRT barrier on x86. Time to take pain pills and start converting to amd64. – lkraav Aug 29 '12 at 12:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.