|
From: Mike A. <man...@ac...> - 2003-10-24 20:41:35
|
Julian and others, First, thank you for your work on valgrind. It's really a great tool. In both valgrind 1.9.6 and the latest from the 12th of October, I have observed that a single thread of a valgrinded process that calls recvmsg() can block the entire process, not just the one thread. There is a message here from April of this year regarding a DCE RPC server that I believe was hit by the same bug, but it was misdiagnosed, and apparently went unsolved. Please find a short sample program that exploits this: http://www.gweep.net/~rocko/vgblock.tar.gz The program has two threads: a looping counter with printf()s, and a looping, blocking recvmsg() call. When run normally, the following output is generated: [1] thread 1 will count loops with a 0.5 second delay. [1] 0 [2] thread 2 will block on recvmsg() [1] 1 [1] 2 [1] 3 [1] 4 [1] 5 [1] 6 [1] 7 [1] 8 ... etc. When run in valgrind, the recvmsg() blocks the whole process: =3D=3D15065=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. =3D=3D15065=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian = Seward. =3D=3D15065=3D=3D Using valgrind-20030725, a program supervision = framework for x86-linux. =3D=3D15065=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian = Seward. =3D=3D15065=3D=3D Estimated CPU clock rate is 1313 MHz =3D=3D15065=3D=3D For more details, rerun with: -v =3D=3D15065=3D=3D=20 [1] thread 1 will count loops with a 0.5 second delay. [1] 0 [2] thread 2 will block on recvmsg() I hope there's an easy fix to this! Thanks, -Mike=20 =20 -------------------------------------------------------- =20 DISCLAIMER: The information contained in this e-mail is confidential = and is intended solely for the review of the named addressee, and in = conjunction with specific Acopia Networks business. Any review, = retransmission, dissemination or other use of, or taking of any action = in reliance upon, this information by persons or entities other than the = intended recipient is prohibited. If you are unable to treat this = information accordingly, or are not the intended recipient, please = notify us immediately by returning the e-mail to the originator. =20 |
|
From: Jeremy F. <je...@go...> - 2003-10-24 22:53:25
Attachments:
18-recv-nonblock.patch
|
On Fri, 2003-10-24 at 08:32, Mike Andrews wrote: > I hope there's an easy fix to this! Yes, that's a known problem with the stable version of valgrind. Unless it manages to intercept every blocking function, it can deadlock all the threads. I've attached a patch I used to fix this once, but I don't think it applies any more. You might be able to tweak it into a working form. The current development version fixes this by changing all the syscall handling so that they're allowed to block. J |