With latest version of perf-core branch, a variant of perf record hangs:

# /tmp/build-perf/perf record -v -e cs -fo /tmp/perf.data  -- sleep 1
couldn't open /proc/-1/status
couldn't open /proc/-1/maps
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.003 MB /tmp/perf.data (~120 samples) ]

It sits there forever. Back trace is:

(gdb) bt
#0  0x0000000000447658 in __perf_session__process_events
(session=0xab9500, data_offset=208,
    data_size=2896, file_size=3104, ops=0x685580) at util/session.c:1006
#1  0x00000000004107dd in process_buildids () at builtin-record.c:466
#2  0x000000000041084d in atexit_header () at builtin-record.c:477
#3  0x00007f45cc3e89e1 in exit () from /lib64/libc.so.6
#4  0x0000000000404749 in handle_internal_command (argc=9,
argv=0x7fffc59e2c70) at perf.c:359
#5  0x000000000040488e in run_argv (argcp=0x7fffc59e2b5c,
argv=0x7fffc59e2b50) at perf.c:403
#6  0x0000000000404a98 in main (argc=9, argv=0x7fffc59e2c70) at perf.c:489


git bisect traced the hang to

commit 55b44629f599a2305265ae9c77f9d9bcfd6ddc17
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Nov 30 17:49:46 2010 +0000

    perf session: Use sensible mmap size

    On 64bit we can map the whole file in one go, on 32bit we can at
least map
    32MB and not map/unmap tiny chunks of the file.

    Base the progress bar on 1/16 of the data size.

    Preparatory patch to get rid of the malloc/memcpy/free of trace data.


If I revert the changes (attached porting of it) perf-record does not hang.

David