This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup


Uros Bizjak <ubizjak@gmail.com> writes:

> What remains is a couple of unrelated failures in the testsuite:
>
> Epoll unexpected fd=0
> pollServer: unexpected wakeup for fd=0 mode=w
> panic: test timed out
> ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388:  7123 Aborted
>                 ./a.out -test.short -test.timeout=$timeout "$@"
> FAIL: http
> gmake[2]: *** [http/check] Error 1
>
> 2011/07/05 18:43:28 Test RPC server listening on 127.0.0.1:50334
> 2011/07/05 18:43:28 Test HTTP RPC server listening on 127.0.0.1:49010
> 2011/07/05 18:43:28 rpc.Serve: accept:accept tcp 127.0.0.1:50334:
> Resource temporarily unavailable
> FAIL: rpc
> gmake[2]: *** [rpc/check] Error 1
>
> 2011/07/05 18:44:22 Test WebSocket server listening on 127.0.0.1:40893
> Epoll unexpected fd=0
> pollServer: unexpected wakeup for fd=0 mode=w
> panic: test timed out
> ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 12993 Aborted
>                 ./a.out -test.short -test.timeout=$timeout "$@"
> FAIL: websocket
> gmake[2]: *** [websocket/check] Error 1
>
> ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 13945
> Segmentation fault      ./a.out -test.short -test.timeout=$timeout
> "$@"
> FAIL: compress/flate
> gmake[2]: *** [compress/flate/check] Error 1
>
> Any ideas how to attack these?

None of these look familiar to me.

An "Epoll unexpected fd" error means that epoll returned information
about a file descriptor which the program didn't ask about.  Not sure
why that would happen.  Particularly for fd 0, since epoll is only used
for network connections, which fd 0 presumably is not.

The way to look into these is to cd to TARGET/libgo and run "make
GOTESTFLAGS=--keep http/check" (or whatever/check).  That will leave a
directory gotestNNNN in your libgo directory.  The executable a.out in
that directory is the test case.  You can debug the test case using gdb
in more or less the usual way.  It's a bit painful to set breakpoints by
function name, but setting breakpoints by file:line works fine.
Printing variables works as well as it ever does, but the variables are
printed in C form rather than Go form.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]