[Bug go/52583] New: Several new go testsuite failues on Solaris

[Bug go/52583] New: Several new go testsuite failues on Solaris

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

             Bug #: 52583
           Summary: Several new go testsuite failues on Solaris
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
        AssignedTo: ian@airs.com
        ReportedBy: ro@gcc.gnu.org
              Host: *-*-solaris2.*
            Target: *-*-solaris2.*
             Build: *-*-solaris2.*


Recently, a couple of go and libgo testsuite failures have occured on Solaris
where results were clean before:

* i386-pc-solaris2.11:

Running target unix/-m64
FAIL: go.go-torture/execute/select-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions 
FAIL: go.go-torture/execute/select-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops 
FAIL: go.test/test/chan/powser1.go execution,  -O2 -g 

panic: runtime error: invalid memory address or nil pointer dereference

        === libgo tests ===


Running target unix
FAIL: log
FAIL: net
FAIL: net/http
FAIL: net/http/httputil

        === libgo Summary for unix ===

# of expected passes        119
# of unexpected failures    4

Running target unix/-m64
FAIL: log
FAIL: net
FAIL: exp/norm
FAIL: go/doc
FAIL: net/http
FAIL: net/http/httptest
FAIL: net/http/httputil
FAIL: net/rpc
FAIL: old/netchan

        === libgo Summary for unix/-m64 ===

# of expected passes        114
# of unexpected failures    9


--- FAIL: log.TestAll (0.02 seconds)
    log_test.go:66: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56):
hello 23 world$" is ":0: hello 23 world"
    log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56):
hello 23 world$" is ":0: hello 23 world"
    log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56):
hello 23 world$" is ":0: hello 23 world"
    log_test.go:66: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12
20:22:43.453671 :0: hello 23 world"
    log_test.go:66: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12
20:22:43.455184 :0: hello 23 world"
FAIL
FAIL: log

--- FAIL: net.TestMulticastListener (0.00 seconds)
    sockoptip.go:67: First ListenMulticastUDP failed: setsockopt: Invalid
argument
pollServer WaitFD: select: Bad file number
panic: test timed out
FAIL: net

pollServer WaitFD: select: Bad file number
panic: test timed out
FAIL: net/http

pollServer WaitFD: select: Bad file number
panic: test timed out
FAIL: net/http/httputil

64-bit:

2012/03/12 20:47:35 Test RPC server listening on 127.0.0.1:51903
2012/03/12 20:47:35 Test HTTP RPC server listening on 127.0.0.1:53240
2012/03/12 20:47:35 rpc: rpc: can't find method Arith.BadOperation
2012/03/12 20:47:35 rpc: rpc: can't find method Arith.Unknown
2012/03/12 20:47:35 rpc: gob: type mismatch: no fields matched compiling
decoder for Args
2012/03/12 20:47:35 NewServer test RPC server listening on 127.0.0.1:61566
2012/03/12 20:47:35 rpc: rpc: can't find method Arith.BadOperation
2012/03/12 20:47:35 rpc: rpc: can't find method Arith.Unknown
2012/03/12 20:47:35 rpc: gob: type mismatch: no fields matched compiling
decoder for Args
2012/03/12 20:47:36 method ReplyNotPointer reply type not a pointer: rpc.Reply
2012/03/12 20:47:36 rpc Register: type ReplyNotPointer has no exported methods
of suitable type
2012/03/12 20:47:36 ArgNotPublic argument type not exported: *rpc.local
2012/03/12 20:47:36 rpc Register: type ArgNotPublic has no exported methods of
suitable type
2012/03/12 20:47:36 method ReplyNotPublic reply type not exported: *rpc.local
2012/03/12 20:47:36 rpc Register: type ReplyNotPublic has no exported methods
of suitable type
panic: runtime error: invalid memory address or nil pointer dereference
FAIL: net/rpc

unexpected fault address 200008
throw: fault
FAIL: old/netchan

* sparc-sun-solaris2.11:

  no go failures

        === libgo tests ===


Running target unix
FAIL: net
FAIL: net/http
FAIL: net/http/httputil
FAIL: text/template
FAIL: testing/quick

        === libgo Summary for unix ===

