|
From: Adam D. <am...@st...> - 2003-08-27 21:25:42
|
Hi. I get this error whenever my app tries to exit: poll_for_ready_fds: select returned -1 valgrind: the `impossible' happened: poll_for_ready_fds: select failed?! Basic block ctr is approximately 19150000 sched status: <43 threads> My application is a fairly complicated multithreaded beast, with mixed sync/async IO, some signal handling, etc. I am running valgrind-20030725 on uclibc. I've successfully used valgrind for leak detection with a single threaded uclibc app. Is there a fix or workaround for this problem? Thanks, Adam |
|
From: Dirk M. <dm...@me...> - 2003-09-12 00:15:36
|
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. |
|
From: Dirk M. <dm...@gm...> - 2003-09-12 01:49:42
|
On Friday 12 September 2003 02:15, Dirk Morris wrote: > Does someone know how I can fix/workaround this? > Sorry if this is well known and documented elsewhere; I was unable to > find anything. Well, if you look at the code of valgrind it looks like some invalid fd is passed to it. do you call poll on a closed fd ? |