[Valgrind-users] poll_for_ready_fds: select failed?!

[Dirk M. <dm...@me...>]

I'm problem with valgrind.
Does someone know how I can fix/workaround this?
Sorry if this is well known and documented elsewhere; I was unable to 
find anything.

The error message is this:
valgrind: the `impossible' happened:
   poll_for_ready_fds: select failed?!
Basic block ctr is approximately 100000

The command I'm running is this:
valgrind --leak-check=yes  --leak-resolution=high --show-reachable=yes ./foo

./foo uses many threads (pthread) and does use poll quite a bit.
It happens when foo is cleaning up; it exits normally in the absense of 
valgrind.

Versions:

On Debian testing:
# dpkg -l | grep libc
ii  libc6          2.3.1-16       GNU C Library: Shared libraries and 
Timezone
ii  libc6-dev      2.3.1-16       GNU C Library: Development Libraries 
and Hea
# uname -a
Linux jimbo 2.5.68 #5 Fri Sep 5 10:22:36 PDT 2003 i686 GNU/Linux
# valgrind --version                
valgrind-20030725
# gcc -v                                     
Reading specs from /usr/lib/gcc-lib/i386-linux/3.3.1/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--with-system-zlib --enable-nls --without-included-gettext 
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug 
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.3.1 20030626 (Debian prerelease)




Full Output:
<snip>
Thu Sep 11 16:45:42 2003: Cleaning up...
poll_for_ready_fds: select returned -1

valgrind: the `impossible' happened:
   poll_for_ready_fds: select failed?!
Basic block ctr is approximately 100000

sched status:

Thread 1: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0
==16736==    at 0x403D2F11: __libc_nanosleep (in /lib/libc-2.3.1.so)
==16736==    by 0x8049E41: main (xenon.c:150)
==16736==    by 0x4034EA50: __libc_start_main (in /lib/libc-2.3.1.so)
==16736==    by 0x8049A94: (within /home/dmorris/work/xenon/xenon)

Thread 2: status = WaitSIG, associated_mx = 0x0, associated_cv = 0x0
==16736==    at 0x4031D3D9: sigwait (vg_libpthread.c:1297)
==16736==    by 0x804A3AE: _signal_watcher (xenon.c:329)
==16736==    by 0x4031C585: thread_wrapper (vg_libpthread.c:667)
==16736==    by 0x4016FE24: do__quit (vg_scheduler.c:2146)

Thread 3: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==16736==    at 0x401815A4: vgAllRoadsLeadToRome_poll (vg_intercept.c:95)
==16736==    by 0x4018165A: __poll (vg_intercept.c:366)
==16736==    by 0x4018238A: 
vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_erring 
(vg_intercept.c:883)
==16736==    by 0x40181869: vgAllRoadsLeadToRome_accept (vg_intercept.c:481)

Thread 6: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==16736==    at 0x403F0A54: __libc_read (in /lib/libc-2.3.1.so)
==16736==    by 0x805833E: ru_read_request (requtil.c:85)
==16736==    by 0x804F5B2: _reqhandler_handle_request (reqhandler.c:57)
==16736==    by 0x804F525: reqhandler_newtransform (reqhandler.c:40)


Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.

If that doesn't help, please report this bug to: js...@ac...

In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using.  Thanks.