sprof fails to generate flat profiling for my shared library: Inconsistency detected by ld.so

Asked by Zheyuan on 2017-08-08

I am unable to generate flat profiling result using `sprof` in Ubuntu 16.04.01 (as well as 14.04.01). Here is a reproducible example, adapted from `man sprof`. I have `glibc` version 2.23-0ubuntu9.

First create a directory for experiment, then create `prog.c` and `libdemo.c` files inside:

    // prog.c
           #include <stdlib.h>

           void x1(void);
           void x2(void);

           int
           main(int argc, char *argv[])
           {
               x1();
               x2();
               exit(EXIT_SUCCESS);
           }

    // libdemo.c
           #include <unistd.h>

           void
           consumeCpu1(int lim)
           {
               int j;

               for (j = 0; j < lim; j++)
                getppid();
           }

           void
           x1(void) {
               int j;

               for (j = 0; j < 100; j++)
                consumeCpu1(200000);
           }

           void
           consumeCpu2(int lim)
           {
               int j;

               for (j = 0; j < lim; j++)
                getppid();
           }

           void
           x2(void)
           {
               int j;

               for (j = 0; j < 1000; j++)
                consumeCpu2(10000);
           }

Now open a terminal, and change directory to the above created one, then run the following shell script:

    cc -g -fPIC -shared -o libdemo.so libdemo.c
    cc -g -o prog prog.c -L. -ldemo

    export LD_PROFILE=libdemo.so
    export LD_PROFILE_OUTPUT=$(pwd) ## use current directory
    rm -f libdemo.so.profile
    LD_LIBRARY_PATH=. ./prog
    sprof -p libdemo.so libdemo.so.profile

I get an error:

> Inconsistency detected by ld.so: dl-open.c: 717: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

**`libdemo.so.profile` has been generated without problem, but `sprof` fails to process it.**

I found this Stack Overflow thread https://stackoverflow.com/questions/6216979/what-is-causing-sprof-to-complain-about-inconsistency-detected-by-ld-so?noredirect=1, but it does not offer a solution. **I want to get `sprof` to work!**

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu glibc Edit question
Assignee:
No assignee Edit question
Last query:
2017-08-09
Last reply:
2017-08-09

I suggest you post on a sprof forum too. It's closer to your issue. If you get a solution then please post it here too. It may help others

Zheyuan (zl1872) said : #2

Hi, I am sorry I don't know any sprof forum, and I can't find one either via Google. Would you give me some direction?

I considered reporting the issue here, because when I do

    sprof --help

I see that bug report should be made to https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs?field.status:list=NEW

I also found sprof source code at https://code.woboq.org/userspace/glibc/elf/sprof.c.html, but I don't have the capability to dig into it.

Of course, without using sprof, I could use oprof to get a flat profiling

    ## sudo apt-get update
    ## sudo apt-get install oprofile
    LD_LIBRARY_PATH=. oprof ./prog
    opreport
    opreport -l libdemo.so

But I still want to know how to get sprof working.

Manfred Hampl (m-hampl) said : #3

Looks similar to Bug #462760

http://sourceware.org/ml/libc-alpha/2008-08/msg00016.html has a bug that is meant to eventually help, with the comment "but I did not continue with the patching"

Zheyuan (zl1872) said : #4

I am afraid I am struggling to find it informative. Is this bug fixed? How is it fixed? What should I do?

Manfred Hampl (m-hampl) said : #5

Sorry if my comment was not clear; I confess that there is a typo error in it.

It seems to me that this is a known bug, that has not been corrected for years.

The sourceware.org link has a __patch__ that maybe helps to correct the problem. This would have to be incorporated into the source of sprof, but obviously nobody ever did this.

I do not think that there is much what you can do besides building your own version of the GNU C libraries.

Can you help with this problem?

Provide an answer of your own, or ask Zheyuan for more information if necessary.

To post a message you must log in.