Re: [Valgrind-users] valgrind and poll()

[David E. <da...@2g...>]

On Wed, 2003-04-02 at 19:41, Jeff Johnson wrote:
> On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote:
> > Hello,
> > 
> > First, the obligatory credits: Thank you very much for writing valgrind!
> > 
> > When I recently subscribed to this mailing list I read a message from
> > Nicholas Nethercote where he said that 1.9.4 was more stable and worked
> > better than 1.0.4 so I thought I'd give it a try.
> > 
> > However, it seems to me like something has changed between the two
> > versions, maybe regarding the combination threads and sockets.
> > 
> > I am running RedHat 8.0, with the latest updates installed:
> > 
> >   kernel-2.4.18-27.8.0
> >   glibc-2.3.2-4.80
> >   gcc-3.2-7
> > 
> > The application I'm examining with valgrind is a threaded server
> > application written in C that uses glib. It is quite large and
> > complicated to install, so there is no point in providing it.
> > 
> > I have tried to make a scaled-down example to reproduce my problem. It
> > is not finished yet, but I thought that I'll try to describe the problem
> > in case anyone has any suggestions:
> > 
> > The server creates a unix socket and makes glib poll() the socket for
> > events. A client connects to the server, which accept() the connection
> > and creates a new thread for handling the connection.
> > 
> > By using simple "printf debugging" it seems like the the new thread
> > never gets scheduled to run in valgrind 1.9.4.
> > 
> > For the fun of it, I tried to send a SIGHUP to my process. There is
> > singal handler installed with signal() for SIGHUP, which gets executed
> > properly. What also happens is that all threads (one for each connection
> > that have been made to the server) get to run!
> > 
> > Do you have any ideas?
> 
> FYI: You're running a NPTL capable library with a NPTL deprived kernel.
> 
> Meanwhile, prefix your valgrind command with
> 	LD_ASSUME_KERNEL=2.2.5 valgrind ...
> to force use of Good Old libpthread.

Well, pthread is never loaded when using valgrind as valgrind maintains
its own thread scheduling:

...
==29456== Reading syms from /usr/local/lib/valgrind/libpthread.so
...

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds