On Tue, Jul 5, 2011 at 10:12 PM, Ian Lance Taylor <i...@google.com> wrote:
>> 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.
It turned out that the EpollEvent definition in
libgo/syscalls/epoll/socket_epoll.go is non-portable (if not outright
dangerous...). The definition does have a FIXME comment, but does not
take into account the effects of __attribute__((__packed__)) from
system headers. Contrary to alpha header, x86 has
__attribute__((__packed__)) added to struct epoll_event definition in
sys/epoll.h header.
To illustrate the problem, please run following test:
--cut here--
#include <stdint.h>
#include <stdio.h>
typedef union epoll_data
{
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
struct epoll_event
{
uint32_t events;
epoll_data_t data;
};
struct packed_epoll_event
{
uint32_t events;
epoll_data_t data;
} __attribute__ ((__packed__));
struct fake_epoll_event
{
uint32_t events;
int32_t fd;
int32_t pad;
};
int
main ()
{
struct epoll_event *ep;
struct packed_epoll_event *pep;
struct fake_epoll_event fep;
fep.events = 0xfe;
fep.fd = 9;
fep.pad = 0;
ep = (struct epoll_event *) &fep;
pep = (struct packed_epoll_event *) &fep;
printf ("%#x %i\n", ep->events, ep->data.fd);
printf ("%#x %i\n", pep->events, pep->data.fd);
return 0;
}
--cut here--
./a.out
0xfe 0
0xfe 9
So, the first line simulates the alpha, the second simulates x86_64.
32bit targets are OK in both cases:
./a.out
0xfe 9
0xfe 9
By changing the definition of EpollEvent to the form that suits alpha:
type EpollEvent struct {
Events uint32;
Pad int32;
Fd int32;
};
both timeouts got fixed and correct FD was passed to and from the syscall.
Uros.
