[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd port for gcc go PATCH 1-4(23)
From: |
Samuel Thibault |
Subject: |
Re: Hurd port for gcc go PATCH 1-4(23) |
Date: |
Mon, 19 Dec 2016 00:25:35 +0100 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
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
patch
Description: Text document
- Re: Hurd port for gcc go PATCH 1-4(23),
Samuel Thibault <=