[child0:1694] <timed out>

[child0:1694] <timed out>

[Toralf Förster]

With latest git tree I do get now a lot of lines like :

[child0:1694] <timed out>
[child0:1694] <timed out>
[child0:1694] <timed out>
[child1:1695] <timed out>
[child0:1694] <timed out>
[child0:1694] <timed out>
[child1:1695] <timed out>

for a command like this: MALLOC_CHECK_=2 trinity -C 2 -N 100000 -x mremap -q -V /tmp/victims/v1/v2

It is intended ?


-- 
Toralf

Re: [child0:1694] <timed out>

[Dave Jones]

On Thu, Aug 14, 2014 at 07:17:48PM +0200, Toralf Förster wrote:
 > With latest git tree I do get now a lot of lines like :
 > 
 > [child0:1694] <timed out>
 > [child0:1694] <timed out>
 > [child0:1694] <timed out>
 > [child1:1695] <timed out>
 > [child0:1694] <timed out>
 > [child0:1694] <timed out>
 > [child1:1695] <timed out>
 > 
 > for a command like this: MALLOC_CHECK_=2 trinity -C 2 -N 100000 -x mremap -q -V /tmp/victims/v1/v2
 > 
 > It is intended ?

It's not a new thing (at least from Trinity's perspective).
If a syscall takes more than a second to complete, we send it a kill
signal.  Some syscalls might be blocking on an fd though, and will
ignore those signals.  You might try checking out /proc/1694/stack
and seeing where it's stuck.  Much of the time it'll be doing sometihng
like a read() on a network socket.  You could then exclude those
by specifiying just a specific network protocol with -P, or if you're
running current git, you can exclude sockets entirely with
--disable-fds=sockets

	Dave

Re: [child0:1694] <timed out>

[Toralf Förster]

On 08/15/2014 12:27 AM, Dave Jones wrote:
> On Thu, Aug 14, 2014 at 07:17:48PM +0200, Toralf Förster wrote:
>  > With latest git tree I do get now a lot of lines like :
>  > 
>  > [child0:1694] <timed out>
>  > [child0:1694] <timed out>
>  > [child0:1694] <timed out>
>  > [child1:1695] <timed out>
>  > [child0:1694] <timed out>
>  > [child0:1694] <timed out>
>  > [child1:1695] <timed out>
>  > 
>  > for a command like this: MALLOC_CHECK_=2 trinity -C 2 -N 100000 -x mremap -q -V /tmp/victims/v1/v2
>  > 
>  > It is intended ?
> 
> It's not a new thing (at least from Trinity's perspective).
> If a syscall takes more than a second to complete, we send it a kill
> signal.  Some syscalls might be blocking on an fd though, and will
> ignore those signals.  You might try checking out /proc/1694/stack
> and seeing where it's stuck.  Much of the time it'll be doing sometihng
> like a read() on a network socket.  You could then exclude those
> by specifiying just a specific network protocol with -P, or if you're
> running current git, you can exclude sockets entirely with
> --disable-fds=sockets
> 
> 	Dave
> 
> 
/me wonders if dfdb9560d brought this message to my eyes ?

Well for the stack trace feature I've to wait till it is implemented - Richard Weinberger told me that there#S a guy just doing it.

But thx for the "--disable-fds=sockets" hint - will play with it.
-- 
Toralf

Re: [child0:1694] <timed out>

[Dave Jones]

On Fri, Aug 15, 2014 at 08:02:01PM +0200, Toralf Förster wrote:

 > >  > With latest git tree I do get now a lot of lines like :
 > >  > 
 > >  > [child0:1694] <timed out>
 > > 
 > /me wonders if dfdb9560d brought this message to my eyes ?

ah, yes, quite likely.  I need to go over a lot of that loglevel code
again at some point, there are a few problems with it. Kinda low down
on my list right now,  but I'll get to it before the next tarball
release.

 > Well for the stack trace feature I've to wait till it is implemented - Richard Weinberger told me that there#S a guy just doing it.

Bah, I thought this was ubiquitous by now..

	Dave