FAQ
Hello,

I met this error when I was building from source from tip() on
CentOS release 5.6 (Final) 64bit

...
pkg/go/doc
pkg/go/build
cmd/go
./make.bash: line 129: 23517 Segmentation fault
"$GOTOOLDIR"/go_bootstrap clean -i std

And then I switched to e018b45f9a6e and I got this:
pkg/go/doc
pkg/go/build
cmd/go
goroutine 1 [semacquire]:
----- stack segment boundary -----

goroutine 2 [semacquire]:
----- stack segment boundary -----
created by runtime.main
/home/nemo/go/src/pkg/runtime/proc.c:225

Then I switched to release and it complied,

Should I file this to the issue panel?

Regards,
--
Jackie

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Feb 7, 2013 at 4:57 pm

    On Fri, Feb 8, 2013 at 12:47 AM, Jackie Li wrote:

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std
    can't reproduce this on CentOS 5.6 (2.6.18-238.19.1.el5).
    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225
    still can't reproduce on the same machine.
    Then I switched to release and it complied,

    Should I file this to the issue panel?
    note that CentOS/RHEL 5.x uses too old a kernel that Go doesn't support, so
    reporting
    issue might not help.

    please try to use gdb to run go_bootstrap and see what caused the SIGSEGV.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jackie Li at Feb 7, 2013 at 5:07 pm
    Thanks for your reply.

    $ gdb go_bootstrap
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000

    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab767 in ?? ()
    (gdb) backtrace
    ../../gdb/addrmap.c:368: internal-error: addrmap_find is not implemented
    yet for mutable addrmaps
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)


    Sorry I don't know how to carry on from there.

    Is this helpful?

    Thanks,
    Jackie

    On Thu, Feb 7, 2013 at 4:57 PM, minux wrote:

    On Fri, Feb 8, 2013 at 12:47 AM, Jackie Li wrote:

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std
    can't reproduce this on CentOS 5.6 (2.6.18-238.19.1.el5).
    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225
    still can't reproduce on the same machine.
    Then I switched to release and it complied,

    Should I file this to the issue panel?
    note that CentOS/RHEL 5.x uses too old a kernel that Go doesn't support,
    so reporting
    issue might not help.

    please try to use gdb to run go_bootstrap and see what caused the SIGSEGV.


    --
    Jackie

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Feb 7, 2013 at 5:44 pm

    On Fri, Feb 8, 2013 at 1:06 AM, Jackie Li wrote:

    Thanks for your reply.

    $ gdb go_bootstrap
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000
    from this output, it seems your kernel is providing a 8KiB vDSO to user
    space
    instead of the normal 4KiB one.
    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab767 in ?? ()
    this address indicate that failures in the vdso, what kernel are you using?
    as the only difference between vdso code in runtime is clock_gettime
    change, so could you
    please apply this simple one line patch to tip and see if it fixes your
    bootstrap problem?

    diff -r f3ab80f38f60 src/pkg/runtime/vdso_linux_amd64.c
    --- a/src/pkg/runtime/vdso_linux_amd64.c Thu Feb 07 06:41:35 2013
    -0800
    +++ b/src/pkg/runtime/vdso_linux_amd64.c Fri Feb 08 01:42:36 2013
    +0800
    @@ -163,7 +163,7 @@
    void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
    void* runtime·__vdso_clock_gettime_sym = (void*)0;

    -#define SYM_KEYS_COUNT 3
    +#define SYM_KEYS_COUNT 2
    static symbol_key sym_keys[] = {
    { (byte*)"__vdso_time", &runtime·__vdso_time_sym },
    { (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym },

    perhaps http://code.google.com/p/go/issues/detail?id=4402 is back again.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jackie Li at Feb 8, 2013 at 10:17 am
    Hi Minux,

    Thanks for you reply,

    I applied your patch:
    $ hg diff
    diff -r f3ab80f38f60 src/pkg/runtime/vdso_linux_amd64.c
    --- a/src/pkg/runtime/vdso_linux_amd64.c Thu Feb 07 06:41:35 2013
    -0800
    +++ b/src/pkg/runtime/vdso_linux_amd64.c Fri Feb 08 10:00:57 2013
    +0000
    @@ -163,7 +163,7 @@
    void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
    void* runtime·__vdso_clock_gettime_sym = (void*)0;

    -#define SYM_KEYS_COUNT 3
    +#define SYM_KEYS_COUNT 2
    static symbol_key sym_keys[] = {
    { (byte*)"__vdso_time", &runtime·__vdso_time_sym },
    { (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym },
    $ hg par
    changeset: 15638:f3ab80f38f60
    tag: tip

    but I still get this error:
    ./make.bash: line 129: 23499 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    it seems to be a different number? previously it was:
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And gdb info:
    $ gdb go_bootstrap
    Reading symbols from /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap...done.
    Dwarf Error: Could not find abbrev number 105 [in module
    /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap]
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000

    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab6eb in ?? ()
    (gdb) bt
    ../../gdb/addrmap.c:368: internal-error: addrmap_find is not implemented
    yet for mutable addrmaps
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.


    Thanks,
    Jackie

    On Thu, Feb 7, 2013 at 5:43 PM, minux wrote:

    On Fri, Feb 8, 2013 at 1:06 AM, Jackie Li wrote:

    Thanks for your reply.

    $ gdb go_bootstrap
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000
    from this output, it seems your kernel is providing a 8KiB vDSO to user
    space
    instead of the normal 4KiB one.
    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab767 in ?? ()
    this address indicate that failures in the vdso, what kernel are you using?
    as the only difference between vdso code in runtime is clock_gettime
    change, so could you
    please apply this simple one line patch to tip and see if it fixes your
    bootstrap problem?

    diff -r f3ab80f38f60 src/pkg/runtime/vdso_linux_amd64.c
    --- a/src/pkg/runtime/vdso_linux_amd64.c Thu Feb 07 06:41:35 2013
    -0800
    +++ b/src/pkg/runtime/vdso_linux_amd64.c Fri Feb 08 01:42:36 2013
    +0800
    @@ -163,7 +163,7 @@
    void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
    void* runtime·__vdso_clock_gettime_sym = (void*)0;

    -#define SYM_KEYS_COUNT 3
    +#define SYM_KEYS_COUNT 2
    static symbol_key sym_keys[] = {
    { (byte*)"__vdso_time", &runtime·__vdso_time_sym },
    { (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym },

    perhaps http://code.google.com/p/go/issues/detail?id=4402 is back again.


    --
    Jackie

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jackie Li at Feb 8, 2013 at 10:31 am
    Sorry forgot to paste my kernel version:
    $ uname -a
    Linux apps-01 2.6.18-238.el5 #1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64
    x86_64 x86_64 GNU/Linux

    Cheers,

    On Fri, Feb 8, 2013 at 10:17 AM, Jackie Li wrote:

    Hi Minux,

    Thanks for you reply,

    I applied your patch:
    $ hg diff
    diff -r f3ab80f38f60 src/pkg/runtime/vdso_linux_amd64.c
    --- a/src/pkg/runtime/vdso_linux_amd64.c Thu Feb 07 06:41:35 2013
    -0800
    +++ b/src/pkg/runtime/vdso_linux_amd64.c Fri Feb 08 10:00:57 2013
    +0000
    @@ -163,7 +163,7 @@
    void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
    void* runtime·__vdso_clock_gettime_sym = (void*)0;

    -#define SYM_KEYS_COUNT 3
    +#define SYM_KEYS_COUNT 2
    static symbol_key sym_keys[] = {
    { (byte*)"__vdso_time", &runtime·__vdso_time_sym },
    { (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym
    },
    $ hg par
    changeset: 15638:f3ab80f38f60
    tag: tip

    but I still get this error:
    ./make.bash: line 129: 23499 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    it seems to be a different number? previously it was:
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And gdb info:
    $ gdb go_bootstrap
    Reading symbols from
    /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap...done.
    Dwarf Error: Could not find abbrev number 105 [in module
    /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap]
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000

    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab6eb in ?? ()
    (gdb) bt
    ../../gdb/addrmap.c:368: internal-error: addrmap_find is not implemented
    yet for mutable addrmaps
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.


    Thanks,
    Jackie

    On Thu, Feb 7, 2013 at 5:43 PM, minux wrote:

    On Fri, Feb 8, 2013 at 1:06 AM, Jackie Li wrote:

    Thanks for your reply.

    $ gdb go_bootstrap
    (gdb) run
    Starting program: /home/nemo/go/pkg/tool/linux_amd64/go_bootstrap
    warning: no loadable sections found in added symbol-file system-supplied
    DSO at 0x2aaaaaaab000
    from this output, it seems your kernel is providing a 8KiB vDSO to user
    space
    instead of the normal 4KiB one.
    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaaaab767 in ?? ()
    this address indicate that failures in the vdso, what kernel are you
    using?
    as the only difference between vdso code in runtime is clock_gettime
    change, so could you
    please apply this simple one line patch to tip and see if it fixes your
    bootstrap problem?

    diff -r f3ab80f38f60 src/pkg/runtime/vdso_linux_amd64.c
    --- a/src/pkg/runtime/vdso_linux_amd64.c Thu Feb 07 06:41:35 2013
    -0800
    +++ b/src/pkg/runtime/vdso_linux_amd64.c Fri Feb 08 01:42:36 2013
    +0800
    @@ -163,7 +163,7 @@
    void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
    void* runtime·__vdso_clock_gettime_sym = (void*)0;

    -#define SYM_KEYS_COUNT 3
    +#define SYM_KEYS_COUNT 2
    static symbol_key sym_keys[] = {
    { (byte*)"__vdso_time", &runtime·__vdso_time_sym },
    { (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym
    },

    perhaps http://code.google.com/p/go/issues/detail?id=4402 is back again.


    --
    Jackie


    --
    Jackie

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alex at Mar 1, 2013 at 3:58 am
    Hi,

    This is my first post to this list and on google groups, so apologies in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Volker Dobler at Mar 1, 2013 at 6:37 am
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Mar 1, 2013 at 6:57 am
    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alski85 at Mar 1, 2013 at 3:34 pm
    Thank you for taking the time to respond and analyze what may be the
    problem.

    I do understand that it's been said that RHEL5 is not supported officially,
    and in fact the binary release packages do not work. That said, that the
    last release will compile and a current snapshot will not, I wanted to make
    it aware as I've seen no announcement/explanation in reasoning, meaning I'd
    initially want to consider it a bug, even if the platform is not being
    targeted. It feels like a rather large chunk of enterprise servers would
    now be excluded if released as is.

    My results seem identical to the original complainant - it seems
    go_bootstrap is the end problem -

    [ src]$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, linux/amd64.
    lib9
    libbio
    libmach
    misc/pprof
    cmd/addr2line
    cmd/cov
    cmd/nm
    cmd/objdump
    cmd/pack
    cmd/prof
    cmd/cc
    cmd/gc
    cmd/6l
    cmd/6a
    cmd/6c
    cmd/6g
    pkg/runtime
    pkg/errors
    pkg/sync/atomic
    pkg/sync
    pkg/io
    pkg/unicode
    pkg/unicode/utf8
    pkg/unicode/utf16
    pkg/bytes
    pkg/math
    pkg/strings
    pkg/strconv
    pkg/bufio
    pkg/sort
    pkg/container/heap
    pkg/encoding/base64
    pkg/syscall
    pkg/time
    pkg/os
    pkg/reflect
    pkg/fmt
    pkg/encoding/json
    pkg/flag
    pkg/path/filepath
    pkg/path
    pkg/io/ioutil
    pkg/log
    pkg/regexp/syntax
    pkg/regexp
    pkg/go/token
    pkg/go/scanner
    pkg/go/ast
    pkg/go/parser
    pkg/os/exec
    pkg/os/signal
    pkg/net/url
    pkg/text/template/parse
    pkg/text/template
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 132: 23512 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    [ src]$ ../pkg/tool/linux_amd64/go_bootstrap
    Segmentation fault

    Kernel is 2.6.18-238.el5xen #1 SMP Tue Jan 4 16:15:36 EST 2011 x86_64
    x86_64 x86_64 GNU/Linux

    Thanks,
    Alex
    On Friday, March 1, 2013 1:57:48 AM UTC-5, Dave Cheney wrote:

    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build
    attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    <dr.volke...@gmail.com <javascript:>> wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies
    in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of
    today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Mar 2, 2013 at 1:31 am
    Hmm, I'm trying to reproduce this issue in a RHEL5 VM now.
    On Sat, Mar 2, 2013 at 2:34 AM, wrote:
    Thank you for taking the time to respond and analyze what may be the
    problem.

    I do understand that it's been said that RHEL5 is not supported officially,
    and in fact the binary release packages do not work. That said, that the
    last release will compile and a current snapshot will not, I wanted to make
    it aware as I've seen no announcement/explanation in reasoning, meaning I'd
    initially want to consider it a bug, even if the platform is not being
    targeted. It feels like a rather large chunk of enterprise servers would
    now be excluded if released as is.

    My results seem identical to the original complainant - it seems
    go_bootstrap is the end problem -

    [ src]$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, linux/amd64.
    lib9
    libbio
    libmach
    misc/pprof
    cmd/addr2line
    cmd/cov
    cmd/nm
    cmd/objdump
    cmd/pack
    cmd/prof
    cmd/cc
    cmd/gc
    cmd/6l
    cmd/6a
    cmd/6c
    cmd/6g
    pkg/runtime
    pkg/errors
    pkg/sync/atomic
    pkg/sync
    pkg/io
    pkg/unicode
    pkg/unicode/utf8
    pkg/unicode/utf16
    pkg/bytes
    pkg/math
    pkg/strings
    pkg/strconv
    pkg/bufio
    pkg/sort
    pkg/container/heap
    pkg/encoding/base64
    pkg/syscall
    pkg/time
    pkg/os
    pkg/reflect
    pkg/fmt
    pkg/encoding/json
    pkg/flag
    pkg/path/filepath
    pkg/path
    pkg/io/ioutil
    pkg/log
    pkg/regexp/syntax
    pkg/regexp
    pkg/go/token
    pkg/go/scanner
    pkg/go/ast
    pkg/go/parser
    pkg/os/exec
    pkg/os/signal
    pkg/net/url
    pkg/text/template/parse
    pkg/text/template
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 132: 23512 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    [ src]$ ../pkg/tool/linux_amd64/go_bootstrap
    Segmentation fault

    Kernel is 2.6.18-238.el5xen #1 SMP Tue Jan 4 16:15:36 EST 2011 x86_64 x86_64
    x86_64 GNU/Linux

    Thanks,
    Alex

    On Friday, March 1, 2013 1:57:48 AM UTC-5, Dave Cheney wrote:

    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build
    attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies
    in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of
    today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to golang-nuts...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Mar 2, 2013 at 10:45 pm
    Hello,

    I was unable to construct a working RHEL5 test environment on ec2 yesterday, however another person with a RHEL5 machine confirmed that tip is working for them using RHEL5.4.

    I recommend that you raise an issue on the issue tracker, golang.org/issue, including the full build output that you previously posted, the hg id of the revision you tried, and as many details about the RHEL5 host that you have.

    Cheers

    Dave
    On 02/03/2013, at 2:34, alski85@gmail.com wrote:

    Thank you for taking the time to respond and analyze what may be the problem.

    I do understand that it's been said that RHEL5 is not supported officially, and in fact the binary release packages do not work. That said, that the last release will compile and a current snapshot will not, I wanted to make it aware as I've seen no announcement/explanation in reasoning, meaning I'd initially want to consider it a bug, even if the platform is not being targeted. It feels like a rather large chunk of enterprise servers would now be excluded if released as is.

    My results seem identical to the original complainant - it seems go_bootstrap is the end problem -

    [ src]$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, linux/amd64.
    lib9
    libbio
    libmach
    misc/pprof
    cmd/addr2line
    cmd/cov
    cmd/nm
    cmd/objdump
    cmd/pack
    cmd/prof
    cmd/cc
    cmd/gc
    cmd/6l
    cmd/6a
    cmd/6c
    cmd/6g
    pkg/runtime
    pkg/errors
    pkg/sync/atomic
    pkg/sync
    pkg/io
    pkg/unicode
    pkg/unicode/utf8
    pkg/unicode/utf16
    pkg/bytes
    pkg/math
    pkg/strings
    pkg/strconv
    pkg/bufio
    pkg/sort
    pkg/container/heap
    pkg/encoding/base64
    pkg/syscall
    pkg/time
    pkg/os
    pkg/reflect
    pkg/fmt
    pkg/encoding/json
    pkg/flag
    pkg/path/filepath
    pkg/path
    pkg/io/ioutil
    pkg/log
    pkg/regexp/syntax
    pkg/regexp
    pkg/go/token
    pkg/go/scanner
    pkg/go/ast
    pkg/go/parser
    pkg/os/exec
    pkg/os/signal
    pkg/net/url
    pkg/text/template/parse
    pkg/text/template
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 132: 23512 Segmentation fault "$GOTOOLDIR"/go_bootstrap clean -i std

    [ src]$ ../pkg/tool/linux_amd64/go_bootstrap
    Segmentation fault

    Kernel is 2.6.18-238.el5xen #1 SMP Tue Jan 4 16:15:36 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

    Thanks,
    Alex
    On Friday, March 1, 2013 1:57:48 AM UTC-5, Dave Cheney wrote:

    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of today's
    tip, attempting compilation on RHEL5. Compilation of the last release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Mar 3, 2013 at 3:31 pm
    Alternatively, if anyone could provide me a temporary shell account for an
    affected
    system, I'm willing to debug the problem (my only CentOS 5 machine is not
    affected
    and I'm not able to switch kernel on it).

    I just need strace and gdb to installed on the machine.
    On Sun, Mar 3, 2013 at 6:44 AM, Dave Cheney wrote:

    Hello,

    I was unable to construct a working RHEL5 test environment on ec2
    yesterday, however another person with a RHEL5 machine confirmed that tip
    is working for them using RHEL5.4.

    I recommend that you raise an issue on the issue tracker, golang.org/issue,
    including the full build output that you previously posted, the hg id of
    the revision you tried, and as many details about the RHEL5 host that you
    have.

    Cheers

    Dave

    On 02/03/2013, at 2:34, alski85@gmail.com wrote:

    Thank you for taking the time to respond and analyze what may be the
    problem.

    I do understand that it's been said that RHEL5 is not supported
    officially, and in fact the binary release packages do not work. That
    said, that the last release will compile and a current snapshot will not, I
    wanted to make it aware as I've seen no announcement/explanation in
    reasoning, meaning I'd initially want to consider it a bug, even if the
    platform is not being targeted. It feels like a rather large chunk of
    enterprise servers would now be excluded if released as is.

    My results seem identical to the original complainant - it seems
    go_bootstrap is the end problem -

    [ src]$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, linux/amd64.
    lib9
    libbio
    libmach
    misc/pprof
    cmd/addr2line
    cmd/cov
    cmd/nm
    cmd/objdump
    cmd/pack
    cmd/prof
    cmd/cc
    cmd/gc
    cmd/6l
    cmd/6a
    cmd/6c
    cmd/6g
    pkg/runtime
    pkg/errors
    pkg/sync/atomic
    pkg/sync
    pkg/io
    pkg/unicode
    pkg/unicode/utf8
    pkg/unicode/utf16
    pkg/bytes
    pkg/math
    pkg/strings
    pkg/strconv
    pkg/bufio
    pkg/sort
    pkg/container/heap
    pkg/encoding/base64
    pkg/syscall
    pkg/time
    pkg/os
    pkg/reflect
    pkg/fmt
    pkg/encoding/json
    pkg/flag
    pkg/path/filepath
    pkg/path
    pkg/io/ioutil
    pkg/log
    pkg/regexp/syntax
    pkg/regexp
    pkg/go/token
    pkg/go/scanner
    pkg/go/ast
    pkg/go/parser
    pkg/os/exec
    pkg/os/signal
    pkg/net/url
    pkg/text/template/parse
    pkg/text/template
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 132: 23512 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    [ src]$ ../pkg/tool/linux_amd64/go_bootstrap
    Segmentation fault

    Kernel is 2.6.18-238.el5xen #1 SMP Tue Jan 4 16:15:36 EST 2011 x86_64
    x86_64 x86_64 GNU/Linux

    Thanks,
    Alex
    On Friday, March 1, 2013 1:57:48 AM UTC-5, Dave Cheney wrote:

    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build
    attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies
    in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of
    today's
    tip, attempting compilation on RHEL5. Compilation of the last
    release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/**proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alski85 at Mar 6, 2013 at 5:53 pm
    Thank you again, Dave and minux. Sorry for the delay in followup. Just
    tested again with today's tip.

    As a side note, the particular server i'm installing on does not have
    mercurial. I'm using mercurial on another server, moving the code over,
    then creating a dummy VERSION file. I don't believe that to be related,
    but am telling in full disclosure.

    Today's tip shows same issue on this server. Here is strace -

    execve("./go_bootstrap", ["./go_bootstrap"], [/* 22 vars */]) = 0
    arch_prctl(ARCH_SET_FS, 0x73a160) = 0
    sched_getaffinity(0, 128, { 3, 0, 0, 0 }) = 32
    mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x2b896cad9000
    mmap(NULL, 268476544, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
    0) = 0x2b896caf9000
    getrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
    mmap(0xc000000000, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
    0xc000000000
    munmap(0xc000000000, 65536) = 0
    mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x2b897cb04000
    mmap(0xc200000000, 1048576, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc200000000
    mmap(0xc1ffff0000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
    -1, 0) = 0xc1ffff0000
    mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x2b897cb24000
    mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
    0x2b897cb44000
    --- SIGSEGV (Segmentation fault) @ 0 (0) ---
    +++ killed by SIGSEGV +++

    I'll open an issue now as suggested.

    Thank you again,
    Alex

    On Sunday, March 3, 2013 10:31:17 AM UTC-5, minux wrote:

    Alternatively, if anyone could provide me a temporary shell account for an
    affected
    system, I'm willing to debug the problem (my only CentOS 5 machine is not
    affected
    and I'm not able to switch kernel on it).

    I just need strace and gdb to installed on the machine.

    On Sun, Mar 3, 2013 at 6:44 AM, Dave Cheney <da...@cheney.net<javascript:>
    wrote:
    Hello,

    I was unable to construct a working RHEL5 test environment on ec2
    yesterday, however another person with a RHEL5 machine confirmed that tip
    is working for them using RHEL5.4.

    I recommend that you raise an issue on the issue tracker,
    golang.org/issue, including the full build output that you previously
    posted, the hg id of the revision you tried, and as many details about the
    RHEL5 host that you have.

    Cheers

    Dave

    On 02/03/2013, at 2:34, als...@gmail.com <javascript:> wrote:

    Thank you for taking the time to respond and analyze what may be the
    problem.

    I do understand that it's been said that RHEL5 is not supported
    officially, and in fact the binary release packages do not work. That
    said, that the last release will compile and a current snapshot will not, I
    wanted to make it aware as I've seen no announcement/explanation in
    reasoning, meaning I'd initially want to consider it a bug, even if the
    platform is not being targeted. It feels like a rather large chunk of
    enterprise servers would now be excluded if released as is.

    My results seem identical to the original complainant - it seems
    go_bootstrap is the end problem -

    [ src]$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, linux/amd64.
    lib9
    libbio
    libmach
    misc/pprof
    cmd/addr2line
    cmd/cov
    cmd/nm
    cmd/objdump
    cmd/pack
    cmd/prof
    cmd/cc
    cmd/gc
    cmd/6l
    cmd/6a
    cmd/6c
    cmd/6g
    pkg/runtime
    pkg/errors
    pkg/sync/atomic
    pkg/sync
    pkg/io
    pkg/unicode
    pkg/unicode/utf8
    pkg/unicode/utf16
    pkg/bytes
    pkg/math
    pkg/strings
    pkg/strconv
    pkg/bufio
    pkg/sort
    pkg/container/heap
    pkg/encoding/base64
    pkg/syscall
    pkg/time
    pkg/os
    pkg/reflect
    pkg/fmt
    pkg/encoding/json
    pkg/flag
    pkg/path/filepath
    pkg/path
    pkg/io/ioutil
    pkg/log
    pkg/regexp/syntax
    pkg/regexp
    pkg/go/token
    pkg/go/scanner
    pkg/go/ast
    pkg/go/parser
    pkg/os/exec
    pkg/os/signal
    pkg/net/url
    pkg/text/template/parse
    pkg/text/template
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 132: 23512 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    [ src]$ ../pkg/tool/linux_amd64/go_bootstrap
    Segmentation fault

    Kernel is 2.6.18-238.el5xen #1 SMP Tue Jan 4 16:15:36 EST 2011 x86_64
    x86_64 x86_64 GNU/Linux

    Thanks,
    Alex
    On Friday, March 1, 2013 1:57:48 AM UTC-5, Dave Cheney wrote:

    Yes, RHEL5 has never been 'officially' supported as the minimum kernel
    for amd64 and 386 is 2.6.27, which is much newer than the 2.6.18 based
    RHEL5.

    Can you please reply with the entire build log of the failed build
    attempt.

    Cheers

    Dave

    On Fri, Mar 1, 2013 at 5:37 PM, Volker Dobler
    wrote:
    I thought that RHEL5 is not supported (too old libc)?

    Am Donnerstag, 28. Februar 2013 23:26:55 UTC+1 schrieb Alex:
    Hi,

    This is my first post to this list and on google groups, so apologies
    in
    advance if I'm not following proper protocol.

    I just wanted to add that this appears to still be an issue as of
    today's
    tip, attempting compilation on RHEL5. Compilation of the last
    release,
    1.0.3, completes as expected however.

    Thanks,
    Alex
    On Thursday, February 7, 2013 11:47:22 AM UTC-5, Jackie wrote:

    Hello,

    I met this error when I was building from source from tip() on
    CentOS release 5.6 (Final) 64bit

    ...
    pkg/go/doc
    pkg/go/build
    cmd/go
    ./make.bash: line 129: 23517 Segmentation fault
    "$GOTOOLDIR"/go_bootstrap clean -i std

    And then I switched to e018b45f9a6e and I got this:
    pkg/go/doc
    pkg/go/build
    cmd/go
    goroutine 1 [semacquire]:
    ----- stack segment boundary -----

    goroutine 2 [semacquire]:
    ----- stack segment boundary -----
    created by runtime.main
    /home/nemo/go/src/pkg/runtime/**proc.c:225

    Then I switched to release and it complied,

    Should I file this to the issue panel?

    Regards,
    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 7, '13 at 4:47p
activeMar 6, '13 at 5:53p
posts14
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase