experiencing infinite loop in net.js list.callback at line 141 - nodejs

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion experiencing infinite loop in net.js list.callback at line 141
Received-SPF: pass (google.com: domain of coldredle...@gmail.com designates 209.85.214.52 as permitted sender) client-ip=209.85.214.52;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=CwS7KwvVwfHZS5DK5ywAFn3rZTN86NIRRBiMU1wAhq+heJK6vgiYlqAic0vHDEIfxn
         pq4O1cHWimnmkIWEEDX4ZpuxdfpwmRDLYP/oOlT50nEHhLYLG2oGHuQoCHQsxhIjwxy5
         IAzCllpW10C3kzxWsPfHLmIJsBOvBlrkoplkg=
MIME-Version: 1.0
Sender: coldredle...@gmail.com
In-Reply-To: <0a2c1cbf-8165-4a51-8fb8-99c96a7f9...@u13g2000prd.googlegroups.com>
References: <0a2c1cbf-8165-4a51-8fb8-99c96a7f9...@u13g2000prd.googlegroups.com>
Date: Wed, 26 Jan 2011 14:26:55 -0800
Message-ID: <AANLkTinRM4PzE2bQDcCoWgdCh70mxztefYSMOAzbg...@mail.gmail.com>
Subject: Re: [nodejs] experiencing infinite loop in net.js list.callback at
 line 141
From: Ryan Dahl <r...@tinyclouds.org>
To: nodejs@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 26, 2011 at 11:28 AM, Woody Anderson
<woody.ander...@gmail.com> wrote:
> My app runs for a while, i have 200 client connection objects that
> each have a 10 sec timeout, at some point the application goes
> completely unresponsive and cpu spikes.
> I attached the debugger and have found that the inner 'timeout' object
> defined in net.js defines a callback which loops through a linked list
> of sockets and either delivers a timeou
list.count_nodes =3D function() {
   var c =3D 0, end =3D this._idlePrev, n =3D this._idlePrev, t =3D
end._idleNext;
   var ids =3D [];
   ids.push(n._x_client_id || 'LIST');
   while( n._idlePrev !=3D end && n._idlePrev !=3D this ) {
       ++c;
       ids.push(n._idlePrev._x_client_id || 'LIST');
       n =3D n._idlePrev;
       if( c > 10000 ) {
           sys.puts(c + ': aborted scan: ' + c + ' ' +
JSON.stringify(ids));
           return -c;
       }
   }
   sys.puts(c + ': hit loop: ' + c + ' ' + JSON.stringify(ids));
   return c;
}
t event and removes the socket
> from the list or (if the socket was active) exits the loop.
>
> What i'm seeing is that the list is not shortened by the
> remove(socket) method. By inspection it seems that the _idleNext
> member of each socket points directly to the timer object (when i
> attach to a working process, only the first element has this
> characteristic, in general it seems to be a dual-linked-list). This
> basically breaks the dual-link-list aspect of the list, and as such
> the length of the list seems unchanged when determined using the
> following code. Note that the first element does change, but it simply
> loops over the same set of elements over and over.
>
> I wrote a quick/dirty loop scanner based on a rather uninformed
> interpretation of what the timeout lists are supposed to look like
> when they are well formed, i then defined that in the debugger and
> used it to inspect the list as the loop progresses etc.
>
> Important information about what my callbacks do when handling the
> timeout event, which may be against some unknown to me rules of
> behavior for handling timeouts.
>
> when the client's socket times out, i destroy the client and then i
> emit an error using the client event emitter to hook some application
> bookeeping.
>
> =C2=A0request.connection._x_to =3D function() {
> =C2=A0client.destroy();
> =C2=A0client.emit('error', 'timeout');
> =C2=A0};
>
> I'm wondering if it's potentially a problem that an event is emitted
> inside an event handler.. but either way i'm having a hard time
> figuring out how the linked list gets so corrupted that it causes an
> infinite loop by virtue of remove(socket) not being effective.
>
> I'm quite concerned about this inf loop scenario, as It's not
> predictable, but does occur a lot when the remote server is slow to
> respond to my application.
> Thoughts? anyone else run across this issue? this is using node 2.1,
> though the timeout is unchanged in 2.5.
> -w
>
>
> here's the code i used to count and show the client sockets in the
> debugger (all of which my app has elsewhere tagged with _x_client_id
> to help me debug):
> list.count_nodes =3D function() {
> =C2=A0 =C2=A0var c =3D 0, end =3D this._idlePrev, n =3D this._idlePrev, t=
 =3D
> end._idleNext;
> =C2=A0 =C2=A0var ids =3D [];
> =C2=A0 =C2=A0ids.push(n._x_client_id || 'LIST');
> =C2=A0 =C2=A0while( n._idlePrev !=3D end && n._idlePrev !=3D this ) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0++c;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0ids.push(n._idlePrev._x_client_id || 'LIST');
> =C2=A0 =C2=A0 =C2=A0 =C2=A0n =3D n._idlePrev;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if( c > 10000 ) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sys.puts(c + ': aborted scan: ' =
+ c + ' ' +
> JSON.stringify(ids));
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -c;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> =C2=A0 =C2=A0}
> =C2=A0 =C2=A0sys.puts(c + ': hit loop: ' + c + ' ' + JSON.stringify(ids))=
;
> =C2=A0 =C2=A0return c;
> }

Is it possible to run this on v0.3.6? There have been significant
changes to this code - the link list is now a separate module and
tested independently.

Ryan
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