# of expected passes        118
# of unexpected failures    5

Running target unix/-m64
FAIL: log
FAIL: net
FAIL: net/http
FAIL: net/http/httputil

        === libgo Summary for unix/-m64 ===

# of expected passes        119
# of unexpected failures    4

  causes seem to be the same on Solaris/x86.

I haven't yet investigated in more detail.

  RAiner

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #1 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-14 19:27:09 UTC ---
(In reply to comment #0)

> --- FAIL: log.TestAll (0.02 seconds)
>     log_test.go:66: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56):
> hello 23 world$" is ":0: hello 23 world"
>     log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56):
> hello 23 world$" is ":0: hello 23 world"
>     log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56):
> hello 23 world$" is ":0: hello 23 world"
>     log_test.go:66: log output should match
> "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
> [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
> .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12
> 20:22:43.453671 :0: hello 23 world"
>     log_test.go:66: log output should match
> "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
> [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
> [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12
> 20:22:43.455184 :0: hello 23 world"
> FAIL
> FAIL: log

I also see these failures on alpha.

I have debugged this issue a bit: these failures happen only when useFormat is
false in function testPrint, at log_test.go:48. It looks to me that Println
doesn't handle long and short file names correctly.  Equivalent Printf function
works without problems, outputting correct expected strings.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> 2012-03-15 05:27:03 UTC ---
What's failing is not Printf or Println, but the filename and line number. 
Those are retrieved using DWARF lookup on the PC, and evidently something is
going wrong in that area.  It might be interesting to know if the test succeeds
using GOCFLAGS=-g, rather than the default -g -O2.

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-15 07:21:12 UTC ---
(In reply to comment #2)
> What's failing is not Printf or Println, but the filename and line number. 
> Those are retrieved using DWARF lookup on the PC, and evidently something is
> going wrong in that area.  It might be interesting to know if the test succeeds
> using GOCFLAGS=-g, rather than the default -g -O2.

Please note that with Printf I get correct filename and line number. This is
reflected in the report above, there are only 5 failures, only when useFormat
is false. DWARF lookup works OK.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> 2012-03-15 16:23:33 UTC ---
If you look at the test (libgo/go/log/log_test.go), you'll see that it simply
does

    if useFormat {
        Printf("hello %d world", 23)
    } else {
        Println("hello", 23, "world")
    }

This is calling log.Printf or log.Println.  Those both wind up calling
log.Output, which uses runtime.Caller to get a stack backtrace to their caller.
 For some reason that stack backtrace is correctly reporting the filename and
line number for the Printf call but is failing to report the filename and line
number for the Println call.  You can see this in the output, where it says
":0" rather than "log_test.go:56".

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #5 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-15 22:01:51 UTC ---
(In reply to comment #4)
> If you look at the test (libgo/go/log/log_test.go), you'll see that it simply
> does
> 
>     if useFormat {
>         Printf("hello %d world", 23)
>     } else {
>         Println("hello", 23, "world")
>     }
> 
> This is calling log.Printf or log.Println.  Those both wind up calling
> log.Output, which uses runtime.Caller to get a stack backtrace to their caller.

Right, the problem is triggered in line.go, line 111:

...
    for _, ln := range u.lines {
>>>		if pc < ln.addrs[0].pc || pc > ln.addrs[len(ln.addrs)-1].pc {
            continue
        }
...

The function is enter with pc:

(gdb) p/x *pc
$94 = 0x120005147

But ln.addrs ranges are set to:

(gdb) p ln.addrs
$95 = {__values = 0xf840002c00, __count = 17, __capacity = 32}
(gdb) p/x ln.addrs.__values[0].pc
$96 = 0x120004ca0
(gdb) p/x ln.addrs.__values[16].pc
$97 = 0x120004df4

However, the function is located at:

#8  0x0000000120005148 in log.testPrint (t=0xf840416d90, flag=<optimized out>,
prefix=..., pattern=..., useFormat=false) at log_test.go:45
45                      Println("hello", 23, "world")
(gdb) disass
Dump of assembler code for function log.testPrint:

   0x0000000120004ca0 <+0>:     ldah    gp,2(t12)
   0x0000000120004ca4 <+4>:     lda     gp,-1912(gp)
   0x0000000120004ca8 <+8>:     ldq     t12,-32456(gp)
   0x0000000120004cac <+12>:    lda     sp,-432(sp)
   ...
   0x0000000120005144 <+1188>:  bsr     ra,0x1200071c8
<libgo_log.log.Println+8>
=> 0x0000000120005148 <+1192>:  unop
   0x000000012000514c <+1196>:  unop
   0x0000000120005150 <+1200>:  br      0x120004dd8 <log.testPrint+312>
   0x0000000120005154 <+1204>:  ldq     t12,-32744(gp)
   0x0000000120005158 <+1208>:  lda     a0,5
   0x000000012000515c <+1212>:  jsr     ra,(t12),0x120005160
<log.testPrint+1216>

(line numbers are slightly changed due to my changes to log_test.go source for
debug purposes).

It looks that ln.addrs ranges are not correctly set. For some reason, line
numbers are truncated at line 48:

(gdb) p ln.addrs.__values[0].line
$100 = 37
(gdb) p ln.addrs.__values[16].line
$101 = 48

But the function in fact ends at line 58 in my case.

It just happens that the call to libgo_log.log.Printf lies inside (truncated)
ln.addrs[].pc ranges:

   0x0000000120004dc8 <+296>:   unop
   0x0000000120004dcc <+300>:   bsr     ra,0x120007148 <libgo_log.log.Printf+8>
   0x0000000120004dd0 <+304>:   unop
   0x0000000120004dd4 <+308>:   unop

Any further help where to look for how ln.addrs ranges are determined?

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> 2012-03-16 03:18:46 UTC ---
Thanks for looking at this.

The first step is to run readelf --debug=line FILE to make sure that the line
number information is recorded correctly.  Which of course it probably is.  If
you have trouble parsing the --debug=line output, try --debug=decodedline.

The place that Go is reading that information is libgo/go/debug/dwarf/line.go. 
Most likely something is going wrong in the way that it gathers the
information, but I don't know what.

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-16 08:44:50 UTC ---
(In reply to comment #6)
> Thanks for looking at this.
> 
> The first step is to run readelf --debug=line FILE to make sure that the line
> number information is recorded correctly.  Which of course it probably is.  If
> you have trouble parsing the --debug=line output, try --debug=decodedline.
> 
> The place that Go is reading that information is libgo/go/debug/dwarf/line.go. 
> Most likely something is going wrong in the way that it gathers the
> information, but I don't know what.

Something happens at line 48 (is_stmt is briefly toggled and Discriminator is
set):

  Special opcode 9: advance Address by 0 to 0x120004dd8 and Line by 4 to 47
  Special opcode 76: advance Address by 20 to 0x120004dec and Line by 1 to 48
  Special opcode 18: advance Address by 4 to 0x120004df0 and Line by -1 to 47
  Special opcode 20: advance Address by 4 to 0x120004df4 and Line by 1 to 48
  Extended opcode 4: set Discriminator to 2
  Set is_stmt to 0
  Special opcode 33: advance Address by 8 to 0x120004dfc and Line by 0 to 48
  Extended opcode 4: set Discriminator to 2
  Set is_stmt to 1
  Special opcode 118: advance Address by 32 to 0x120004e1c and Line by 1 to 49
  Extended opcode 4: set Discriminator to 2
  Special opcode 18: advance Address by 4 to 0x120004e20 and Line by -1 to 48
  Extended opcode 4: set Discriminator to 2
  Special opcode 20: advance Address by 4 to 0x120004e24 and Line by 1 to 49
  Extended opcode 4: set Discriminator to 2
  Special opcode 116: advance Address by 32 to 0x120004e44 and Line by -1 to 48

Also --debug=decodedline says:

log_test.go                                   47         0x120004dd8
log_test.go                                   48         0x120004dec
log_test.go                                   47         0x120004df0
log_test.go                                   48         0x120004df4
UNKNOWN: length 2
log_test.go                                   48         0x120004dfc
UNKNOWN: length 2
log_test.go                                   49         0x120004e1c

It is probably this UNKNOWN that disturbs decoding.

[Bug go/52583] Several new go testsuite failues on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-03-16 09:55:26 UTC ---
I've found that this failure on Solaris

--- FAIL: net.TestMulticastListener (0.00 seconds)
        sockoptip.go:67: First ListenMulticastUDP failed: setsockopt: Invalid
argument

is caused by Solaris using sockoptip_linux.go, which passes an int to
setsockopt for IP_MULTICAST_LOOP, where Solaris expects and unsigned char.

I'm fixing this by using a new sockoptip_solaris.go which does this
right.

I'm now running into

--- FAIL: net.TestMulticastListener (0.00 seconds)
        sockoptip.go:118: "224.0.0.254:12345" not found in RIB

still looking what's going on here.  And the 

pollServer WaitFD: select: Bad file number

errors here and in net/http and net/http/httputil remain.

    Rainer

[Bug go/52583] Several new go testsuite failues on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-03-16 11:03:28 UTC ---
> I'm now running into
>
> --- FAIL: net.TestMulticastListener (0.00 seconds)
>         sockoptip.go:118: "224.0.0.254:12345" not found in RIB
>
> still looking what's going on here.  And the 

No wonder this doesn't work: the code ultimately calls
interfaceMulticastAddrTable, but Solaris uses interface_stub.go, and
none of the other implementations are remotely usable.  I concoct
something using the SIOCGLIFNUM and SIOCGLIFCONF ioctls.

    Rainer

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #10 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-16 11:05:33 UTC ---
(In reply to comment #8)

> I'm now running into
> 
> --- FAIL: net.TestMulticastListener (0.00 seconds)
>         sockoptip.go:118: "224.0.0.254:12345" not found in RIB
> 
> still looking what's going on here.  And the 

Please see [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00639.html

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-17 15:13:15 UTC ---
Created attachment 26906
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26906
Patch to log/log_test.go that witll trigger the failure on x86_64.

(In reply to comment #6)

> The place that Go is reading that information is libgo/go/debug/dwarf/line.go. 
> Most likely something is going wrong in the way that it gathers the
> information, but I don't know what.

Attached patch will trigger the failure on x86_64.

Please place breakpoint at findLine (line.go:103), and check ranges at
line.go:111:

(gdb) p ln.addrs 
$7 = {__values = 0xf8400a3900, __count = 6, __capacity = 8}
(gdb) p ln.addrs.__values[0]
$8 = {pc = 4212288, line = 60}
(gdb) p ln.addrs.__values[5]
$9 = {pc = 4212356, line = 60}

(gdb) p/x ln.addrs.__values[0].pc
$11 = 0x404640
(gdb) p/x ln.addrs.__values[5].pc
$12 = 0x404684

(gdb) p/x *pc
$13 = 0x4047d5

The pc will be outside the boundaries, and will cause:

[uros@localhost gotest30392]$ ./a.out
--- FAIL: log.TestAll (0.01 seconds)
        log_test.go:55: log output should match
"^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is ":0: hello 23 world"
FAIL

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> 2012-03-17 16:41:21 UTC ---
Can you attach the output of readelf --debug (not just --debug=line) for the
program that fails?

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #13 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-17 17:18:30 UTC ---
Created attachment 26907
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26907
readelf --debug output for patched log/check a.out

Output of readelf --debug on x86_64, patched log/check test.

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-17
     Ever Confirmed|0                           |1

--- Comment #14 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-17 17:22:00 UTC ---
(In reply to comment #11)

> Patch to log/log_test.go that witll trigger the failure on x86_64.

Maybe I should say that this is on x86_64-pc-linux-gnu.

[Bug go/52583] Several new go testsuite failues on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-03-20 13:48:51 UTC ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-03-16 09:55:26 UTC ---
[...]
> I'm now running into
>
> --- FAIL: net.TestMulticastListener (0.00 seconds)
>         sockoptip.go:118: "224.0.0.254:12345" not found in RIB
>
> still looking what's going on here.  And the 

This is caused by Solaris using go/net/interface_stub.go.  After some
investigation, it turns out that while the interfaceTable and
interfaceAddrTable functions could be implemented in several different
ways (e.g. routing sockets and SIOCGLIFNUM, SIOCGLIFCONF ioctls),
interfaceMulticastAddrTable requires the use of the SNMP MIB-2
functionality described in <inet/mib2.h>, which also covers the other
two.

I'll try to come up with something, based on the code in net-snmp and
the OpenSolaris netstat.c.

    Rainer

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #16 from Ian Lance Taylor <ian at airs dot com> 2012-04-24 20:43:33 UTC ---
I think that the problems with the log test should be fixed now.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #17 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-04-25 04:26:21 UTC ---
Author: ian
Date: Wed Apr 25 04:26:12 2012
New Revision: 186801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186801
Log:
    PR go/52583

net: Solaris fixes.

In particular fix fd_select.go to handle the case where a file
descriptor is closed by one goroutine while another goroutine
is waiting for it.

Added:
    trunk/libgo/go/net/sock_solaris.go
    trunk/libgo/go/net/sockoptip_solaris.go
Modified:
    trunk/libgo/Makefile.am
    trunk/libgo/Makefile.in
    trunk/libgo/go/net/dial_test.go
    trunk/libgo/go/net/fd_select.go
    trunk/libgo/go/net/multicast_test.go

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #18 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-04-25 04:26:37 UTC ---
Author: ian
Date: Wed Apr 25 04:26:31 2012
New Revision: 186802

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186802
Log:
    PR go/52583

net: Solaris fixes.

In particular fix fd_select.go to handle the case where a file
descriptor is closed by one goroutine while another goroutine
is waiting for it.

Added:
    branches/gcc-4_7-branch/libgo/go/net/sock_solaris.go
    branches/gcc-4_7-branch/libgo/go/net/sockoptip_solaris.go
Modified:
    branches/gcc-4_7-branch/libgo/Makefile.am
    branches/gcc-4_7-branch/libgo/Makefile.in
    branches/gcc-4_7-branch/libgo/go/net/dial_test.go
    branches/gcc-4_7-branch/libgo/go/net/fd_select.go
    branches/gcc-4_7-branch/libgo/go/net/multicast_test.go

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.7.0                       |4.7.1

--- Comment #19 from Ian Lance Taylor <ian at airs dot com> 2012-04-25 04:28:27 UTC ---
With the patches I just committed, sparc-sun-solaris2.11 passes all the Go
tests for me.

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #20 from Uros Bizjak <ubizjak at gmail dot com> 2012-04-25 06:40:13 UTC ---
(In reply to comment #16)
> I think that the problems with the log test should be fixed now.

Yes, my latest libgo testrun on alpha [1] is clean.

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02214.html

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #21 from Ian Lance Taylor <ian at airs dot com> 2012-04-25 14:56:56 UTC ---
I no longer see any failures on i386 Solaris.  I see a few failures on x86_64
Solaris.  They are all crashing in x86_64_fallback_frame_state when trying to
unwind through a signal handler.  The x86_64_fallback_frame_state function
assumes, quite reasonably, that context->pc is a valid memory address. 
Unfortunately, many Go stacks begin with a stack passed to makecontext.  The
implementation of makecontext in the Solaris libc does not seem to have
appropriate unwind information.  Ideally it should specifically set the return
address unwind column to be undefined, as described by DWARF.  Right now, an
attempt to unwind the stack frame up to the point of makecontext will sometimes
produce an invalid value for the PC of the (nonexistent) frame that called
makecontext.  And that leads to the crash.

I think the only fixes are for Solaris to correct makecontext so that it sets
up proper unwind information, or for libgo to implement a version of
makecontext specific for its purposes.  The latter will not happen for 4.7.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED

--- Comment #22 from Ian Lance Taylor <ian at airs dot com> 2012-04-27 16:41:42 UTC ---
Suspending this PR until either Solaris fixes x86_64 makecontext or libgo
starts using a different mechanism.

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #23 from Uros Bizjak <ubizjak at gmail dot com> 2012-08-26 06:59:43 UTC ---
(In reply to comment #16)
> I think that the problems with the log test should be fixed now.

The problem resurfaced again on alpha [1]:

--- FAIL: log.TestAll (0.26 seconds)
        :0: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello
23 world$" is ":0: hello 23 world"
        :0: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello
23 world$" is ":0: hello 23 world"
        :0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
        :0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
        :0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
        :0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
        :0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.721082 :0: hello 23 world"
        :0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.743545 :0: hello 23 world"
        :0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.772843 :0: hello 23 world"
        :0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.793352 :0: hello 23 world"
FAIL
FAIL: log

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02550.html

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #24 from Uros Bizjak <ubizjak at gmail dot com> 2012-08-26 07:53:02 UTC ---
(In reply to comment #23)
> (In reply to comment #16)
> > I think that the problems with the log test should be fixed now.
> 
> The problem resurfaced again on alpha [1]:

Comment 11 has a testcase patch, when applied to log/log_test.go test source,
this problem will trigger on x86_64-pc-linux-gnu too.

[Bug go/52583] Several new go testsuite failues on Solaris

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-08-26 08:41:25 UTC ---
(In reply to comment #23)
> The problem resurfaced again on alpha [1]:

And on mips64.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #26 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-09-06 05:28:12 UTC ---
Author: ian
Date: Thu Sep  6 05:28:02 2012
New Revision: 191008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191008
Log:
debug/elf, debug/dwarf: DWARF line number fixes.

Support DW_AT_high_pc as a constant.
Support DW_AT_ranges.

PR gcc/52583

Modified:
    trunk/libgo/go/debug/dwarf/line.go
    trunk/libgo/go/debug/elf/file.go

--- Comment #27 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-09-06 05:28:26 UTC ---
Author: ian
Date: Thu Sep  6 05:28:19 2012
New Revision: 191009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191009
Log:
debug/elf, debug/dwarf: DWARF line number fixes.

Support DW_AT_high_pc as a constant.
Support DW_AT_ranges.

PR gcc/52583

Modified:
    branches/gcc-4_7-branch/libgo/go/debug/dwarf/line.go
    branches/gcc-4_7-branch/libgo/go/debug/elf/file.go

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #26 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-09-06 05:28:12 UTC ---
Author: ian
Date: Thu Sep  6 05:28:02 2012
New Revision: 191008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191008
Log:
debug/elf, debug/dwarf: DWARF line number fixes.

Support DW_AT_high_pc as a constant.
Support DW_AT_ranges.

PR gcc/52583

Modified:
    trunk/libgo/go/debug/dwarf/line.go
    trunk/libgo/go/debug/elf/file.go

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #27 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-09-06 05:28:26 UTC ---
Author: ian
Date: Thu Sep  6 05:28:19 2012
New Revision: 191009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191009
Log:
debug/elf, debug/dwarf: DWARF line number fixes.

Support DW_AT_high_pc as a constant.
Support DW_AT_ranges.

PR gcc/52583

Modified:
    branches/gcc-4_7-branch/libgo/go/debug/dwarf/line.go
    branches/gcc-4_7-branch/libgo/go/debug/elf/file.go

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #28 from Ian Lance Taylor <ian at airs dot com> 2012-09-06 05:30:05 UTC ---
The log test problems should be fixed again.

If it reappears, please don't add to this PR.  This PR is about Solaris
problems.  Open a new PR instead.  Thanks.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

--- Comment #29 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jun 13 13:56:14 2014
New Revision: 211640

URL: https://gcc.gnu.org/viewcvs?rev=211640&root=gcc&view=rev
Log:
    PR go/52583
runtime: Stop backtrace at a few recognized functions.

On x86_64 Solaris the makecontext function does not properly
indicate that it is at the top of the stack.  Attempting to
unwind the stack past a call to makecontext tends to crash.
This patch changes libgo to look for certain functions that
are always found at the top of the stack, and to stop
unwinding when it reaches one of those functions.  There is
never anything interesting past these functions--that is,
there is never any code written by the user.

Modified:
    trunk/libgo/runtime/go-callers.c

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #30 from Ian Lance Taylor <ian at airs dot com> ---
This should be fixed now on mainline (the future 4.10).