Sorry, I mean to include that.  

Here is the stack trace from node A :

#0  0x00007fbb74173de8 in vfprintf () from /lib64/
#1  0x00007fbb74177abf in buffered_vfprintf () from /lib64/
#2  0x00007fbb74172c1e in vfprintf () from /lib64/
#3  0x00007fbb7417cd87 in fprintf () from /lib64/
#4  0x0000000000400f40 in send (name=0x6 <Address 0x6 out of bounds>, 
    messenger=0x149a150, message=0x51, 
    addr=0x4000 <Address 0x4000 out of bounds>) at node.c:44
#5  0x00007fbb7450f524 in pn_send () from /lib/
#6  0x00007fbb74510883 in pn_connector_process () from /lib/
#7  0x00007fbb7450d85a in pn_messenger_tsync () from /lib/
#8  0x00007fbb7450d961 in pn_messenger_sync () from /lib/
#9  0x00007fbb7450ef6d in pn_messenger_recv () from /lib/
#10 0x0000000000401079 in recv (name=0x7fff2f9a5363 "A", messenger=0x1493970, 
    message=0x148e010, addr=0x7fff2f9a4360 "amqp://~") at node.c:88
#11 0x00000000004014e2 in main (argc=3, argv=0x7fff2f9a4888) at node.c:194

If you like I can give you access to my machine.

----- Original Message -----
From: "Rafael Schloming" <>
Sent: Tuesday, February 19, 2013 9:33:29 AM
Subject: Re: the killer node

This doesn't happen for me. I see node B loop forever and never send
anything which is what I would expect given the while (1) { sleep(...); }
you have in there. What does your debugger say about where node A crashes?


On Tue, Feb 19, 2013 at 4:40 AM, Michael Goulish <>wrote:

> Well, it looks like one of my nodes can kill the other one by doing a put.
> No errors reported by either messenger before the fatality.
> I'd like to see if someone else can confirm this result,
> and maybe see something that I am not seeing.
> compile and run scripts are provided in the directory, called "node".
> I am testing this against unpatched 0.4 RC1 code.  ( But result was same
> with
> Ken's recent patch for infinite credit. )
>   1. Two instances of one program are used.  Node A only receives,
>      Node B only sends to it.
>   2. Start node A first, with the script "r1".
>      It will go through its main loop, trying to receive
>      and timing out, for as long as you like.
>   3. Start node B, with script r2.
>      It will pause after formatting it first message, and will
>      then do a dramatic 5-second countdown.  Then it calls
>      put  ( not send! )  and node *A* dies horribly, its core
>      file spattering the hard disk.
>      Node B is unaware of the carnage it has caused, sedated
>      by a sleep loop, tragically still expecting to call send
>      and start talking to its partner, node A.
> ( see attached -- if you dare. )

Reply via email to