Kaustubh Deorukhkar | 23 Jun 12:34 2015
Picon

libevent HTTP support feature list

Hello,

I am new to libevent and would like to know how is the support for HTTP protocol. I am evaluating it for a http server and would help if you all can share experience with using libevent HTTP in prod.

- Does it support full HTTP/1.1 ?
- HTTP pipe-lining (found some posts about issues with pipe-lining on keep alive, is it fixed and stable?)
- Expect 100 support for managing requests
- Do we have a feature list of what all is supported?

Will be very helpful if someone can share or point me to docs if any?

Thanks in advance,
Kaustubh
Goetz T. Fischer | 14 Jun 17:57 2015
Picon

echo server, close after reply

hi,

this is probably trivial but i couldn't find a way of getting it done.

using the always popular echo server example from the docs i just want the 
connection to close after sending the "echo". BEV_OPT_CLOSE_ON_FREE is set 
already so i'd just add bufferevent_free(bev) after evbuffer_add_buffer(output, 
input). however as you probably have guessed already no reply is sent then at 
all.
i don't seem to be the only one wondering about this. i found two other guys 
asking the same here

http://www.codedisqus.com/CzVjVXqXkX/how-to-close-socket-after-writing-in-libevent-with-bufferevents.html 
and here

http://stackoverflow.com/questions/15995659/libevent-writes-to-the-socket-only-after-second-buffer-write. 
both however without a reply.

so my simple question is: how can i send the reply and then close the 
connection?

any hint is welcome and thanks in advance!

--
R-A-C
Götz T. Fischer CertIT&Comp
+49(0)7225/98 98 79
g.fischer <at> r-a-c.de
r-a-c.de
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Tomer Heber | 5 Jun 22:46 2015

Infinite Loop in libevent.

Hi,


I've been using libevent (2.0.21) for some time now. I have encountered a very rare and strange issue on one of our production environments.

The machine was at 100% cpu, and had been caught on some kind of infinite loop. Using GDB I traced it to libevent.


Just to clarify, I verified with tcpdump that the machine was not under a DDOS attack.


strace showed a constant call to "gettimeofday" (or one of it's equivalent), and a failure due to too many open file descriptors.


I was able to obtain the following from gdb

#0  0x00007fd495cbf2d3 in vfprintf () from /lib64/libc.so.6

#1  0x00007fd495d7aaa0 in __vsnprintf_chk () from /lib64/libc.so.6

#2  0x00007fd4969d71c2 in vsnprintf (buf=0x7fd48abfc468 ": Too many open files", buflen=1000, format=<value optimized out>, ap=<value optimized out>) at /usr/include/bits/stdio2.h:78

#3  evutil_vsnprintf (buf=0x7fd48abfc468 ": Too many open files", buflen=1000, format=<value optimized out>, ap=<value optimized out>) at evutil.c:1577

#4  0x00007fd4969d7263 in evutil_snprintf (buf=<value optimized out>, buflen=<value optimized out>, format=<value optimized out>) at evutil.c:1554

#5  0x00007fd4969d623d in _warn_helper (severity=2, errstr=0x7fd495dd0d70 "Too many open files", fmt=<value optimized out>, ap=<value optimized out>) at log.c:183

#6  0x00007fd4969d6634 in event_sock_warn (sock=<value optimized out>, fmt=0x7fd4969ee50b "Error from accept() call") at log.c:124

#7  0x00007fd4969d365c in listener_read_cb (fd=41, what=<value optimized out>, p=0x7fd460004dc0) at listener.c:441

#8  0x00007fd4969c8f8c in event_process_active_single_queue (base=0x1046480, flags=0) at event.c:1350

#9  event_process_active (base=0x1046480, flags=0) at event.c:1420

#10 event_base_loop (base=0x1046480, flags=0) at event.c:1621


Since it was a production environment there was little more I could in do. In the end GDB crashed the process (or the OS?).


Any ideas?


10x,

Tomer.


René Berber | 31 May 22:03 2015

Source packages weirdness; probably a real problem

Hi,

Something weird is going on with libevent source packages:

* Their gpg signatures check, they have always check.
* I'm using MXE which also verifies a (sha1) checksum:
 + Version 2.0.22, downloaded about a week ago, had the checksum of what
2.0.21 has now... that shouldn't happen.
 + Version 2.0.21 currently has a different checksum to what it had
originally, about a year ago... that also shouldn't happen.
* Using those versions results in part of my app not working, the part
that uses libevent to set up a http/RPC server... this proves that at
least version 2.0.21 is not what it was originally (i.e. I've used it
many times over the last year to build my app, and it worked fine).

Any ideas?

I haven't tried to find what the problem is, but from my point of view,
it looks like a security break at your end, and a result that I cannot
trust on my end (not only that it doesn't work, but I can't be sure is
not doing something else).
--

-- 
René Berber

Attachment (smime.p7s): application/pkcs7-signature, 5069 bytes
liu lily | 28 May 01:09 2015
Picon

about libevent versions

Hi, all:

         I made a piece of software with libevent a long time ago, but now I forget the library version I used. N.ow I want to modify the source code and re-compile it I used ldd  over the executable to check the version, and it shows:

         libevent-1.4.so.2

so, which version should I install?
thanks!
Alexey Simak | 13 May 16:32 2015
Picon

Bug in win32_dispatch?

Hi,

We are using libevent in the next scenario:

1) Create nonblocking socket.
2) Call "connect()" on it.
3) Create an event for socket and wait in event_base_dispatch() for socket 
events.
4) Check for EV_TIMEOUT, EV_READ or EV_WRITE passed to callback.

