Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 81024 - oprofile incorrect sample filenames
oprofile incorrect sample filenames
Product: Red Hat Linux
Classification: Retired
Component: oprofile (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: William Cohen
Depends On:
  Show dependency treegraph
Reported: 2003-01-03 11:04 EST by William Cohen
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version: 0.5.4-22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-27 13:18:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description William Cohen 2003-01-03 11:04:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Some of the sample file names being used by oprofile to store files in
/var/lib/oprofile/samples are incorrect.

Using the 2.4.20-2.2smp kernel and oprofile-0.4-16 on a P4 machine.

For example after running oprofile for a while measuring GLOBAL_POWER_EVENTS and
the examining the data with op_time find that some of the modules do not have
the correct path listed in op_time

5015       0.2122 0.0000 /lib/scsi_mod.o.gz
5654       0.2392 0.0000 /lib/aic7xxx.o.gz
8770       0.3711 0.0000 /lib/ext3.o.gz
14901      0.6305 0.0000 /lib/jbd.o.gz

Looking in /var/lib/oprofile/sample the corresponding files are


These should be


Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Actual Results:  No every file in /var/lib/oprofile/samples maps back to a file
on the machine.

Expected Results:  Expect that each file in /var/lib/oprofile/samples maps back
to a file on the machine.

Additional info:
Comment 1 William Cohen 2003-01-03 15:17:50 EST
oprofile gets the path for the module from /proc/ksyms. It appears that the
/proc/ksyms has incorrect information for some of the modules.

dfd20000 __insmod_ext3_O/lib/ext3.o.gz_M3E035AEB_V132116        [ext3]
dfd50000 __insmod_jbd_O/lib/jbd.o.gz_M3E035AEB_V132116  [jbd]
dfd80000 __insmod_aic7xxx_O/lib/aic7xxx.o.gz_M3E035AE5_V132116  [aic7xxx]
dfdf0000 __insmod_sd_mod_O/lib/sd_mod.o.gz_M3E035AE4_V132116    [sd_mod]
c2200000 __insmod_scsi_mod_O/lib/scsi_mod.o.gz_M3E035AE4_V132116        [scsi_mod]
Comment 2 William Cohen 2003-01-03 15:39:23 EST
The problem is due to the way that oprofiled obtains the path for a module.
oprofiled extracts the information from /proc/ksyms. Unfortunately, modules in
the initrd are have different path. Thus, modules loaded from the initrd do not
have an appropriate path in the /proc/ksyms.
Comment 3 Bill Nottingham 2003-01-06 16:25:54 EST
oprofile could do a filetree walk under /lib/modules/`uname -r`/ to find the
correct path. (Just an idea.)
Comment 4 William Cohen 2004-08-27 13:18:53 EDT
For RHEL3 oprofile (oprofile-0.5.4-22)
opd_kernel.c:opd_reread_module_info() obtains the information from
/proc/ksyms for example and entry from /proc/ksyms:


Note that oprofile-0.8 has completely different logic for handling the
modules and that won't give the complet path to modules.

Note You need to log in before you can comment on or make changes to this bug.