Haiping Zhao | 4 Sep 08:40 2009

evhttp chunked response bug?

Hi, there,

I'm reading evhttp's source code, and I'm not sure if I've found a bug, or I
just mis-read it. But it seems to me, when I do chunked encoding on
response, I'd call three functions sequentially somehow,

evhttp_send_reply_start(req, ...);
evhttp_send_reply_chunk(req, ...);
evhttp_send_reply_end(req, ...);

Here's the problem, if any of the 1st two fails to send some packets, i.e.,
evbuffer_write() returned -1 or 0, it will call evhttp_connection_fail(),
which will free the request eventually if connection needs to be closed by
evhttp_connection_free().

Now, how does my subsequent call know "req" is freed? Wouldn't that cause
crashes, if I simply call those 3 functions in a row? Or did I miss some
correct way of calling them?

Thanks.

-Haiping
Emmanuel Oga | 4 Sep 08:57 2009
Picon

Bibliography for event loops?

Hi,

I've been looking forward learning how I can take benefit from an
event loop to enhance servers.
Though there are lots of books covering things like process forking
and multi threading, I could not find anything about event loops in
any book.

Do you have any book suggestion or documents you think are interesting
about libevent or event loops in general?

Thanks
Haiping Zhao | 4 Sep 23:44 2009

Re: evhttp chunked response bug?

If this turned out to be a real bug, I made a change that might help:

[hzhao <at> dev066 libevent-1.4.11-stable]$ svn diff
Index: http.c
===================================================================
--- http.c      (revision 184899)
+++ http.c      (working copy)
 <at>  <at>  -1976,6 +1976,8  <at>  <at> 
 evhttp_send_reply_start(struct evhttp_request *req, int code,
     const char *reason)
 {
+  req->referenced = 1;
+
        evhttp_response_code(req, code, reason);
        if (req->major == 1 && req->minor == 1) {
                /* use chunked encoding for HTTP/1.1 */
 <at>  <at>  -1990,6 +1992,8  <at>  <at> 
 void
 evhttp_send_reply_chunk(struct evhttp_request *req, struct evbuffer
*databuf)
 {
+  if (req->referenced < 0) return;
+
        if (req->chunked) {
                evbuffer_add_printf(req->evcon->output_buffer, "%x\r\n",
                                    (unsigned)EVBUFFER_LENGTH(databuf));
 <at>  <at>  -2004,6 +2008,12  <at>  <at> 
 void
 evhttp_send_reply_end(struct evhttp_request *req)
 {
(Continue reading)

q6Yr7e0o nIJDVMjC | 5 Sep 00:19 2009

Re: evhttp chunked response bug?

Shouldn't you call evhttp_send_reply_end in the callback of
evhttp_send_reply_chunk which is only called if the sending succeeded?

On 9/4/09, Haiping Zhao <hzhao <at> facebook.com> wrote:
> Hi, there,
>
> I'm reading evhttp's source code, and I'm not sure if I've found a bug, or I
> just mis-read it. But it seems to me, when I do chunked encoding on
> response, I'd call three functions sequentially somehow,
>
> evhttp_send_reply_start(req, ...);
> evhttp_send_reply_chunk(req, ...);
> evhttp_send_reply_end(req, ...);
>
> Here's the problem, if any of the 1st two fails to send some packets, i.e.,
> evbuffer_write() returned -1 or 0, it will call evhttp_connection_fail(),
> which will free the request eventually if connection needs to be closed by
> evhttp_connection_free().
>
> Now, how does my subsequent call know "req" is freed? Wouldn't that cause
> crashes, if I simply call those 3 functions in a row? Or did I miss some
> correct way of calling them?
>
> Thanks.
>
> -Haiping
>
> _______________________________________________
> Libevent-users mailing list
> Libevent-users <at> monkey.org
(Continue reading)

Haiping Zhao | 5 Sep 00:20 2009

Re: evhttp chunked response bug?

Hmm, that should help. I have several send_reply_chunk() though. Are you suggesting they should form nested callback chains?

-Haiping


On 9/4/09 3:19 PM, "q6Yr7e0o nIJDVMjC" <u9oqcd4p <at> googlemail.com> wrote:

Shouldn't you call evhttp_send_reply_end in the callback of
evhttp_send_reply_chunk which is only called if the sending succeeded?




On 9/4/09, Haiping Zhao <hzhao <at> facebook.com> wrote:
> Hi, there,
>
> I'm reading evhttp's source code, and I'm not sure if I've found a bug, or I
> just mis-read it. But it seems to me, when I do chunked encoding on
> response, I'd call three functions sequentially somehow,
>
> evhttp_send_reply_start(req, ...);
> evhttp_send_reply_chunk(req, ...);
> evhttp_send_reply_end(req, ...);
>
> Here's the problem, if any of the 1st two fails to send some packets, i.e.,
> evbuffer_write() returned -1 or 0, it will call evhttp_connection_fail(),
> which will free the request eventually if connection needs to be closed by
> evhttp_connection_free().
>
> Now, how does my subsequent call know "req" is freed? Wouldn't that cause
> crashes, if I simply call those 3 functions in a row? Or did I miss some
> correct way of calling them?
>
> Thanks.
>
> -Haiping
>
> _______________________________________________
> Libevent-users mailing list
> Libevent-users <at> monkey.org
> http://monkeymail.org/mailman/listinfo/libevent-users
>

_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
q6Yr7e0o nIJDVMjC | 5 Sep 02:40 2009

Re: evhttp chunked response bug?

Hi,

> Hmm, that should help. I have several send_reply_chunk() though. Are you
> suggesting they should form nested callback chains?

Afaik it's the only threadsafe way of ensuring to not call reads and
writes on already closed descriptors. Although i know it's highly
unportable i use gcc's nested functions [1] for such kind of
callbacks; it's just extremly nice to read. As long as GCC's your
compiler nested functions are great for callbacks. Just never
reference data outside the function's scope :-)

[1] http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
Gilad Benjamini | 8 Sep 23:07 2009

Empty read event

Hi,

I am using libevent-1.4.11-stable and running into a problem within the epoll code.

In epoll_dispatch, epoll_wait returns with a single event. The event has EPOLLIN set, but evread is NULL.

Apparently, since the descriptor wasn’t read, the event keeps happening over and over.

 

Any ideas ?

 

Gilad

 

_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Tommy van Leeuwen | 16 Sep 20:11 2009
Picon

epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed

Hello,

After upgrading from 2.0.2 to the latest 2.0.3 (r1431) i got this assertion.

epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed

Debug shows this:

Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: event_add: timeout
in 120 seconds, call 0x407cb3
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: event_del:
0x35956e0, callback 0x40802b
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger:
event_process_active: event: 0x35956e0, EV_READ  call 0x40802b
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: event_add: event:
0x4c81b40,  EV_WRITE EV_TIMEOUT call 0x407a60
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: event_add: timeout
in 60 seconds, call 0x407a60
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: timeout_next: in 0 seconds
Sep 16 20:03:19 test nnd-userproc[14824]: evlogger: epoll_dispatch:
epoll_wait reports 32

I really like to checkout the ssl support in 2.0.3 so please advice :)

Thanks,
Tommy
Nick Mathewson | 16 Sep 21:23 2009
Picon

Re: epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed

On Wed, Sep 16, 2009 at 08:11:07PM +0200, Tommy van Leeuwen wrote:
> Hello,
> 
> After upgrading from 2.0.2 to the latest 2.0.3 (r1431) i got this assertion.
> 
> epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed

Just fixed it this morning in r1432, thanks to another helpful user.
Thanks for the report!

--

-- 
Nick
Tommy van Leeuwen | 16 Sep 21:30 2009
Picon

Re: epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed

On Wed, Sep 16, 2009 at 9:23 PM, Nick Mathewson <nickm <at> freehaven.net> wrote:
> On Wed, Sep 16, 2009 at 08:11:07PM +0200, Tommy van Leeuwen wrote:
>> Hello,
>>
>> After upgrading from 2.0.2 to the latest 2.0.3 (r1431) i got this assertion.
>>
>> epoll.c:166: epoll_dispatch: Assertion `res < epollop->nevents' failed
>
> Just fixed it this morning in r1432, thanks to another helpful user.
> Thanks for the report!

Nice, thanks! :)

T.

Gmane