There is a problem on win32:

When we are connecting to a destination that is not listening on the socket, 
we receive
EV_WRITE event, which is not correct from my point of view.

The problem is in win32_dispatch from win32select.c:

    res = select(fd_count,
             (struct fd_set*)win32op->readset_out,
             (struct fd_set*)win32op->writeset_out,
             (struct fd_set*)win32op->exset_out, tv);

    EVBASE_ACQUIRE_LOCK(base, th_base_lock);

    event_debug(("%s: select returned %d", __func__, res));

    if (res <= 0) {
        return res;
    }

    if (win32op->readset_out->fd_count) {
        i = rand() % win32op->readset_out->fd_count;
        for (j=0; j<win32op->readset_out->fd_count; ++j) {
            if (++i >= win32op->readset_out->fd_count)
                i = 0;
            s = win32op->readset_out->fd_array[i];
            evmap_io_active(base, s, EV_READ);
        }
    }
    if (win32op->exset_out->fd_count) {
        i = rand() % win32op->exset_out->fd_count;
        for (j=0; j<win32op->exset_out->fd_count; ++j) {
            if (++i >= win32op->exset_out->fd_count)
                i = 0;
            s = win32op->exset_out->fd_array[i];
            evmap_io_active(base, s, EV_WRITE);
        }
    }
    if (win32op->writeset_out->fd_count) {
        SOCKET s;
        i = rand() % win32op->writeset_out->fd_count;
        for (j=0; j<win32op->writeset_out->fd_count; ++j) {
            if (++i >= win32op->writeset_out->fd_count)
                i = 0;
            s = win32op->writeset_out->fd_array[i];
            evmap_io_active(base, s, EV_WRITE);
        }
    }
    return (0);

As you see, EV_WRITE is returned if there is some socket error.

Is this behaviour a bug or "as designed"?

Thanks,
Alexey Simak 

***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Mark Ellzey | 12 May 20:22 2015
Picon

The state of cmake & libevent


As you may or may have not noticed, libevent-2.1 introduced cmake build
support. You may have also noticed that it isn't 100% compat with the
output of autotools

CMake is a step in the right direction, and I'm personally a huge fan,
but unfortunately the current state of the CMake system in libevent is 
complex, and obviously unfinished.

Over the next few weeks (on and off) I will be rewriting the CMake system to match
100% with autotools, and makes a bit more sense.

So in the mean time, it would probably be for the best if developers
avoid building with cmake, you know, for our future sanity!

Cheers!

Mark
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Nick Mathewson | 6 May 14:59 2015
Picon

Adding Mark Ellzey as a Libevent maintainer

Hi, all!

As you've noticed, I've been pretty slow with Libevent development
lately, due to the pace of my day job at Tor.  So I'm asking Mark
Ellzey, longtime contributor and libevhtp guy, to step in as another
maintainer.  I've given him commit and admin access to the various
repositories; let's see how it goes.  Welcome, Mark!

I'm not stepping down, and I hope that having another maintainer
actually makes it so I can spend *more* time on Libevent, by having
somebody to help me focus.

Top priority for a while is probably going to be getting 2.1 out the door.

"Soon I Hope."

peace,
--

-- 
Nick Mathewson
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Macrux | 23 Apr 16:32 2015
Picon

libevent 1.4.x compile error on windows 7/8

Hi there,

I'm trying to build libevent 1.4.x  stable release on windows, using these steps:

  • From there, extract the libevent source to the location of your choice. Make note of this location, as you will need it later.
  • Open the Visual Studio Command Prompt (or execute the appropriate VCVARSALL.bat for your required environment in a terminal).
  • Navigate to the location where you extracted the libevent source, then execute the following commands: nmake /F Makefile.nmake
But I'm running on this error:
Note: I'm using MS Visual Studio 10 on Windows 7x64

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
C:\libevent-1.4.14b-stable>nmake /F Makefile.nmake

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c WIN32-Code\win32.c
win32.c
WIN32-Code\win32.c(150) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c event.c buffer.c evbuffer.c log.c evutil.c strlcpy.c signal.c
event.c
buffer.c
buffer.c(203) : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data
buffer.c(320) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data
buffer.c(321) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data
buffer.c(460) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
buffer.c(502) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evbuffer.c
evbuffer.c(111) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
log.c
evutil.c
evutil.c(98) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possibleloss of data
evutil.c(111) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
evutil.c(125) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
strlcpy.c
signal.c
Generating Code...
        lib /nologo event.obj buffer.obj evbuffer.obj  log.obj evutil.obj  strlc py.obj signal.obj win32.obj /out:libevent_core.lib
        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c event_tagging.c http.c evdns.c evrpc.c
