Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

binaries crash after moving to $GOROOT_FINAL #1280

Closed
gopherbot opened this issue Nov 16, 2010 · 13 comments
Closed

binaries crash after moving to $GOROOT_FINAL #1280

gopherbot opened this issue Nov 16, 2010 · 13 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link

by armando.dicianno:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. amd64, linux on a basic Gentoo install (nothing fancy or weird), gcc-4.4.4, multilib
2. hg clone go
3. cd go/src ; ./all.bash

What is the expected output?
Whatever success is!

What do you see instead?
--- cd cmd/ebnflint
ebnflint -start="SourceFile"
"/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
make: *** [test] Segmentation fault


Which compiler are you using (5g, 6g, 8g, gccgo)?
This is during install, so whatever that is internally (6g?); I tried with no GOARCH or
GOOS and then GOARCH=amd64 and GOOS=linux.

Which operating system are you using?
Gentoo Linux. I have a very basic amd64 install. gcc-4.4.4 (gentoo -r2)

Which revision are you using?  (hg identify)
a7800e20064a tip



Please provide any additional information below.

I spent some time writing an ebuild for wider use. In my tests for seeing what files
were needed (GOROOT v. GOROOT_FINAL), I noticed that godoc also segfaults -- this will
end up being a different bug, I'm sure. ;-) However, it may be related.

-----------

Feel free to let me know about further system or debugging information you need. While
I'm very new to Go, I generally know how to invoke and use various development tools --
I just don't know what I'm looking for in this case.
@griesemer
Copy link
Contributor

Comment 1:

I cannot reproduce this.
ebnflint should simply run w/o any output if it is successful. It does some basic
consistency checks of the EBNF grammar in the language spec.
Can you please try a fresh build from the tip of the tree and try again? If you get a
crash with ebnflint, it would be useful to have a bit more information (e.g. stack dump).

Owner changed to g...@golang.org.

Status changed to WaitingForReply.

@gopherbot
Copy link
Author

Comment 2 by armando.dicianno:

I have gdb 7.0.1, so debugging Go from gdb should work, from what I understand?
1) Build, and test crashes
--------
If I run ./all.bash to build and test, the terminal actually exits when this error
happens, so I run each step manually:
$ . ./make.bash
$ . ./env.bash
$ ./run.bash --no-rebuild
...
...
...
--- cd cmd/ebnflint
ebnflint -start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
make: *** [test] Segmentation fault
2) If I run the command manually, it crashes
--------
$ cd cmd/ebnflint
$ ebnflint -start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
Segmentation fault
$ ebnflint -start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
Segmentation fault
$ ebnflint -start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
Segmentation fault
3) If I run it through gdb, it works
--------
$ cd cmd/ebnflint
 $ gdb ebnflint 
GNU gdb (Gentoo 7.0.1 p1) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>;...
Reading symbols from /home/fafhrd/Projects/go/repos/go/src/cmd/ebnflint/ebnflint...
warning: Loadable segment ".interp" outside of ELF segments
Dwarf Error: Could not find abbrev number 110 [in module
/home/fafhrd/Projects/go/repos/go/src/cmd/ebnflint/ebnflint]
(gdb) run -start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
Starting program: /home/fafhrd/Projects/go/repos/go/src/cmd/ebnflint/ebnflint
-start="SourceFile" "/home/fafhrd/Projects/go/repos/go"/doc/go_spec.html
Program exited normally.
--------
So, this smells like a "safe malloc" type issue, where memory under gdb must be getting
initialized before use, possibly?
Please let me know any other techniques for debugging.

@gopherbot
Copy link
Author

Comment 3 by armando.dicianno:

