After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 172394 - display "/usr/libexec" as path even if the file is not in this directory
display "/usr/libexec" as path even if the file is not in this directory
Status: RESOLVED FIXED
Product: bug-buddy
Classification: Deprecated
Component: general
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: Bug-buddy Maintainers
Bug-buddy Maintainers
: 490586 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-04-01 20:28 UTC by Sebastien Bacher
Modified: 2008-10-02 14:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
don't hardcode process name (2.31 KB, patch)
2006-12-28 22:47 UTC, Sam Morris
none Details | Review

Description Sebastien Bacher 2005-04-01 20:28:38 UTC
* crash an app usually using /usr/libexec on a Debian system which doesn't use
/usr/libexec (ie: /usr/lib/netspeed/netspeed_applet2)
* look on the bug-buddy text: "Backtrace was generated from
'/usr/libexec/netspeed_applet2'"

It should display the real path: "/usr/lib/netspeed/netspeed_applet2" and not
"/usr/libexec/netspeed_applet2"
Comment 1 Sam Morris 2006-10-03 19:02:20 UTC
Why not use the target of the symlink /proc/$pid/exe instead of semi-hardcoding the path?
Comment 2 Fernando Herrera 2006-11-27 23:41:13 UTC
Good point. Do you want to cook a patch? :)
Comment 3 Sam Morris 2006-12-28 22:16:22 UTC
Hm, why do we need to know the path at all? 'gdp -p $pid' works fine for me.
Comment 4 Sam Morris 2006-12-28 22:47:43 UTC
Created attachment 79010 [details] [review]
don't hardcode process name

Anyway, here's a first stab at this.

The approach I took was to try each method of getting the process' executable file in turn until one succeeds. IMO grovelling through PATH if none of the methods work is not useful since we have already seen how it gives the wrong result--especially unwanted if the path is being fed to gdb (GDB gets run on /usr/bin/gnome-terminal when I ran /home/sam/src/g-t/gnome-terminal...)
Comment 5 Sam Morris 2008-05-27 11:20:46 UTC
Is this bug still relevant since the bug-buddy rewrite & associated interface changes? 
Comment 6 Cosimo Cecchi 2008-09-01 13:54:30 UTC
Yes, this is still relevant I guess. I'll have a look at this patch after branching for gnome-2-24.
Comment 7 Sam Morris 2008-09-03 09:13:54 UTC
Indeed, when my own applications crash, bug-buddy prints messages like this to the console:

/usr/lib/bug-buddy/nitromap: No such file or directory.
Comment 8 Cosimo Cecchi 2008-09-24 16:50:28 UTC
Marking the patch as "needs-work", as it isn't ready to be committed.
I want to work on this, but don't know how it works on Solaris, CC-ing Matt.
Comment 9 Matt Keenan (IRC:MattMan) 2008-09-25 13:24:22 UTC
For Solaris the addendum to the patch attached here would be :

+
+	/* Solaris - Similar to above just different location of symlink */
+	{
+		gchar *link = g_strdup_printf ("/proc/%d/path/a.out", pid);
+		g_assert (link);
+
+		GError *err = NULL;
+		gchar *exe = g_file_read_link (link, &err);
+		if (err == NULL) {
+			g_free (link);
+			return (exe);
+		}
+		g_message ("Could not read %s: %s\n", link, err->message);
+		g_clear_error (&err);
+	}

Comment 10 Cosimo Cecchi 2008-09-25 14:49:41 UTC
Thanks Matt and Sam, I committed a modified patch to trunk for this.
I didn't commit the BSD snippet, as I am not sure recent BSD builds support /proc. If someone is interested, please write a patch.
Also, I kept the old code so that unsupported platforms will still be able use that as a fallback and won't fail.

2008-09-25  Cosimo Cecchi  <cosimoc@gnome.org>

	* src/gdb-buddy.c: (get_process_executable), (gdb_get_trace):
	Take the real path of the process from /proc, on supported platforms
	(Linux and Solaris).
	Thanks to Sam Morris and Matt Keenan (#172394).
Comment 11 Cosimo Cecchi 2008-10-02 14:15:35 UTC
*** Bug 490586 has been marked as a duplicate of this bug. ***