From: SourceForge.net <no...@so...> - 2013-04-05 01:30:14
|
Bugs item #3610048, was opened at 2013-04-04 18:30 Message generated for change (Tracker Item Submitted) made by gh4ck3r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ghacker (gh4ck3r) Assigned to: Nobody/Anonymous (nobody) Summary: operf can't profile a process that changed its name. Initial Comment: I make a sample and patch for this. Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 |
From: SourceForge.net <no...@so...> - 2013-04-05 15:20:27
|
Bugs item #3610048, was opened at 2013-04-04 18:30 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ghacker (gh4ck3r) Assigned to: Nobody/Anonymous (nobody) Summary: operf can't profile a process that changed its name. Initial Comment: I make a sample and patch for this. Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information ---------------------------------------------------------------------- >Comment By: Maynard Johnson (maynardj) Date: 2013-04-05 08:20 Message: 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! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 |
From: SourceForge.net <no...@so...> - 2013-04-08 02:33:03
|
Bugs item #3610048, was opened at 2013-04-04 18:30 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ghacker (gh4ck3r) Assigned to: Nobody/Anonymous (nobody) Summary: operf can't profile a process that changed its name. Initial Comment: I make a sample and patch for this. Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2013-04-07 19:33 Message: 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. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2013-04-05 08:20 Message: 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! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 |
From: SourceForge.net <no...@so...> - 2013-04-09 21:06:51
|
Bugs item #3610048, was opened at 2013-04-04 18:30 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ghacker (gh4ck3r) >Assigned to: Maynard Johnson (maynardj) Summary: operf can't profile a process that changed its name. Initial Comment: I make a sample and patch for this. Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information ---------------------------------------------------------------------- >Comment By: Maynard Johnson (maynardj) Date: 2013-04-09 14:06 Message: 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. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2013-04-07 19:33 Message: 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. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2013-04-05 08:20 Message: 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! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 |
From: SourceForge.net <no...@so...> - 2013-04-09 22:28:48
|
Bugs item #3610048, was opened at 2013-04-04 18:30 Message generated for change (Comment added) made by gh4ck3r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ghacker (gh4ck3r) Assigned to: Maynard Johnson (maynardj) Summary: operf can't profile a process that changed its name. Initial Comment: I make a sample and patch for this. Please refer to https://github.com/ChangbinPark/Oprofile/issues/1 for more detailed information ---------------------------------------------------------------------- >Comment By: Ghacker (gh4ck3r) Date: 2013-04-09 15:28 Message: 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. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2013-04-09 14:06 Message: 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. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2013-04-07 19:33 Message: 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. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2013-04-05 08:20 Message: 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! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3610048&group_id=16191 |