#239 operf can't profile a process that changed its name.

[Ghacker]

I make a sample and patch for this.
Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information

[Maynard Johnson]

Thanks for your bug report. Please add a full description of the problem here in this bug report, and attach your patch here (following patch contribution guidelines documented at http://oprofile.sourceforge.net/contribute/\). Thanks!

[Anonymous]

Here's my description.

A process that changed it's name via "prctl" system call can't be profiled with oprofile at all.

Sample code)
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/prctl.h>

int main(int argc, char *argv[])
{
char name[BUFSIZ]={0,};
unsigned long i=0;
if(argc>1) prctl(PR_SET_NAME, (unsigned long)argv[1], 0, 0);
prctl(PR_GET_NAME, name, 0, 0);
while(1){
printf("My name is %s and pid %d. I'm busy....[%ld]\n" , name, getpid(), ++i);
sleep(1);
}
return 0;
}

If above program is executed with a parameter other than its executable name, it can't be profiled with Oprofile.

[Ghacker]

A patch to fix the bug

[Maynard Johnson]

Thanks for the testcase to reproduce the problem, and for the patch to fix it. The fix, though, isn't quite complete. If the target program that does prctl() ends before operf gets around to processing its samples and other data we get from the kernel, then the readlink will fail, so we need to be able to handle that.

Coincidentally, I've been working on an operf bug that involves the same area of code that your patch changes (i.e., obtaining an appropriate appname for a process). The bug was reported by a user running specjbb with Java 7, which has lots of threads created via fork/exec by the main JVM process. While coding the fix for this, I employed your readlink technique as a first attempt for trying to obtain the appname since it's faster than using the PERF_RECORD_COMM and PERF_RECORD_MMAP data from the kernel. But my code also handles the case where readlink fails due to the process having ended, and it falls back to the technique of comparing the 'comm' data (app shortname) with the filename segment of mmap'ed pathnames. I also made a change so that if a program does a prctl() to change the name to "foo" and then the program ends before operf can do a readlink for it, we will default to attributing the samples to "foo". So samples won't get dropped, no matter what.

The specjbb user who reported the aforementioned problem is testing my patch now. If all goes well, I'll be posting it to the list soon. So, just to be clear, that patch will fix also the problem you reported here, so I'll come back and ask you to test it. Thanks.

[Ghacker]

I totally understand the case that is not considered.
And I'm glad to hear you already have a patch for it.
I hope it works fine with the specjbb and mine.

Please let me know whenever your patch is ready to be tested.
Thanks for your effort.

[Maynard Johnson]

I apologize for neglecting to get back to you. The patch I mentioned above that I was working on turned out to be very complex and took longer than I thought to get it right. But it was finally pushed upstream on Apr 25. I hope you'll find that your problem is fixed in the current git repo.

[Ghacker]

Your patch works perfectly in my environment.
I also sorry for my neglecting and do thank your great effort and you don't forget this. :)

[Maynard Johnson]

This fix was actually included in the latest 0.9.9 release, so I will close this bug.