Skip to content

Conversation

@soramichi
Copy link
Contributor

@soramichi soramichi commented Nov 29, 2018

Some processors have 8 general purpose counters and 3 fixed counters, so the total would be 11.
The current code allocates data buffer only for 7 (4 + 3) counters, resulting in a SEGV on these processors.

$ cat /proc/cpuinfo | grep 'model name' | uniq
model name	: Intel(R) Xeon(R) CPU E5-1603 v4 @ 2.80GHz

$ sudo ./pcm-core.x 
Number of physical cores: 4
Number of logical cores: 4
Number of online logical cores: 4
Threads (logical cores) per physical core: 1
Num sockets: 1
Physical cores per socket: 4
Core PMU (perfmon) version: 3
Number of core PMU generic (programmable) counters: 8
Width of generic (programmable) counters: 48 bits
Number of core PMU fixed counters: 3
Width of fixed counters: 48 bits
...

@opcm
Copy link
Contributor

opcm commented Nov 29, 2018

which src+line does it crash?

@soramichi
Copy link
Contributor Author

soramichi commented Nov 29, 2018

In my environment, pcm-core.x crashes at line 3100 of cpucounters.cpp (where perfData is destructed) because m->readPerfData(..., perfData) at line 3092 writes 11 * 8 bytes of data to perfData whose length is only 7 * 8.

This may not be repreducible in some envs because buffer overruns do not necessarily cause the same fault in any envs but the phenomenon rather depends on the compiler/libc/kernel version. I use gcc 6.3.0 on Debian stable (stretch).

@opcm opcm merged commit b291be1 into intel:master Nov 29, 2018
@opcm
Copy link
Contributor

opcm commented Nov 29, 2018

thanks!

@soramichi soramichi deleted the fix_max_counters branch November 29, 2018 14:42
rdementi added a commit that referenced this pull request Dec 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants