B.R. | 18 Aug 15:33 2014

Linking to library in other project


I am a new user here :o)

I plan on using the libevent library for the very first time in a project.
I wonder about something related to cross-compiling for Windows and Linux:

I compiled libevent with MinGW+MSYS on Windows in order to link my project against the libevent.a (static linking).
What if I want to link my project with the same library for the Linux version? I do not see any libevent.lib. Shall I use the libevent.a again? Or should I compile libevent in Linux first then use its output library, which I guess would be libevent(.dll).lib?


B. R.
Erik Fears | 9 Aug 03:53 2014

evdns_cancel_request may not fully cancel


I've run into an issue in my codebase where it appears evdns is calling 
a callback on a request that I've canceled.

This is an issue for me, because once I call evdns_cancel_request, I've 
also freed my own context associated with the request (i.e. the 
void* passed back by libevent to the callback).

If the result was always DNS_ERR_CANCEL on a cancelled request, 
this wouldn't be a problem, because I could abort. It seems that in some 
cases the result could be DNS_ERR_NONE if the callback was 
already pending

I believe this code may be to blame?

evdns_cancel_request(struct evdns_base *base, struct evdns_request *handle)

if (handle->pending_cb) {

Is this expected?


Gawen ARAB | 5 Aug 12:09 2014

Libevent 2.1 release ?

Hey guys,

Sorry if the question had been asked, I didn't find the info in this mailing-list.

I was wondering what was missing to have a 2.1 beta or 2.1 stable ? What are the events you think is required before triggering the release ?



Yang Gao | 16 Jul 23:46 2014

Race condition on event_debug_mode_too_late.


In one of our tests, we saw a race condition on event_debug_mode_too_late. We are using 2.0.21 stable.

In the test, one thread has on top of the stack
#0  event_assign
#1  event_new
#2 ... omitted

and another is doing
#0  event_add_internal
#1  event_add
#2  ... omitted

Setting macro _EVENT_DISABLE_DEBUG_MODE fixes the problem. 

A google search shows this might be similar to reports here:
and here:



CJ Ess | 5 Jul 03:55 2014

libevent http post/put example, please

I believe I've Googled thoroughly and gone through everything on Github, and while I can find many step-by-step examples of handling http GETs with libevent, I can not find any good examples of how to handle a POST or PUT. The few examples I do find seem to assume that the entire request, headers and body, is in memory.

I would like to see an example of receiving a POST or PUT with a large body - larger then available memory. Does anyone have one they could post here or send to me privately?

Andre | 3 Jul 17:41 2014

Using evbuffer_add to write into a file

I have a lot of functions for serialization data. At the moment I am 
just sending these data to other sockets. But I want to save some of the 
information with the same functions for serialization in a file. So I 
thought that there is might be a chance to fopen and fwrite the data via 
libevent with it's file descriptor. I searched a lot but I found nothing 
similar to this.
I am using libevent 2.1.4.
Thanks in advance.
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Hiroaki Hata | 27 Jun 15:50 2014

output buffer length check of SSL connection


le-proxy.c sample is very helpful for me. Thanks Nick.

I'm tried to use it for SSL connections and noticed some transmitted 
packets dropped. 
In congestion control, we have to check the length of output buffer,
but when the SSL is used, the buffer of the underlay bufferevent b_out
should be checked rather than the filter event of SSL.
In the sample code, the underlay bufferevent is overwritten with b_ssl.
I cached b_out and checked the buffer length of it and set write callback
to it, then the congestion works well.
This is a just comment but I appreciate you for your detailed online manuals
and comprehensive examples.

Hiroaki Hata

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

Robin | 26 Jun 14:36 2014

Event timeout after it has been freed

I'm still investigating the issues from my other email and came across 
another thing.
This might, again, be due to memory corruption on my side - I'm hoping 
it isn't though.

I implemented a simple timer-event class which basically creates an 
event with a timeout and calls an std::function once that timeout is hit.
Every now and then I get crashes in my ping event.
The ping event is a lambda which captures the "this" pointer of my 
socket and just pings the client every 30 seconds.
The crashes are always related to the ping event having a nullptr as the 
socket pointer.
So I did some recording in gdb and came to the conclusion it gets set to 
0 in the destructor of the event class, which gets called when a socket 
Backtrace can be seen here:
Destructor just calls event_del, if the event is running, followed by an 
It rarely happens, I had to wait for that crash for about 5hours, thats 
10k connections minimum.

Could it be the event doesnt get canceled when it is pending?
Like the event "queue" could look something like this
1. Disconnect socket x
2. Socket y recieve
4. Socket x send
5. Event z timeout

"1." would cancel Event z though
(I am just guessing here since I have no idea why it's happening)

Really hope someone is able to help me out, slowly going insane..


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

Robin | 15 Jun 15:09 2014

Valgrind, evmap_io_add Invalid write of size 4


I was just debugging some crashes and memory leaks with valgrind and 
this came up:
[warn] Epoll MOD(4) on fd 61 failed.  Old events were 6; read change was 
2 (del); write change was 0 (none): Bad file descriptor
> ==10706== Invalid write of size 4
> ==10706==    at 0x5348FE6: evmap_io_add (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x5337BAA: event_add (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x5343A57: _bufferevent_add_event (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x53441DC: be_socket_enable (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x5343475: bufferevent_enable (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x806974F: net::Socket::Setup(int, sockaddr_in) 
> (Socket.cpp:77)
> ==10706==    by 0x8068A96: 
> net::Listener<net::socket::Client>::Accept(int, sockaddr_in*) 
> (Listener.hpp:85)
> ==10706==    by 0x806885A: 
> net::Listener<net::socket::Client>::SOnAccept(evconnlistener*, int, 
> sockaddr*, int, void*) (Listener.hpp:112)
> ==10706==    by 0x53462E1: listener_read_cb (in 
> /usr/lib/i386-linux-gnu/libevent-2.0.so.5.1.7)
> ==10706==    by 0x78BBD23D: ???
> ==10706==  Address 0x61d44e80 is 176 bytes inside a block of size 
> 4,056 free'd
> [...] Non libevent related stuff, some free'd memory which has nothing 
> to do with libevent

>         void Accept(evutil_socket_t fd, sockaddr_in * addr) {
>             sys_log(0, "New connection on %s:%d from %s", 
> m_bind_ip.c_str(), m_bind_port, inet_ntoa(addr->sin_addr));
>             SocketType* s = new SocketType();
>             s->SetID(m_socket_id++);
>             if (!s->Setup(fd, *addr)) {
>                 sys_err("Failed to set up socket %d", m_socket_id);
>                 delete s;
>                 return;
>             }
>             if (!OnAccept(s)) {
>                 delete s;
>                 return;
>             }
>             m_sockets.insert(std::pair<unsigned int, 
> SocketType*>(s->GetID(), s));
>         }
>         static void SOnAccept(evconnlistener *, evutil_socket_t fd, 
> struct sockaddr * addr, int socklen, void * arg) {
>             if (!arg) {
>                 sys_err("Recieved nullpointer as arg");
>                 return;
>             }
>             Listener<SocketType>* l = (Listener<SocketType>*) arg;
>             l->Accept(fd, (sockaddr_in*) addr);
>         }
The callback is registered like this:
m_listener = 
1024, (sockaddr*) & sa, sizeof (sa));

>     bool Socket::Setup(evutil_socket_t fd, sockaddr_in addr) {
>         if (m_event) {
>             sys_err("Socket already set up");
>             return false;
>         }
>         m_addr = addr;
>         m_event = 
> bufferevent_socket_new(NetworkManager::instance().GetEventBase(), fd, 
>         bufferevent_setcb(m_event, Socket::SOnRead, Socket::SOnWrite, 
> Socket::SOnEvent, this);
>         bufferevent_enable(m_event, EV_READ | EV_WRITE);
>         OnConnect();
>         return true;
>     }
Is this just a false positive or am I doing something wrong?
This doesn't happen every time there's a new connection, in fact, it 
only seems to happen once

I am running on Debian Wheezy & libevent 2.0.19

I am also getting a bunch of these type errors:
> [warn] Epoll MOD(4) on fd 68 failed.  Old events were 6; read change 
> was 2 (del); write change was 0 (none): Bad file descriptor

Usually after it hit a breakpoint or it couldn't keep up (running this 
in a single thread+valgrind, stuff gets sloow)
Am I right to assume I can just ignore it as it only seems to happen 
when running valgrind?

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

Nick Mathewson | 9 Jun 05:04 2014

Sorry -- patch review is going slowly (and how you can help)

Hi, all!

Things have been busy in my day job, so please accept my apologies for
the slow speed of getting incoming patches reviewed.  I'll try to set
aside time in June to reduce those queues as much as I can.

You can help!  If you've looked around the Libevent codebase much at
all, you could have a look through patches and bug reports at the
various trackers that people seem to be using.

There's the one I'd prefer people to use for patches:


And there's the other two:


When reviewing patches, here are some things to look for:
  * If this is a patch to libevent itself, is it tested?  Is it
correct?  (Whenever possible, changes should have tests.)
  * If this is a patch to the documentation or the sample code, does
it really improve clarity?
  * If this patch introduces any new APIs, are they well-documented,
reasonable, and relatively future-proot?
  * If this patch changes any existing APIs, will the change break any
existing correct code?  (If so, the patch must change. We don't do
this kind of API breakage.)


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

Adrian Chadd | 7 Jun 21:41 2014

libevent2 and delete-after-close with kqueue

Hi all,

I'm trying to chase down a bug with libevent2-trunk.

The TL;DR is that I have ktrace traces from FreeBSD showing that an FD
delete event is being kqueued to a kqueue FD after the FD has been
closed in that thread. It's responsible for ENOTCAPABLE showing up.
Something like EBADF just drops through; ENOTCAPABLE currently causes
the IO loop to terminate. This is with a multi-threaded server, but
there's one event base per thread and one accept FD per event base.

It _looks_ like the evhttp / bufferevent code is doing the right thing
- ie, it's deleting the events (which should delete them from the
kqueue list) before calling close(). But there's a bunch of places
that I have to actually go and check. Unfortunately "EV_DELETE"
entries are being left on the kqueue list and not removed. The only
way to know that these need to be removed is to actually call the
event deletion function from evutil.c when the socket is closed.
Teaching evutil_closesocket() would do it, but it would require an
eventbase. It also implies that a socket is only in one event base -
it's quite possible servers have an FD in multiple event bases. Ugh.

What do people think?

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