public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* debugging libgo failures
@ 2019-03-12 18:20 Aldy Hernandez
  2019-03-12 19:28 ` Ian Lance Taylor
  0 siblings, 1 reply; 3+ messages in thread
From: Aldy Hernandez @ 2019-03-12 18:20 UTC (permalink / raw)
  To: GCC Mailing List; +Cc: Ian Lance Taylor

Hi Ian.  Hi folks.

I have some libgo failures which I'm pretty sure I caused (see below for 
details), but I can't seem to figure out how to reproduce.  Before I go 
down the rabbit hole, is there an easy way of reproducing say:

FAIL: database/sql
FAIL: net/http

I'm used to scouring 
x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining 
insight on how to manually run tests.  However, there's nothing in 
libgo/testsuite, and libgo/libgo.log just has a summary of tests.

Ideally I'd like a way of building a test (with say -fdump-tree-all), 
and/or sticking gdb on the resulting executable.

Thanks.
Aldy

--- FAIL: TestMaxIdleConns (0.00s)
     sql_test.go:1789: freeConns after set to zero = -1; want 0
     sql_test.go:1798: freeConns = -1; want 0
panic: runtime error: makeslice: cap out of range [recovered]
         panic: runtime error: makeslice: cap out of range

goroutine 202 [running]:
panic
         /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
testing.tRunner..func1
         /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
panic
         /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
database..z2fsql.DB.Close
 
/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
sql.closeDB
 
/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
database..z2fsql.TestMaxIdleConns
 
/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
testing.tRunner
         /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
created by testing.T.Run
         /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
FAIL: database/sql


[snip]
[snip]

net..z2fhttp.persistConn.writeLoop
 
/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
created by net..z2fhttp.Transport.dialConn
 
/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339 
+2693

eax    0x0
ebx    0x2
ecx    0xcbbdd84c
edx    0x0
edi    0x0
esi    0x8
ebp    0xcbbdd84c
esp    0xcbbdd830
eip    0xf7f93049
eflags 0x286
cs     0x23
fs     0x0
gs     0x63
FAIL: net/http

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: debugging libgo failures
  2019-03-12 18:20 debugging libgo failures Aldy Hernandez
@ 2019-03-12 19:28 ` Ian Lance Taylor
  2019-03-13 16:22   ` Aldy Hernandez
  0 siblings, 1 reply; 3+ messages in thread
From: Ian Lance Taylor @ 2019-03-12 19:28 UTC (permalink / raw)
  To: Aldy Hernandez; +Cc: GCC Mailing List, Ian Lance Taylor

On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez <aldyh@redhat.com> wrote:
>
> I have some libgo failures which I'm pretty sure I caused (see below for
> details), but I can't seem to figure out how to reproduce.  Before I go
> down the rabbit hole, is there an easy way of reproducing say:
>
> FAIL: database/sql
> FAIL: net/http
>
> I'm used to scouring
> x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining
> insight on how to manually run tests.  However, there's nothing in
> libgo/testsuite, and libgo/libgo.log just has a summary of tests.
>
> Ideally I'd like a way of building a test (with say -fdump-tree-all),
> and/or sticking gdb on the resulting executable.

To run a test, cd to the libgo build directly (TARGET/libgo) and run
`make database/sql/check`.  To see the exact commands that it runs,
including how the compiler is invoked, run `make GOTESTFLAGS=--trace
database/sql/check`.  To leave the directory behind with the test
program, run `make GOTESTFLAGS=--keep database/sql/check`.  That will
leave a gotestNNNN/test directory.  In that directory you can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
You can run specific failing tests using a -test.run option.  You can
of course run gdb on the program.

Hope that helps.

Ian


> --- FAIL: TestMaxIdleConns (0.00s)
>      sql_test.go:1789: freeConns after set to zero = -1; want 0
>      sql_test.go:1798: freeConns = -1; want 0
> panic: runtime error: makeslice: cap out of range [recovered]
>          panic: runtime error: makeslice: cap out of range
>
> goroutine 202 [running]:
> panic
>          /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
> testing.tRunner..func1
>          /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
> panic
>          /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
> database..z2fsql.DB.Close
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
> sql.closeDB
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
> database..z2fsql.TestMaxIdleConns
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
> testing.tRunner
>          /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
> created by testing.T.Run
>          /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
> FAIL: database/sql
>
>
> [snip]
> [snip]
>
> net..z2fhttp.persistConn.writeLoop
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
> created by net..z2fhttp.Transport.dialConn
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339
> +2693
>
> eax    0x0
> ebx    0x2
> ecx    0xcbbdd84c
> edx    0x0
> edi    0x0
> esi    0x8
> ebp    0xcbbdd84c
> esp    0xcbbdd830
> eip    0xf7f93049
> eflags 0x286
> cs     0x23
> fs     0x0
> gs     0x63
> FAIL: net/http

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: debugging libgo failures
  2019-03-12 19:28 ` Ian Lance Taylor
@ 2019-03-13 16:22   ` Aldy Hernandez
  0 siblings, 0 replies; 3+ messages in thread
From: Aldy Hernandez @ 2019-03-13 16:22 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: GCC Mailing List, Ian Lance Taylor



On 3/12/19 3:28 PM, Ian Lance Taylor wrote:
> On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>> I have some libgo failures which I'm pretty sure I caused (see below for
>> details), but I can't seem to figure out how to reproduce.  Before I go
>> down the rabbit hole, is there an easy way of reproducing say:
>>
>> FAIL: database/sql
>> FAIL: net/http
>>
>> I'm used to scouring
>> x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining
>> insight on how to manually run tests.  However, there's nothing in
>> libgo/testsuite, and libgo/libgo.log just has a summary of tests.
>>
>> Ideally I'd like a way of building a test (with say -fdump-tree-all),
>> and/or sticking gdb on the resulting executable.
> 
> To run a test, cd to the libgo build directly (TARGET/libgo) and run
> `make database/sql/check`.  To see the exact commands that it runs,
> including how the compiler is invoked, run `make GOTESTFLAGS=--trace
> database/sql/check`.  To leave the directory behind with the test
> program, run `make GOTESTFLAGS=--keep database/sql/check`.  That will
> leave a gotestNNNN/test directory.  In that directory you can run
> `LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
> You can run specific failing tests using a -test.run option.  You can
> of course run gdb on the program.
> 
> Hope that helps.

Thank you very very much.  This was exactly what I needed.  Bug fixed, 
btw :).

Is this information available somewhere in our docs or wiki?  It'd be 
incredibly useful for others I bet.

Thanks.
Aldy

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-03-13 16:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-12 18:20 debugging libgo failures Aldy Hernandez
2019-03-12 19:28 ` Ian Lance Taylor
2019-03-13 16:22   ` Aldy Hernandez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).