Received: by 10.58.246.37 with SMTP id xt5mr4104590vec.13.1352577125024;
        Sat, 10 Nov 2012 11:52:05 -0800 (PST)
X-BeenThere: libuv@googlegroups.com
Received: by 10.52.26.41 with SMTP id i9ls6001797vdg.2.gmail; Sat, 10 Nov 2012
 11:52:04 -0800 (PST)
Received: by 10.52.72.133 with SMTP id d5mr2948487vdv.16.1352577124678;
        Sat, 10 Nov 2012 11:52:04 -0800 (PST)
Date: Sat, 10 Nov 2012 11:52:04 -0800 (PST)
From: Dhruv Matani <dhruvb...@gmail.com>
To: libuv@googlegroups.com
Message-Id: <cbfd7564-59c0-4635-960a-ca7c5e1bd7ab@googlegroups.com>
In-Reply-To: <CAHQurc_0eEkmvK+XJ0c-qUb9khc9Pk1+9=dpFcrLCd33Yu6bOw@mail.gmail.com>
References: <89236609-8120-4a7b-8f6b-fe447283f388@googlegroups.com>
 <CAHQurc-iigrWJEGiDb7Bsdyt183Hp_h5NpKfGVPuU05SYnWABQ@mail.gmail.com>
 <243ab147-b0c0-4749-a115-5073846f42b0@googlegroups.com>
 <CAHQurc_0eEkmvK+XJ0c-qUb9khc9Pk1+9=dpFcrLCd33Yu6bOw@mail.gmail.com>
Subject: Re: [libuv] How to correctly & efficiently handle http/1.1 style
 pipelines requests using libuv & http-parser?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_272_28132049.1352577124134"

------=_Part_272_28132049.1352577124134
Content-Type: multipart/alternative; 
	boundary="----=_Part_273_33410074.1352577124135"

------=_Part_273_33410074.1352577124135
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

> 

> > but it never fails under normal operation. This happens when I kill a 
> busy 
> > client. 
> > Should I ignore that signal at the application level? 
>
> Yes. 
>

okay.
 

>
> > 2. Every time I unpause the http-parser, the data field is set to 
> garbage, 
> > and I need to reset it to the right value - is this expected? 
>
> http_parser_pause() doesn't touch the data field.  It sounds like 
> there's some memory corruption in your application. 
>

I'm running it under gdb with a watch set on the memory location 
parser->data. This what gdb says:

http message parsed
Hardware watchpoint 5: *0x80a0c10

Old value = 134876000
New value = 2173
http_parser_pause (parser=0x80a0bf8, paused=1) at http_parser.c:2177
2177 }

The old value actually was 134876000, and somehow it is being set to 2173.

Finally traced it down to the fact that the object (http_parser_g.o) was 
compiled with the debug flag ON and the rest of the app (struct 
http_parser) was compiled w/o it, which is probably why the SET_ERRNO() 
macro is setting error_lineno to the current line, which happens to be the 
data field in the non-debug version.

Crazy! Do you see any way to detect this? Probably a runtime magic value 
field that is set to different constants in production on debug mode.

Regards,
-Dhruv.

 

>
> > Thanks for clearing up a lot of the confusion! 
> > 
> > -Dhruv. 
>

------=_Part_273_33410074.1352577124135
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

&gt;&nbsp;<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; but it neve=
r fails under normal operation. This happens when I kill a busy
<br>&gt; client.
<br>&gt; Should I ignore that signal at the application level?
<br>
<br>Yes.
<br></blockquote><div><br></div><div>okay.</div><div>&nbsp;<br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; 2. Every time I unpause the http-parser, the data field is set to =
garbage,
<br>&gt; and I need to reset it to the right value - is this expected?
<br>
<br>http_parser_pause() doesn't touch the data field. &nbsp;It sounds like
<br>there's some memory corruption in your application.
<br></blockquote><div><br></div><div>I'm running it under gdb with a watch =
set on the memory location parser-&gt;data. This what gdb says:</div><div><=
br></div><div><div>http message parsed</div><div>Hardware watchpoint 5: *0x=
80a0c10</div><div><br></div><div>Old value =3D 134876000</div><div>New valu=
e =3D 2173</div><div>http_parser_pause (parser=3D0x80a0bf8, paused=3D1) at =
http_parser.c:2177</div><div>2177<span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre">=09</span>}</div></div><div><br></div><div>The old value act=
ually was&nbsp;134876000, and somehow it is being set to 2173.</div><div><b=
r></div><div>Finally traced it down to the fact that the object (http_parse=
r_g.o) was compiled with the debug flag ON and the rest of the app (struct =
http_parser) was compiled w/o it, which is probably why the SET_ERRNO() mac=
ro is setting error_lineno to the current line, which happens to be the dat=
a field in the non-debug version.</div><div><br></div><div>Crazy! Do you se=
e any way to detect this? Probably a runtime magic value field that is set =
to different constants in production on debug mode.</div><div><br></div><di=
v>Regards,</div><div>-Dhruv.<br></div><div><br></div><div>&nbsp;<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Thanks for clearing up a lot of the confusion!
<br>&gt;
<br>&gt; -Dhruv.
<br></blockquote>
------=_Part_273_33410074.1352577124135--

------=_Part_272_28132049.1352577124134--