Re: Hurd port for gcc go PATCH 1-4(23)
Hello,
Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote:
> Another more annoying gnumch/hurd/glibc bug is that the
> built program go (go-6 in Debian) gets killed when executed from the
> shell vi path, but not when issued directly: /usr/bin/go-6 works fine.
> go-6
> Segmentation fault (core dumped)
I've had a quick look by adding printfs in go-main.c and further to see
up to where it goes before crashing. It crashes in
src/libgo/runtime/go-caller.c
in function __go_get_backtrace_state, inside the stat() call in:
if (__builtin_strchr (filename, '/') == NULL)
filename = NULL;
if (stat (filename, &s) < 0 || s.st_size < 1024)
filename = NULL;
filename of course doesn't start with '/' (it's argv[0]), and thus NULL
is passed to stat(). It happens that by luck on Linux this just returns
an EFAULT error, but that's sheer luck :) This should probably be turned
into e.g.:
if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
filename = NULL;
as the attached patch does, which should really be applied or done
any other way.
Then calling go-6 brings this:
fatal error: libbacktrace could not find executable to open
That's inside src/libbacktrace/fileline.c, the fileline_initialize
function, which tries the above filename (and thus fails), then
getexecname() (which is not implemented), then /proc/self/exe, which is
not implemented, then /proc/curproc/file which is even less implemented.
So here it'd be "just" a matter of implementing /proc/self/exe.
Samuel
Index: runtime/go-caller.c
===================================================================
--- runtime/go-caller.c (révision 235086)
+++ runtime/go-caller.c (copie de travail)
@@ -93,7 +93,7 @@
argv[0] (http://gcc.gnu.org/PR61895). It would be nice to
have a better check for whether this file is the real
executable. */
- if (stat (filename, &s) < 0 || s.st_size < 1024)
+ if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
filename = NULL;
back_state = backtrace_create_state (filename, 1, error_callback, NULL);
Reply to: