No matter how I try, I can't seem to get a library profile from sprof on CentOS5.
Does anyone know if sprof actually works on CentOS5? I'd be very interested to hear if anyone is using it successfully.
At the moment I'm trying something like this to get the dump:
LD_LIBRARY_PATH=. LD_PROFILE=libmy.so ./mymain
where libmy.so is the library I want to profile, and mymain is the executable which links to it.
This appears to create the profile dump successfully (which appears at /var/tmp/libmy.so.profile), but when I try to get a readable profile using sprof it fails:
$ sprof libmy.so /var/tmp/libmy.so.profile sprof: failed to load shared object `libmy.so'
I have a CentOS4 machine here, and doing the above on that works fine, but I've had no luck at all on CentOS5 (all currently up-to-date).
Can anyone help? (Please!)
On Wed, Jul 9, 2008 at 1:57 PM, Hywel Richards hywelbr@googlemail.com wrote:
LD_LIBRARY_PATH=. LD_PROFILE=libmy.so ./mymain
...
$ sprof libmy.so /var/tmp/libmy.so.profile sprof: failed to load shared object `libmy.so'
Acutally I have no idea of what sprof is or does, but from the error message above it seems sprof cannot find your library because it is not in the default library search path. Try this:
$ LD_LIBRARY_PATH=. sprof libmy.so /var/tmp/libmy.so.profile
Let us know how that goes.
HTH, Filipe
Filipe Brandenburger wrote:
Acutally I have no idea of what sprof is or does, but from the error
Let me tell you about sprof, then, because it is fantastic!
Of course, it would be even better if it worked.
It is a statistical profiler for shared object libraries that (presumably) works by sampling the position of the program counter every now and again. All you need to do is set the value of LD_PROFILE to the name of the .so and statistics will get dumped to a file in /var/tmp.
You can then use sprof to build a profile from those stats in the same way that gprof does from a gmon.out file.
But it's much better than gprof as you don't have to compile with special flags which cause code to get inserted and distorts the timing of your program anyway. And as it profiles .so files it also allows you to easily profile python modules, for example, where you don't want to recompile the main program.
Unfortunately, there does not seem to be much information about it on the internet. It makes me wonder if there is an alternative which has superceeded it (I see oprofile, but it looks a good deal more difficult to use).
message above it seems sprof cannot find your library because it is not in the default library search path. Try this:
$ LD_LIBRARY_PATH=. sprof libmy.so /var/tmp/libmy.so.profile
Let us know how that goes.
No luck with that, I'm afraid:
$ LD_LIBRARY_PATH=. sprof libmy.so /var/tmp/libmy.so.profile sprof: failed to load shared object `libmy.so'
I've tried all sorts to try and coax the program to accept the files - I wonder if it might not just be an unhelpful error message and something else is failing. I have a strace here in case anyone can understand what is going on (is it some locale setting that it doesn't like, perhaps, I don't know much about that stuff - it doesn't seem to attempt to open anything like libmy.so at all):
execve("/usr/bin/sprof", ["sprof", "libmy.so", "/var/tmp/libmy.so.profile"], [/* 39 vars */]) = 0 brk(0) = 0x8c78000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd7000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/tls/i686/sse2/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/tls/i686/sse2", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/tls/i686", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/tls/sse2/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/tls/sse2", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/tls", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/i686/sse2/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/i686/sse2", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/i686", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/sse2/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg/sse2", 0xbf83ced8) = -1 ENOENT (No such file or directory) open("/usr/lib/xorg/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/xorg", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=80005, ...}) = 0 mmap2(NULL, 80005, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fc3000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PJ\251\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=16428, ...}) = 0 mmap2(0xa94000, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xa94000 mmap2(0xa96000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xa96000 close(3) = 0 open("/usr/lib/xorg/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\277\223\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1597968, ...}) = 0 mmap2(0x926000, 1320356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x926000 mmap2(0xa63000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13c) = 0xa63000 mmap2(0xa66000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa66000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fc2000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fc26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xa96000, 4096, PROT_READ) = 0 mprotect(0xa63000, 8192, PROT_READ) = 0 mprotect(0x922000, 4096, PROT_READ) = 0 munmap(0xb7fc3000, 80005) = 0 brk(0) = 0x8c78000 brk(0x8c99000) = 0x8c99000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=56454464, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7dc2000 mmap2(NULL, 884736, PROT_READ, MAP_PRIVATE, 3, 0x1e1) = 0xb7cea000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x6d1) = 0xb7ce9000 close(3) = 0 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ce8000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2528 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7ce8000, 4096) = 0 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "sprof: ", 7sprof: ) = 7 write(2, "failed to load shared object `li"..., 39failed to load shared object `libmy.so') = 39 write(2, "\n", 1 ) = 1 exit_group(1) = ?
Hywel Richards wrote:
No matter how I try, I can't seem to get a library profile from sprof on CentOS5.
Does anyone know if sprof actually works on CentOS5? I'd be very interested to hear if anyone is using it successfully.
At the moment I'm trying something like this to get the dump:
LD_LIBRARY_PATH=. LD_PROFILE=libmy.so ./mymain
where libmy.so is the library I want to profile, and mymain is the executable which links to it.
This appears to create the profile dump successfully (which appears at /var/tmp/libmy.so.profile), but when I try to get a readable profile using sprof it fails:
$ sprof libmy.so /var/tmp/libmy.so.profile sprof: failed to load shared object `libmy.so'
I have a CentOS4 machine here, and doing the above on that works fine, but I've had no luck at all on CentOS5 (all currently up-to-date).
Can anyone help? (Please!)
Given that I can get this to work well on a CentOS4 machine, and I have tried lots of minor trivial changes to command-line, etc, but still fail on CentOS5, does anyone know what I can do or where I can go to progress this further?
My current guess is that it is a (probably very trivial) bug, although I recognise there still the possibility that this is simply a usage problem (however, if that is so, the usage since centos4 has clearly changed).
A more straightforward program I might have a go at debugging, but I don't feel competent on this one - sprof is part of the glibc package.
The glibc pages (http://www.gnu.org/software/libc/bugs.html) say that bugs should be reported to the distribution project first.
I would also be interested to know what the general policy is regarding what to do about bugs on Centos. I presume there is no way for people involved in centos to make changes directly, otherwise the distribution stops being a clone, so bugs/fixes on the centos bugzilla presumably get fed back to redhat at some point, and then eventually trickle down? (Is there a webpage somewhere explaining how this works? I know the FAQ states that there is no relationship with redhat, but surely they must exploit the bug reports somehow).
Anyway, should I report this on the CentOS bugzilla? Would someone take it up if I did? I assume that reporting it to redhat would be inappropriate. If not centos, should I go on to report it to glibc?
Hywel.
On Tue, Jul 29, 2008 at 10:49:14AM +0100, Hywel Richards wrote:
Given that I can get this to work well on a CentOS4 machine, and I have
... where did you generate your libmy.so? On a C3/4/5 box?
What gives (on c4 and c5): ldd libmy.so
You may miss some compat libs.
Tru
Tru Huynh wrote:
where did you generate your libmy.so? On a C3/4/5 box?
What gives (on c4 and c5): ldd libmy.so
You may miss some compat libs.
Tru
For the c4 test, I built it on c4, and for the c5 test I built it on c5.
Here are the outputs from ldd on the c4 and c5 boxes respectively:
[hywel@centos4box]$ ldd libmy.so libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00e45000) libm.so.6 => /lib/tls/libm.so.6 (0x00afd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a80000) libc.so.6 => /lib/tls/libc.so.6 (0x00267000) /lib/ld-linux.so.2 (0x00a48000)
[hywel@centos5box]$ ldd libmy.so linux-gate.so.1 => (0x009ce000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x004e7000) libm.so.6 => /lib/libm.so.6 (0x005fe000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00eae000) libc.so.6 => /lib/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x00908000)
The .so files work fine, it's only when I later run sprof to get the profile that I have any problem (on the c5 box).
Hywel Richards wrote:
Hywel Richards wrote:
No matter how I try, I can't seem to get a library profile from sprof on CentOS5.
Does anyone know if sprof actually works on CentOS5? I'd be very interested to hear if anyone is using it successfully.
At the moment I'm trying something like this to get the dump:
LD_LIBRARY_PATH=. LD_PROFILE=libmy.so ./mymain
where libmy.so is the library I want to profile, and mymain is the executable which links to it.
This appears to create the profile dump successfully (which appears at /var/tmp/libmy.so.profile), but when I try to get a readable profile using sprof it fails:
$ sprof libmy.so /var/tmp/libmy.so.profile sprof: failed to load shared object `libmy.so'
I have a CentOS4 machine here, and doing the above on that works fine, but I've had no luck at all on CentOS5 (all currently up-to-date).
Can anyone help? (Please!)
Given that I can get this to work well on a CentOS4 machine, and I have tried lots of minor trivial changes to command-line, etc, but still fail on CentOS5, does anyone know what I can do or where I can go to progress this further?
My current guess is that it is a (probably very trivial) bug, although I recognise there still the possibility that this is simply a usage problem (however, if that is so, the usage since centos4 has clearly changed).
A more straightforward program I might have a go at debugging, but I don't feel competent on this one - sprof is part of the glibc package.
The glibc pages (http://www.gnu.org/software/libc/bugs.html) say that bugs should be reported to the distribution project first.
I would also be interested to know what the general policy is regarding what to do about bugs on Centos. I presume there is no way for people involved in centos to make changes directly, otherwise the distribution stops being a clone, so bugs/fixes on the centos bugzilla presumably get fed back to redhat at some point, and then eventually trickle down? (Is there a webpage somewhere explaining how this works? I know the FAQ states that there is no relationship with redhat, but surely they must exploit the bug reports somehow).
Anyway, should I report this on the CentOS bugzilla? Would someone take it up if I did? I assume that reporting it to redhat would be inappropriate. If not centos, should I go on to report it to glibc?
Johnny Hughes wrote:
This looks like it might well be the same problem.
I guess the fact that this is in an OpenSUSE list suggests that it is a problem originating in glibc.
It's a little bit discouraging that the bug was entered so long ago and is still open.
On Tue, Jul 29, 2008 at 04:29:19PM +0100, Hywel Richards wrote:
Johnny Hughes wrote:
This looks like it might well be the same problem.
yes http://lists.opensuse.org/opensuse-factory/2007-09/msg00477.html https://bugzilla.novell.com/show_bug.cgi?id=327040#c3
Could you please fill a bug at http://bugs.centos.org and to upstream http://bugzilla.redhat.com with these 2 links.
It's a little bit discouraging that the bug was entered so long ago and is still open.
There is no match when I search "sprof" on http://bugzilla.redhat.com How would they fix it if it's not reported there ;)
Tru
Tru Huynh wrote:
On Tue, Jul 29, 2008 at 04:29:19PM +0100, Hywel Richards wrote:
Johnny Hughes wrote:
This looks like it might well be the same problem.
yes http://lists.opensuse.org/opensuse-factory/2007-09/msg00477.html https://bugzilla.novell.com/show_bug.cgi?id=327040#c3
Could you please fill a bug at http://bugs.centos.org and to upstream http://bugzilla.redhat.com with these 2 links.
OK, I have logged the problem at bugs.centos.org (http://bugs.centos.org/view.php?id=3021), but is it in order to enter it in the redhat bugzilla when I don't have RHEL to check it against?
I know it will be the same, but what is their/centos's policy on this? This was the reason for my asking generally about bug reporting policy in centos - is there a webpage somewhere describing what the process is supposed to be here? I was expecting that the bug would first reach confirmed status before it got forwarded upstream, or something like that.
Hywel.
-
Filipe Brandenburger -
Hywel Richards -
Johnny Hughes -
Tru Huynh