Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#689 closed defect (fixed)

Taskdump cannot load symbols for binaries not in /app or /srv

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone: 0.8.0
Component: helenos/app/taskdump Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:


If a binary that is not in /app or /srv faults and is dumped (e.g. test binary, driver, etc.), taskdump will fail to locate the binary and thus fail to load the symbols.

This is because taskdump will look at the task name and prepend /app/ and /srv/ and tries to open those paths. If the binary is located elsewhere, this will fail.

Change History (9)

comment:1 by Jiri Svoboda, 6 years ago

It would be nice to have a way to determine the full path of the binary corresponding to a task.

It would be useful not only for taskdump/debugging. MGI expects to find data files in paths relative to the binary. On other OSes it needs to emulate the OS binary search strategy (e.g. current dir, PATH, etc.). If we could just ask the OS, it would make it so much easier.

comment:2 by Jiří Zárevúcky, 6 years ago

So, something akin to Linux's /proc/pid/exe. There are some considerations involved. Notably, both taskdump and the program itself need access to the binary file, but it should be possible for the file to have different paths in each process.

comment:3 by Jiri Svoboda, 6 years ago

Yes, although /proc/pid/exe gives just the contents of the binary (I guess that would be fine for taskdump). For locating data files you need the path. The two cases (debugger and getting your own path for finding data files) are probably distinct and require a different API.

I cannot comment on different processes seeing different paths to the same file because we don't have that so it's not clear to me how that would work.

comment:4 by Jiří Zárevúcky, 6 years ago

I guess the most common example would be chroot and related sandboxing mechanisms. But IMO, lookup of data files is a fundamentally platfrom-dependent task, and making data explicitly relative to binary path is a very weird (inflexible, nonportable) way to go about it.

Last edited 6 years ago by Jiří Zárevúcky (previous) (diff)

comment:5 by Jiri Svoboda, 6 years ago

No, it isn't. If your binary application is distributed by means of a simple zip file or tarball which contains the binary and data files, extracting the archive will always place your data files on the same path relative to the binary (e.g. in the same directory). Finding the files in path relative to the binary directory is better than finding them relative to CWD, because it works even if CWD != directory where we unpacked the archive.

If you wanted to have a Linux package that installs binaries in /usr/bin and data files in /usr/share, that's a completely different story and something that is decided at compile time, not at run time.

comment:6 by Jiří Zárevúcky, 6 years ago

I see your point. I didn't consider applications distributed like that (too accustomed to package managers I guess).

By the way, on Linux, /proc/pid/exe (or /proc/self/exe) acts like a symlink, so it solves both use cases through readlink().

Last edited 6 years ago by Jiří Zárevúcky (previous) (diff)

comment:7 by Jakub Jermář, 6 years ago

Milestone: 0.7.1

comment:8 by Jakub Jermář, 5 years ago

Resolution: fixed
Status: newclosed

comment:9 by Jakub Jermář, 5 years ago

Milestone: 0.8.0
Note: See TracTickets for help on using tickets.