Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 13 months ago

Closed 3 days 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:
Component: helenos/app/taskdump Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description

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 (8)

comment:1 Changed 13 months ago by Jiri Svoboda

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 Changed 13 months ago by Jiří Zárevúcky

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 Changed 13 months ago by Jiri Svoboda

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 Changed 13 months ago by Jiří Zárevúcky

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 13 months ago by Jiří Zárevúcky (previous) (diff)

comment:5 Changed 13 months ago by Jiri Svoboda

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 Changed 13 months ago by Jiří Zárevúcky

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 13 months ago by Jiří Zárevúcky (previous) (diff)

comment:7 Changed 11 months ago by Jakub Jermář

Milestone: 0.7.1

comment:8 Changed 3 days ago by Jakub Jermář

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.