|
From: Michael R. <mr...@wi...> - 2005-11-30 18:20:18
|
I'm running valgrind --tool=memcheck on a network program. When it calls socket I am getting an EINTR error. This only happens under valgrind. $ valgrind --version valgrind-2.2.0 $ uname -a Linux hp 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux errno = 4 perror = Interrupted system call Thanks for any help/advise. |
|
From: Tom H. <to...@co...> - 2005-11-30 18:50:00
|
In message <a06100536bfb39c90432d@[10.100.2.144]>
Michael Rutman <mr...@wi...> wrote:
> I'm running valgrind --tool=memcheck on a network program. When it calls
> socket I am getting an EINTR error. This only happens under valgrind.
>
> $ valgrind --version
> valgrind-2.2.0
>
> $ uname -a
> Linux hp 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386
> GNU/Linux
>
> errno = 4
> perror = Interrupted system call
>
> Thanks for any help/advise.
Well your program will be running more slowly under valgrind so maybe
the timing changes and makes it more likely that you get a signal during
that call - in other words maybe it is an issue that has always been
there that valgrind is exposing.
You haven't actually said which system call is involved, but in general
any blocking call may return EINTR unless you have been careful to
ensure that all signals are marked as restartable and you should
therefore expect to have to handle that error.
If you run with --trace-signals=yes then you should see what the signal
is that is causing the interrupt which might provide more clues about
what is going on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Duncan S. <bal...@fr...> - 2005-12-01 08:14:56
|
> I'm running valgrind --tool=memcheck on a network program. When it calls > socket I am getting an EINTR error. This only happens under valgrind. It doesn't happen when running in gdb or under strace? D. |
|
From: Michael R. <mr...@wi...> - 2005-12-01 15:18:48
|
At 12:14 AM -0800 12/1/05, Duncan Sands wrote: >> I'm running valgrind --tool=memcheck on a network program. When it calls >> socket I am getting an EINTR error. This only happens under valgrind. > >It doesn't happen when running in gdb or under strace? > It's worse under gdb. (gdb) set args --tool=memcheck Dev/WWCS (gdb) r Starting program: /usr/bin/valgrind --tool=memcheck Dev/WWCS ==17348== Memcheck, a memory error detector for x86-linux. ==17348== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==17348== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==17348== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==17348== For more details, rerun with: -v ==17348== Program received signal SIGSEGV, Segmentation fault. 0xb1033ed8 in ?? () (gdb) |
|
From: Tom H. <to...@co...> - 2005-12-01 15:31:11
|
In message <a06100542bfb4c48ea317@[10.100.2.144]>
Michael Rutman <mr...@wi...> wrote:
> At 12:14 AM -0800 12/1/05, Duncan Sands wrote:
>>> I'm running valgrind --tool=memcheck on a network program. When it calls
>>> socket I am getting an EINTR error. This only happens under valgrind.
>>
>>It doesn't happen when running in gdb or under strace?
>
> It's worse under gdb.
>
> (gdb) set args --tool=memcheck Dev/WWCS
> (gdb) r
> Starting program: /usr/bin/valgrind --tool=memcheck Dev/WWCS
> ==17348== Memcheck, a memory error detector for x86-linux.
> ==17348== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
> ==17348== Using valgrind-2.2.0, a program supervision framework for x86-linux.
> ==17348== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==17348== For more details, rerun with: -v
> ==17348==
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb1033ed8 in ?? ()
> (gdb)
You can't debug valgrind like that - read README_DEVELOPERS to find
out the correct way to do it.
I don't think that is what Duncan was suggesting however - he was
suggesting just running your program under gdb I think. Not sure why.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Duncan S. <bal...@fr...> - 2005-12-01 15:26:34
|
On Thursday 1 December 2005 16:18, Michael Rutman wrote: > At 12:14 AM -0800 12/1/05, Duncan Sands wrote: > >> I'm running valgrind --tool=memcheck on a network program. When it calls > >> socket I am getting an EINTR error. This only happens under valgrind. > > > >It doesn't happen when running in gdb or under strace? > > > > > > It's worse under gdb. > > (gdb) set args --tool=memcheck Dev/WWCS > (gdb) r > Starting program: /usr/bin/valgrind --tool=memcheck Dev/WWCS > ==17348== Memcheck, a memory error detector for x86-linux. > ==17348== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. > ==17348== Using valgrind-2.2.0, a program supervision framework for x86-linux. > ==17348== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. > ==17348== For more details, rerun with: -v > ==17348== > > Program received signal SIGSEGV, Segmentation fault. > 0xb1033ed8 in ?? () > (gdb) Actually, I meant if you run the original program in gdb or under strace, for example: gdb Dev/WWCS The reason I ask is that I've seen similar problems with such tools, especially when using socket timeouts. Ciao, Duncan. |
|
From: Michael R. <mr...@wi...> - 2005-12-01 15:37:57
|
At 7:26 AM -0800 12/1/05, Duncan Sands wrote: >On Thursday 1 December 2005 16:18, Michael Rutman wrote: >> At 12:14 AM -0800 12/1/05, Duncan Sands wrote: >> >> I'm running valgrind --tool=memcheck on a network program. When it calls >> >> socket I am getting an EINTR error. This only happens under valgrind. >> > >> >It doesn't happen when running in gdb or under strace? >> > >> >> >> >> It's worse under gdb. >> >> (gdb) set args --tool=memcheck Dev/WWCS >> (gdb) r >> Starting program: /usr/bin/valgrind --tool=memcheck Dev/WWCS >> ==17348== Memcheck, a memory error detector for x86-linux. >> ==17348== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. >> ==17348== Using valgrind-2.2.0, a program supervision framework for >>x86-linux. >> ==17348== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. >> ==17348== For more details, rerun with: -v >> ==17348== >> >> Program received signal SIGSEGV, Segmentation fault. >> 0xb1033ed8 in ?? () >> (gdb) > >Actually, I meant if you run the original program in gdb or under strace, for >example: > gdb Dev/WWCS >The reason I ask is that I've seen similar problems with such tools, >especially >when using socket timeouts. > Ah, no, works flawlessly under gdb. I'm not sure why an EINTR is being issued. The call to socket shouldn't ever be returning that according to the man page. |
|
From: Tom H. <to...@co...> - 2005-12-01 15:43:21
|
In message <a06100544bfb4c915b2b5@[10.100.2.144]>
Michael Rutman <mr...@wi...> wrote:
> I'm not sure why an EINTR is being issued. The call to socket shouldn't
> ever be returning that according to the man page.
Sorry. I misunderstood your original email. I thought you were talking
about socket related calls in general, not the socket call specifically.
I don't think socket will ever raise an EINTR error - this is a
PF_INET socket I assume?
Are you absolutely sure that is where the error is coming from? The
socket function is returning -1 and an immediate check of errno gives
a value of EINTR?
What does adding "--trace-syscalls=yes --trace-signals=yes" show?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2005-12-01 15:55:00
|
At 16:37 01.12.2005, Michael Rutman wrote: >I'm not sure why an EINTR is being issued. The call to socket >shouldn't ever be returning that according to the man page. My manpage says (along with other specific errors): Other errors may be generated by the underlying protocol modules. Usually on every unix like system you should assume that *every* system call can be interrupted by a signal, unless it is set as restartable. Id suggest that you figure out what signal interrupted the syscall, and then what caused the signal. greets Dennis Carpe quod tibi datum est |
|
From: Duncan S. <bal...@fr...> - 2005-12-01 15:47:11
|
> Ah, no, works flawlessly under gdb. OK. > I'm not sure why an EINTR is being issued. The call to socket shouldn't > ever be returning that according to the man page. Is it the kernel or libc that generates the EINTR? D. |
|
From: Michael R. <mr...@wi...> - 2005-12-01 15:59:54
|
At 7:47 AM -0800 12/1/05, Duncan Sands wrote: >> Ah, no, works flawlessly under gdb. > >OK. > >> I'm not sure why an EINTR is being issued. The call to socket shouldn't >> ever be returning that according to the man page. > >Is it the kernel or libc that generates the EINTR? > Sorry for wasting everyone's time. I was using the valgrind installed on RHEL 3. I pulled the sources for valgrind 2.4.1 to see if it was throwing the exception and it works fine. So, the lesson is, don't use the installed one but always grab the latest sources. Thanks for the advise. |
|
From: Tom H. <to...@co...> - 2005-12-01 16:18:26
|
In message <a06100545bfb4cc256a9d@[10.100.2.144]>
Michael Rutman <mr...@wi...> wrote:
> At 7:47 AM -0800 12/1/05, Duncan Sands wrote:
>>
>>> I'm not sure why an EINTR is being issued. The call to socket shouldn't
>>> ever be returning that according to the man page.
>>
>>Is it the kernel or libc that generates the EINTR?
>>
>
> Sorry for wasting everyone's time. I was using the valgrind installed on
> RHEL 3.
Oh right. I was kind of assuming we were talking valgrind 3 at least.
> I pulled the sources for valgrind 2.4.1 to see if it was throwing the
> exception and it works fine.
>
> So, the lesson is, don't use the installed one but always grab the latest
> sources.
Which 2.4.1 isn't...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-12-01 16:51:50
|
> > So, the lesson is, don't use the installed one but always grab the latest > > sources. > > Which 2.4.1 isn't... Not even slightly. Michael, try 3.1.0 and let us know what happens. J |