Okay, I'm almost certain this is related to a conflation of environment variables, at
build time, for the purpose of packaging.
The make system really needs some attention so that it doesn't fight packaging. I'm
trying to make a .deb and an .ebuild, and in both cases, I have not been able to find
the right combination of GOROOT, GOROOT_FINAL, GOBIN at compile time that doesn't either
cause segfault's of some apps (ebnflitn, dodoc, and a handful of others.
*** It is only the binaries buily using GOROOT_FINAL that are segfaulting for me. ***
Personally, I'm happy using a Go install in it's src dir for my own projects.
However, I'd really appreciate a clear example of:
1) Which variables to set for a "moved install" (i.e. use of GOROOT_FINAL)
2) Which directories in the repo are needed for apps to work -- gotry required Make.inc,
for e.g.
If a "moved install" -- really, what GNU autotools considers DESTDIR -- works for you,
I'd love to see the steps you followed to produce a working set of tools.

@griesemer
Copy link
Contributor

Comment 4:

Thanks for looking into this. Changing status.

Status changed to HelpWanted.

@rsc
Copy link
Contributor

rsc commented Jan 20, 2011

Comment 5:

It should work just fine, starting with a clear environment, to do
cd ..../go/src
GOROOT_FINAL=/wherever ./make.bash  # or all.bash to run tests
./clean.bash --nopkg
cp -R ../* /wherever
It is expected that you copy all of $GOROOT to $GOROOT_FINAL.
It may work to copy less, but we have not defined or committed to
that continuing to work.
I just ran your example and cannot reproduce the problem.
$ cd /tmp
$ hg clone https://go.googlecode.com/hg go1
requesting all changes
adding changesets
adding manifests
adding file changes
added 7199 changesets with 28151 changes to 4027 files
updating to branch default
2450 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd go1/src
$ GOROOT_FINAL=/tmp/go2 ./make.bash
...
The binaries expect /tmp/go1 to be copied or moved to /tmp/go2.
$ mkdir /tmp/go2
$ cp -R ../* /tmp/go2
$ cd /tmp
$ rm -rf go1
$ go2/bin/ebnflint -start="SourceFile" go2/doc/go_spec.html
$ echo $?
0
$ 
If you can still reproduce the problem in the most recent release
please upload a broken ebnflint binary for us to look at.
Thanks.

Owner changed to r...@golang.org.

Status changed to WaitingForReply.

@gopherbot
Copy link
Author

Comment 6 by renich@woralelandia.com:

guys, we're having similar problems:
https://bugzilla.redhat.com/show_bug.cgi?id=652987

@rsc
Copy link
Contributor

rsc commented Jan 25, 2011

Comment 7:

Why do you say that's similar?
I don't see the similarity.
Russ

@gopherbot
Copy link
Author

Comment 8 by renich@woralelandia.com:

warning: Loadable segment ".interp" outside of ELF segments
I'm no expert but this line happens to me all the time while trying to build it in
Fedora.
I think it is related not in ebnflint crashing but it's debug-info related problems.
Debug info is not being generated correctly and, that, might be causing armando's
problems and ours...
The packages build fine while disabling debug-info. Please, if possible, try this spec
file.

Attachments:

  1. go.spec (3435 bytes)

@rsc
Copy link
Contributor

rsc commented Feb 2, 2011

Comment 9:

How are you moving the binaries to $GOROOT_FINAL?
Are you running strip on them during the move?
If so, perhaps this is a duplicate of issue #1242?

@gopherbot
Copy link
Author

Comment 10 by renich@woralelandia.com:

well, this issue has been overcome by not stripping exactly:
http://renich.fedorapeople.org/SPECS/go.spec (first 5 lines)
I will appreciate any comments and or directions on this.

@adg
Copy link
Contributor

adg commented Feb 2, 2011

Comment 11:

Don't strip Go files. Or am I missing something?

@gopherbot
Copy link
Author

Comment 12 by renich@woralelandia.com:

nah, that's it for the moment ;)
Thanks for the issue link on this. I'll subscribe to know what happens to it.
Anyway, please, invest some time on that if possible. ;)

@rsc
Copy link
Contributor

rsc commented Feb 2, 2011

Comment 13:

We do intend to make the binaries work with strip.
They did once.
Marking this as a duplicate of 1242.

Status changed to Duplicate.

Merged into issue #1242.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rsc @adg @griesemer @gopherbot