Hi Teng and Y,

Yes, you're right.

Previously my script (test_profile.sh) is to run both the binary (./spin)
and profile.py in the background and to kill profile.py immediately the
binary exits. Profile.py does not resolve the symbols until it receives the
kill signal. However, when it receives the signal, the binary has already
exited and /proc/$PID/maps does not exist anymore.

I tried two fixes and they both work:
1) Copy /proc/$PID/maps to /tmp/proc$PID, then hack bcc_proc.c to search
for the /tmp/proc$PID of the map if /proc/$PID/maps does not exists.
2) Estimate the run time of the binary and kill profile.py before the
binary exits.

Thank you!
-Fenggang

On Wed, Aug 16, 2017 at 5:22 PM Teng Qin <[email protected]> wrote:

> Also the binary need to be still running when doing symbolization.
>
>
> On Wed, Aug 16, 2017 at 3:14 PM, Y Song via iovisor-dev <
> [email protected]> wrote:
>
>> >
>> > // always fails, with errno = 2
>> > procmap = fopen(procmap_filename, "r");
>> >
>>
>> errno 2 (ENOENT) means file does not exist. You can add additional
>> print to check whether the file truly exists or not.
>>
>> On Sat, Aug 12, 2017 at 5:14 AM, Fenggang Wu via iovisor-dev
>> <[email protected]> wrote:
>> > Hi there,
>> >
>> > I am trying out bcc tools from http://github.com/iovisor/bcc, more
>> > specificaly profile.py and offcputime.py. However in the tracing result,
>> > user functions are shown as "[unknown]", whereas kernel functions such
>> as
>> > "sys_*" are interpreted well. Any ideas?
>> >
>> > Thank you very much!
>> > Fenggang
>> >
>> > ======
>> >
>> > Here are more details (I use profile.py as the example). If there are
>> more
>> > details that are necessary please feel free to let me know.
>> >
>> > 1) how to reproduce the issue:
>> > #~> cat Makefile
>> > all:
>> > g++ -o spin spin.cc
>> > objcopy --only-keep-debug spin spin.debug
>> > objcopy --add-gnu-debuglink=spin.debug spin
>> >
>> >
>> > clean:
>> > rm spin spin.debug
>> > #~> cat spin.cc
>> > #include<iostream>
>> > using namespace std;
>> > void myfunc() {
>> >   int i, j, cnt;
>> >   cout << "my func" << endl;
>> >   for (i = 0; i < 4; i++) {
>> >     for ( j = 0; j < 500000000; j++) {
>> >       cnt ^= i + j;
>> >     }
>> >     cout << i << " " << cnt;
>> >   }
>> > }
>> >
>> > int main() {
>> >   cout << "hello" << endl;
>> >   myfunc();
>> > }
>> > #~> cat test_profile.sh
>> > #!/bin/bash
>> > sudo make
>> >
>> > sudo -- bash -c  "./spin & PID=\$!; echo PID=\$PID; cat
>> /proc/\$PID/maps;
>> > (trap - SIGINT; profile -U -p \$PID > spin.profile)& wait \$PID;"; sudo
>> kill
>> > -SIGINT `pgrep -x profile`; sleep 1; cat spin.profile;
>> > sleep 1
>> > sudo make clean
>> >
>> > #~>./test_profile.sh
>> >
>> > Here, in my server,  spin.profile cannot resolve user-level symbols
>> (i.e.
>> > symbols in spin.cc). It only shows userland symbol names as "[unknown]".
>> >
>> > I am using Ubuntu 16.04.3 LTS with Linux Kernel ver. 4.10.0-28-generic.
>> I've
>> > tried both installing by apt-get or building from source (latest pull
>> from
>> > github). the results are the same: user-land functions names cannot be
>> > resolved.
>> >
>> > 2) What I've tried/found:
>> >
>> > - perf_event works well under my environment in resolving both the
>> kernel
>> > and userspace symbols.
>> > - bcc/test/python/test_debuginfo.py pass all tests. Showing that
>> build-id
>> > and debug-link both methods work in bcc.
>> > - [MAJOR PROBLEM] I found the failed statement:
>> > src/cc/bcc_proc.c:78:
>> > int bcc_procutils_each_module(int pid, bcc_procutils_modulecb callback,
>> void
>> > *payload) {
>> >
>> > ...
>> > // always fails, with errno = 2
>> > procmap = fopen(procmap_filename, "r");
>> > ...
>> >
>> > }
>> >
>> > - Afterwards, I've written a similar little c++ program to read
>> > "/proc/pid/maps", and it can open/read the proc map file successfully.
>> > Besides, I can also cat the proc map file in the shell, the file can be
>> read
>> > successfully too.
>> >
>> > the little testing c++ program to open and read the procmap file is as
>> > follows (very similar to bcc_procutils_each_module):
>> >
>> > #~> cat read-proc-map.cc
>> > #include <iostream>
>> > #include <cstring>
>> > #include <stdio.h>
>> > #include <errno.h>
>> >
>> > int main(int argc, char*argv[]) {
>> >   char procmap_filename[128];
>> >   FILE *procmap;
>> >   int ret;
>> >
>> >   printf("%d\n", argc);
>> >
>> >   if (argc != 2) return -1;
>> >
>> >   printf("mytest\n");
>> >
>> >   snprintf(procmap_filename, sizeof(procmap_filename),
>> >   "/proc/%s/maps", argv[1]);
>> >   procmap = fopen(procmap_filename, "r");
>> >
>> >   printf("mytest: fopen <%s>\n", procmap_filename);
>> >
>> >   if (!procmap) {
>> >     printf("mytest:   ... failed errno=%d\n", errno);
>> >     return -1;
>> >   }
>> >
>> >   printf("mytest:   ... success <%s>\n", procmap_filename);
>> >
>> >
>> >   do {
>> >     char endline[4096];
>> >     char perm[8], dev[8];
>> >     long long begin, end, size, inode;
>> >
>> >     ret = fscanf(procmap, "%llx-%llx %s %llx %s %lld", &begin, &end,
>> perm,
>> > &size, dev, &inode);
>> >
>> >     if (!fgets(endline, sizeof(endline), procmap))
>> >       break;
>> >
>> >     if (ret == 6) {
>> >       char *mapname = endline;
>> >       char *newline = strchr(endline, '\n');
>> >
>> >       if (newline)
>> > newline[0] = '\0';
>> >
>> >       while (isspace(mapname[0])) mapname++;
>> >
>> >       printf("%s, %llx, %llx\n", mapname, begin, end);
>> >     }
>> >   } while (ret && ret != EOF);
>> >
>> >   fclose(procmap);
>> >   printf("mytest: fclosed %s\n", procmap_filename);
>> >   return 0;
>> > }
>> >
>> > ====
>> >
>> > _______________________________________________
>> > iovisor-dev mailing list
>> > [email protected]
>> > https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>> >
>> _______________________________________________
>> iovisor-dev mailing list
>> [email protected]
>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>>
>
>
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Reply via email to