event_tagging.c
event_tagging.c(149) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
event_tagging.c(204) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(211) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(223) : warning C4267: 'function' : conversion from 'size_t' to ' unsigned int', possible loss of data
event_tagging.c(231) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
http.c
http.c(102) : warning C4005: 'NI_NUMERICHOST' : macro redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(953) : see previous definition of 'NI_NUMERICHOST'
http.c(103) : warning C4005: 'NI_NUMERICSERV' : macro redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(955) : see previous definition of 'NI_NUMERICSERV'
http.c(145) : error C2011: 'addrinfo' : 'struct' type redefinition
        C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ws2def.h(841) : see declaration of 'addrinfo'
http.c(278) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
http.c(283) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
http.c(554) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(800) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(899) : warning C4018: '>=' : signed/unsigned mismatch
http.c(934) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
http.c(2284) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
http.c(2739) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
http.c(2762) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
http.c(2852) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c
evdns.c(1000) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(1223) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(1402) : warning C4244: 'initializing' : conversion from '__int64' to 'const unsigned int', possible loss of data
evdns.c(1409) : warning C4244: '+=' : conversion from '__int64' to 'off_t', possible loss of data
evdns.c(1413) : warning C4244: 'initializing' : conversion from '__int64' to 'const unsigned int', possible loss of data
evdns.c(1420) : warning C4244: '+=' : conversion from '__int64' to 'off_t', possible loss of data
evdns.c(1657) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1676) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1688) : warning C4267: 'function' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(1736) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(2133) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
evdns.c(2239) : warning C4267: 'initializing' : conversion from 'size_t' to 'const int', possible loss of data
evdns.c(2435) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
evdns.c(2494) : warning C4267: 'initializing' : conversion from 'size_t' to 'const int', possible loss of data
evrpc.c
evrpc.c(196) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
Generating Code...
NMAKE : fatal error U1077: 'C:\msvisualstudio\VC\BIN\amd64\cl.EXE' : return code '0x2'
Stop.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Right now I'm stucked since I need to build the libevent to be used in other project build. I will really appreciate any help you could give me.

Thanks in advance,

Néstor.


Pradosh Mohapatra | 19 Apr 07:24 2015
Picon

libevent 2.0.22-stable - infinite loop

Hi guys,

My code is getting into an infinite loop while using the http client APIs with retries, when the server is unreachable.

The http client block is simple:

  http_conn_ = evhttp_connection_base_new(evq_, NULL, server_, http_port_);

  evhttp_connection_set_timeout(http_conn_, 3);
  evhttp_connection_set_retries(http_conn_, 3);

  evhttp_make_request(http_conn_, req, type, api);

The signature of the loop has been reported before (e.g.
http://archives.seul.org/libevent/users/Mar-2012/msg00000.html), i.e. in this block:

  while ((ev = min_heap_top(&base->timeheap))) {
    if (evutil_timercmp(&ev->ev_timeout, &now, >))
      break;

    /* delete this event from the I/O queues */
    event_del_internal(ev);

    event_debug(("timeout_process: call %p",
                 ev->ev_callback));
    event_active_nolock(ev, EV_TIMEOUT, 1);
  }

with the 'ev' being the retry_ev with evhttp_connection_retry() callback.

Looking at http.c, the following snippet looked a bit suspicious:

static void
evhttp_connection_cb_cleanup(struct evhttp_connection *evcon)
{
  struct evcon_requestq requests;

  if (evcon->retry_max < 0 || evcon->retry_cnt < evcon->retry_max) {
    evtimer_assign(&evcon->retry_ev, evcon->base, evhttp_connection_retry, evcon);
    /* XXXX handle failure from evhttp_add_event */
    evhttp_add_event(&evcon->retry_ev,
                     MIN(3600, 2 << evcon->retry_cnt),
                     HTTP_CONNECT_TIMEOUT);
    evcon->retry_cnt++;
    return;
  }
  <snip>
}

Before calling evtimer_assign() etc., shouldn't this be checking if retry_ev is added/active/pending?

Doing the same experiment without setting retries works fine, of course.

Any guidance on how to debug this?

Thanks,
- Pradosh
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Maciej Szeptuch | 31 Mar 14:06 2015

evbuffer_write with empty buffer

Hi,

I have a question about evbuffer_write.
I couldn't find it anywhere, but am I required to check if buffer is
not empty before calling evbuffer_write or it returning -1 (and not
setting errno!) in this situation is a bug?

Thanks,
Maciej Szeptuch
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.


Gmane