Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 81024 - oprofile incorrect sample filenames
Summary: oprofile incorrect sample filenames
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: oprofile
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: William Cohen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-03 16:04 UTC by William Cohen
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version: 0.5.4-22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-27 17:18:53 UTC

Attachments (Terms of Use)

Description William Cohen 2003-01-03 16:04:12 UTC
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 20:17:50 UTC
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 20:39:23 UTC
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 21:25:54 UTC
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 17:18:53 UTC
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.