bug-hurd
[Top][All Lists]
Advanced

[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

Attachment: patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]