Pmctools: Known Bugs
The current bug list may be viewed at the following issue tracker.
Old bug list
This page lists known bugs in the PMC code.
- Profiling of multi-threaded programs has bugs. The symptoms are that multi-threaded programs do not exit cleanly. (Reported by David Fresse).
- pmcstat -P appears to be missing samples (reported by Niklas Sorensson).
PCSAMPLE event logs should indicate a CPU# that the sample was taken on. We could reuse the pl_usermode 'int' field for this, keeping the CPU# in a higher numbered bitfield.
- On the AMD64, an INVARIANTS-enabled kernel reports a memory leak at module unload time for memory type "pmc". It appears that a log buffer is being leaked (from the size of the leak).
Forcibly unloading the hwpmc(4) module when it is in use shows up other leaks. (Reported by wkoszek@).
- A WITNESS/INVARIANTS enabled AMD64 kernel reports the following lock-order reversal:
hwpmc: TSC/1/0x20 K8/4/0x1ff lock order reversal: 1st 0xffffffff80564ea0 pmc shared lock (pmc shared lock) @ /home/fcpi/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:2527 2nd 0xffffffff80564fc0 proctree (proctree) @ /home/fcpi/src/sys/kern/kern_fork.c:301 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x4f9 _sx_slock() at _sx_slock+0x4d fork1() at fork1+0xf5 kthread_create() at kthread_create+0x96 pmclog_configure_log() at pmclog_configure_log+0x12f pmc_syscall_handler() at pmc_syscall_handler+0x1e6 syscall() at syscall+0x215 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8008dfa9c, rsp = 0x7fffffffe4e8, rbp = 0x7fffffffe510 ---
- Only dump kernel and process mappings once per owner process and only when a sampling PMC is configured. Currently we always log mappings, but this information is useless for log files that are being used in counting mode.
- (reported by v.sriram) pmc_start(3) sometimes does not cause the hardware counter to be started. Inserting a sleep(3) call after the pmc_start() call makes stuff work. I thought I had fixed this bug!
- (reported by ssouhlal@) running pmcstat -S on a dual AMD64 results in an occasional double fault. This is mitigated by using a separate stack for NMI interrupts. Bumping up the KSTACK size does not help.
(reported by rwatson) pmcstat -S on a P4 HTT box caused a stray NMI if interrupted with a ^C. See -current for analysis: the NMI is probably being handled after the WRMSR in p4_stop_pmc turns off the PMC. Issue 30
- (reported by alfred) hwpmc does not deal with sparse CPU numbering correctly.