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.

Mark Ruys | 24 Mar 10:35 2015

How to break out libevent's dispatch loop

Posted also at http://stackoverflow.com/questions/29219314/how-to-break-out-libevents-dispatch-loop

I've implemented a tiny webserver in a separate thread using the nice libevent library. The webserver runs event_base_dispatch() to process all events. What I need is a way to break out this dispatch loop from the main thread. 

It boils down to the following C++ code:

  #include <stdlib.h>
#include <signal.h>
#include <thread>
#include <evhttp.h>

struct event_base *eb;
std::thread t;

static volatile sig_atomic_t bailout = false;

void my_signal_handler(int) {
bailout = true;
}

void onRequest(evhttp_request *req, void *) {
struct evbuffer *OutBuf = evhttp_request_get_output_buffer(req);
evbuffer_add_printf(OutBuf, "<html><body>Testing 1-2-3</body></html>");
evhttp_send_reply(req, HTTP_OK, "OK", OutBuf);
}

void dispatch() {
eb = event_base_new();
struct evhttp *http = evhttp_new(eb);
evhttp_set_gencb(http, &onRequest, NULL);
evhttp_bind_socket_with_handle(http, "0.0.0.0", 5555);
event_base_dispatch(eb);
}

int main() {

struct sigaction sigIntHandler;
sigIntHandler.sa_handler = my_signal_handler;
sigemptyset(&sigIntHandler.sa_mask);
sigIntHandler.sa_flags = 0;
sigaction(SIGINT, &sigIntHandler, NULL);

t = std::thread { &dispatch };

while ( ! bailout ) {
std::this_thread::sleep_for(std::chrono::seconds(1));
}

event_base_loopexit(eb, NULL);

t.join();
}

The behavior is that if you run the program, request a page, abort the program by Ctrl-C, the event_base_dispatch() keeps running *until* you fetch another web page. Only then the loop aborts and the program terminates. What I need is that the dispatch loop is exited immediately, not after the next page request. Is this possible?

Thanks,

Mark

Anatol Pomozov | 20 Mar 22:36 2015
Picon

http client code memory leak

Hi,

I am implementing a HTTP server application that utilizes HTTP client in its generic handler. i.e. on receiving a request it makes several requests to other servers and after it gets responses back it finalizes original request. Here is pseudo code of the generic callback:

global_base;
generic_callback() {
  url = get_user_data(req);
  for (server : remote_servers) {
     evcon = evhttp_connection_base_new(global_base, ..);
     req = evhttp_request_new(client_request_done, req, url);
     evhttp_make_request(evcon, req);
  }
}

The code works fine. I've decided to check it for memory leaks using valgrind and discovered that a lot of memory is lost in evhttp_connection_base_new(). I believe my code should cleanup the connections I've created.

I checked libevent examples and googled but I did not find how to make this cleanup properly. All examples show HTTP client with single connection created in main() function that is cleaned after event_base_dispatch() is over. But in my case I dynamically create connection and I need to clean it when it is unused. I was trying to run the evhttp_connection_free() function in client_request_done callback (the one passed to evhttp_request_new), but evhttp_request_get_connection(req) returns NULL. It means the connection object is not accessible in the callback function. Hmm... How do I expect to free the connection then?

I see version 2.1 has function evhttp_connection_free_on_completion() but it still does not help to prevent leaks in evhttp_connection_base_new().

Here is the code that I was trying to profile:
  https://github.com/anatol/pacoloco/blob/master/hub.c#L213

And here is the valgrind report ran against current HEAD (a77a82a03f85):
  https://gist.github.com/anatol/7a44648af62627da46a4

How to prevent this memory leak in the http client code?
Linus Aranha | 10 Mar 19:21 2015
Picon

Libevent-2.1.5-beta - Couple issues


Hi libevent developers,

I was not sure if we have to raise bugs for the beta version - libevent-2.1.5 so here is an email to begin. We would really appreciate a fix for issue 1 soon.

Thanks,
Linus Aranha

Issue 1)
Cleanup ordering issue in evdns_base_free_and_unlock - gives rise to invalid reads/writes

I found an issue in the code for libevent-2.1.5-beta in the cleanup function -  evdns_base_free_and_unlock.

Below is the valgrind report. It looks we end up accessing the nameserver (evdns.c:662) pointer part of the requests structure after it is cleaned up at evdns.c:4011.

The issue is not present in 2.0.21-stable.

Maybe we could just re-order the cleanup so the nameservers are cleaned up in the end? That should prevent the invalid reads and writes.

==722== Invalid read of size 4
==722==    at 0x4C4CB80: request_finished (evdns.c:662)
==722==    by 0x4C56228: evdns_base_free_and_unlock (evdns.c:4022)
==722==    by 0x4C56483: evdns_base_free (evdns.c:4062)
==722==    by 0x404A0B: dummy_function1 (file.c:xxx)
==722==    by 0x405F61: dummy_function2 (file.c:xxx)
==722==    by 0x40BDD5: dummy_function3 (file.c:xxx)
==722==    by 0x40EED2: dummy_function4 (file.c:xxx)
==722==    by 0x4C38D72: event_persist_closure (event.c:1531)
==722==    by 0x4C3905B: event_process_active_single_queue (event.c:1590)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (file.c:xxx)
==722==  Address 0x5dfa710 is 448 bytes inside a block of size 456 free'd
==722==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==722==    by 0x405AB7: dummy_free (file.c:xx)
==722==    by 0x4C3EE8F: event_mm_free_ (event.c:3462)
==722==    by 0x4C5610F: evdns_nameserver_free (evdns.c:3995)
==722==    by 0x4C56149: evdns_base_free_and_unlock (evdns.c:4011)
==722==    by 0x4C56483: evdns_base_free (evdns.c:4062)
==722==    by 0x404A0B: dummy_function1 (file.c:xxx)
==722==    by 0x405F61: dummy_function2 (file.c:xxx)
==722==    by 0x40BDD5: dummy_function3 (file.c:xxx)
==722==    by 0x40EED2: dummy_function4 (file.c:xxx)
==722==    by 0x4C38D72: event_persist_closure (event.c:1531)
==722==    by 0x4C3905B: event_process_active_single_queue (event.c:1590)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (file.c:xxx)

Issue 2)
Found memory leak

Valgrind stacktrace is below.

==722== 792 bytes in 3 blocks are definitely lost in loss record 34 of 65
==722==    at 0x4A05F80: malloc (vg_replace_malloc.c:296)
==722==    by 0x4059EA: dummy_malloc (dummy.c:xx)
==722==    by 0x4C3ED1B: event_mm_calloc_ (event.c:3403)
==722==    by 0x4C578C8: evdns_getaddrinfo (evdns.c:4649)
==722==    by 0x4047A7: dummy1 (dummy.c:xxx)
==722==    by 0x404933: dummy2 (dummy.c:xxx)
==722==    by 0x41F412: dummy3 (dummy.c:xxx)
==722==    by 0x41EEE1: dummy4 (dummy.c:xxx)
==722==    by 0x404CF8: dummy5 (dummy.c:xxx)
==722==    by 0x4C390FE: event_process_active_single_queue (event.c:1597)
==722==    by 0x4C39684: event_process_active (event.c:1689)
==722==    by 0x4C39DE0: event_base_loop (event.c:1912)
==722==    by 0x4C3970C: event_base_dispatch (event.c:1723)
==722==    by 0x404C46: main (dummy.c:xxx)
==722==


Bill Vaughan | 25 Feb 15:25 2015
Picon

assert in event_del_internal()

Hi all,

We have been seeing a fairly hard to reproduce problem with crashes inside of libevent in our overnight scale tests.  We run 15,000 clients in an  ESX environment and have been getting one or two crashes per night. We are running libevent 2.0.21 on this test system. We have moved to 2.0.22 on our development branch.

The application is relatively large and complex and it is quite possible we have a memory trampler, but valgrind tests so far are clean and code inspection hasn't found anything.

We recently ran the overnight test with libevent debugging enabled (event_enable_debug_mode(), evthread_enable_lock_debuging()) and had the following assert in the libevent debug hash table:


[err] event_del_internal: noting a del on a non-setup event 0xb56248a0 (events: 0x0, fd: -1, flags: 0x80)
=== Command detached from window (Mon Feb 23 23:13:14 2015) ===
=== Command terminated with signal 6 (core file generated) (Mon Feb 23 23:13:14 2015) ===
 

Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./vtc_app -Script-Client29-333'.
Program terminated with signal 6, Aborted.
#0  0xb775e424 in __kernel_vsyscall ()
(gdb) where
#0  0xb775e424 in __kernel_vsyscall ()
#1  0xb747a1df in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb747d825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0x0814bc31 in event_exit (errcode=-559030611) at log.c:79
#4  0x0814bd53 in event_errx (eval=-559030611,
    fmt=0x82105b0 "%s: noting a del on a non-setup event %p (events: 0x%x, fd: %d, flags: 0x%x)") at log.c:136
#5  0x0813dc07 in event_del_internal (ev=<optimized out>) at event.c:2265
#6  event_process_active_single_queue (activeq=<optimized out>, base=<optimized out>) at event.c:1324
#7  event_process_active (base=<optimized out>) at event.c:1420
#8  event_base_loop (base=0xb6a09d58, flags=2) at event.c:1621
#9  0x08073960 in VtcCommMgr::ThreadLoop (this=0xacdcc008) at vtc_app/vtc_comm_mgr.cpp:844
#10 0xb772cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#11 0xb753ad3e in clone () from /lib/i386-linux-gnu/libc.so.6


So looks like an event fired that was not in the hash table, which should only happen if the event was freed, from what I can tell. This points to a clear application bug, however, there is a bit more to the store.

Examining the libevent hash table that tracks the events, we found this:

== 667 0xb5e248f0 ==
     {node = {hte_next = 0x0}, ptr = 0x0, added = 0}
global_debug_map.hth_table[666].node.hte_next
== 668 0xb5600858 ==
     {node = {hte_next = 0x0}, ptr = 0xb5600808, added = 1}
global_debug_map.hth_table[667].node.hte_next
== 669 0xb5624950 ==
     {node = {hte_next = 0x0}, ptr = 0xb5624900, added = 1}
global_debug_map.hth_table[668].node.hte_next
== 676 0x97a5390 ==
     {node = {hte_next = 0x0}, ptr = 0x97a50a8, added = 0}
global_debug_map.hth_table[669].node.hte_next
 

Bucket 667 has an entry, but the pointer to the event is 0.  The hash entry should be deleted (mm_free()) when the event is freed, and have a valid event pointer otherwise, so the event likely was not freed. All of the other entries in the hash look good. The event that is currently being processed in the backtrace, 0xb56248a0, maps to bucket 667 based on the hash algorithm:  ((0xb56248a0 >> 6) % 769) == 667, which is our bucket. This appears to be some sort of corruption if I am understanding the hash table logic correctly.

The event base was good and our application only calls event_free() and not any of the other APIs that could free an event from the hash (event_reinit() and a couple others).

I see in the 2.0.22 release notes that a race was fixed in event_active().  Do you think that could cause this? Our next step is to move to 2.0.22 on our test system to see if the problem still happens. However, this branch of code is very close to a release, so we are very cautious about changing things without a clear cause and effect.

We have had several engineers reviewing the application code and so far have not seen any invalid libevent usages, and as I said, valgrind is clean. Clearly we are doing something wrong in the application or have found some sort of edge case within the library. And libevent 2.0.21 has been very stable as I have used it on this project and others.

The application is complicated enough that I can't easily provide code snippets that are meaningful, and since we are not sure how to reproduce the problem, I don't have any test code that can reproduce it.

All of the clients are running under Ubuntu 12.04.

Has anyone else seen anything like this?

Thanks,
-Bill



Christian Stieber | 19 Feb 10:04 2015
Picon

Do paired buffer events work?

I've been trying to use them for a while now, without much success.

I seem to be able to put data into "my" side of the pair, and it appears
on the "remote" side -- but no callbacks are called on the remote end.

    Log("WebSocket %p received %u bytes",this,(unsigned
int)TheMessage->payload_len);
    if
(bufferevent_write(MyBufferEvent,TheMessage->payload,(size_t)TheMessage->payload_len)!=0)
    {
        /* throw ... */
    }
    else
    {
        bufferevent_flush(MyBufferEvent,EV_WRITE|EV_READ,BEV_NORMAL);

        Log("MyBufferEvent has output size
%d",(int)evbuffer_get_length(bufferevent_get_output(MyBufferEvent)));
        Log("RemoteBufferEvent %p has input size %d",(struct
bufferevent*)RemoteBufferEvent,(int)evbuffer_get_length(bufferevent_get_input(RemoteBufferEvent)));

        Log("RemoteBufferEvent has reading enabled:
%s",(bufferevent_get_enabled(RemoteBufferEvent) & EV_READ) ? "yes"
: "no");

This actually gives me the expected output, such as

[2015-02-19 08:08:54] WebSocket 0x7f8f080008c0 received 4 bytes
[2015-02-19 08:08:54] MyBufferEvent has output size 0
[2015-02-19 08:08:54] RemoteBufferEvent 0x7f8f08001370 has input size 4
[2015-02-19 08:08:54] RemoteBufferEvent has reading enabled: yes

but that's it -- the callback on the remote end simply isn't called.

I can send more data to the websocket thing and it's just added to the
output buffer of the "remote" end of the pair like it should, except that
it's never used since the callbacks are never invoked.

The same applies when I run flush with a BEV_FINISHED to signal an "EOF"
-- it's not happening on the remote end.

I'm just going to try calling those callbacks myself, probably with some
testing to detect when those callbacks start working so I know to update
the code then; not currently expecting too many problems with that. The
question is whether I'm still doing something wrong, somewhere, or whether
those callbacks are only meant for "real" sockets?

I was using "2.1.4-alpha" up until a couple of hours ago; updated to
"2.1.5-beta" and ran the thing again, but it didn't seem to change
anything

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

Marco Graziano | 11 Feb 06:06 2015

deadlock in callbacks

I am running into a deadlock with both libevent 2.0 and 2.1 that I cannot explain. One thread is executing a write callback and the other thread a read callback of a different bufferevent. Since they are both accessing the same data structure passed to the callbacks (arg=0x630c40), I am using a rwlock in the data structure. I did not expect though the evbuffer internal lock to interfere with the lock used to synchronize access to the data structure shared between the callbacks.

I am including the backtraces and the relevant portions of code. I would appreciate if someone can give me any suggestion on how to work around this.

Thanks,

-Marco G.

(gdb) t 1
[Switching to thread 1 (Thread 0x7ffff7fdd780 (LWP 12008))]
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff7770672 in _L_lock_953 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff77704da in __GI___pthread_mutex_lock (mutex=0x620200) at ../nptl/pthread_mutex_lock.c:114
#3  0x00007ffff7b9686e in evbuffer_get_length (buffer=0x630930) at buffer.c:610
#4  0x000000000040494b in device_write_cb (bev=0x123f640, arg=0x630c40) at cometa.c:667
#5  0x00007ffff7ba2139 in bufferevent_trigger_nolock_ (options=0, iotype=4, bufev=0x123f640) at bufferevent-internal.h:369
#6  bufferevent_writecb (fd=<optimized out>, event=<optimized out>, arg=0x123f640) at bufferevent_sock.c:297
#7  0x00007ffff7ba7a19 in event_persist_closure (ev=<optimized out>, base=0x6218d0) at event.c:1531
#8  event_process_active_single_queue (base=base <at> entry=0x6218d0, activeq=0x621d20, max_to_process=max_to_process <at> entry=2147483647, 
    endtime=endtime <at> entry=0x0) at event.c:1590
#9  0x00007ffff7ba82cf in event_process_active (base=0x6218d0) at event.c:1689
#10 event_base_loop (base=0x6218d0, flags=0) at event.c:1912
#11 0x000000000040a700 in main () at cometa.c:1571


bufferevent 0x123f640 write callback:
665    pthread_rwlock_wrlock(&device->lock);
666    if ((device->pending && device->state == WAITING_STATE) || device->ws_pending) {
667     int l = evbuffer_get_length(device_bev);   
668     pthread_rwlock_unlock(&device->lock);
669     output = bufferevent_get_output(device->pending->bufev);
670 if (evbuffer_get_length(output) == 0) {
671 /* free and close the connection */
672 pthread_rwlock_wrlock(&device->lock);
673     free_http_connection(device->pending);
674     device->pending = NULL;
675     device->state = IDLE_STATE;
676   device->chunk_length = 0;
677     device->ntoread = -1;
678
679     evbuffer_drain (device_bev, l);
680   sem_post(&device->active);
681   pthread_rwlock_unlock(&device->lock);
682     }
683    } else {
684     pthread_rwlock_unlock(&device->lock);
685    }


(gdb) t 3
[Switching to thread 3 (Thread 0x7ffff532f700 (LWP 12013))]
(gdb) bt
#0  pthread_rwlock_wrlock () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_wrlock.S:85
#1  0x0000000000404667 in device_read_cb (bev=0x630730, arg=0x630c40) at cometa.c:604
#2  0x00007ffff7ba2324 in bufferevent_trigger_nolock_ (options=0, iotype=2, bufev=0x630730) at bufferevent-internal.h:366
#3  bufferevent_readcb (fd=34, event=<optimized out>, arg=0x630730) at bufferevent_sock.c:187
#4  0x00007ffff7ba7a19 in event_persist_closure (ev=<optimized out>, base=0x7fffe8000900) at event.c:1531
#5  event_process_active_single_queue (base=base <at> entry=0x7fffe8000900, activeq=0x7fffe8000d50, 
    max_to_process=max_to_process <at> entry=2147483647, endtime=endtime <at> entry=0x0) at event.c:1590
#6  0x00007ffff7ba82cf in event_process_active (base=0x7fffe8000900) at event.c:1689
#7  event_base_loop (base=0x7fffe8000900, flags=0) at event.c:1912
#8  0x000000000040a1ff in device_loop (arg=0x0) at cometa.c:1437
#9  0x00007ffff776e182 in start_thread (arg=0x7ffff532f700) at pthread_create.c:312
#10 0x00007ffff689700d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

bufferevent 0x630730 read call back:
604 pthread_rwlock_wrlock(&device->lock); 
605    if (device->state != WAITING_STATE) {
606    
607   device->chunk_length = 0;
608     device->ntoread = -1;
609     /* in case of state == WAITING_STATE the counters reset is done in the write callback after sending the response */
610    }
611 pthread_rwlock_unlock(&device->lock);

Marco Graziano | 10 Feb 17:32 2015

undefined reference to event_base_add_virtual in libevent 2.1

Getting a linker error using libevent 2.1:

marcog <at> marcog-VirtualBox:~/Cometa/cometa-mt/server$ make
cc -Wall -g -I./include -L/usr/local/lib -levent -o cometa cometa.o request.o http_parser.o config.o rsyslog.o response.o routes.o api.o info.o webhooks.o websockets.o -l:libevent-2.1.so.5  -l:libevent_pthreads-2.1.so.5 -lpthread -lcrypto -lm -ldl -lwebsock -lconfig -lssl -lworkqueue -lbeanstalk 
/usr/bin/ld: cometa.o: undefined reference to symbol 'event_base_add_virtual'
/usr/local/lib/libevent-2.0.so.5: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [cometa] Error 1

While everything is fine with libevent 2.0:

marcog <at> marcog-VirtualBox:~/Cometa/cometa-mt/server$ make
cc -Wall -g -I./include -L/usr/local/lib -levent -o cometa cometa.o request.o http_parser.o config.o rsyslog.o response.o routes.o api.o info.o webhooks.o websockets.o -l:libevent-2.0.so.5  -l:libevent_pthreads-2.0.so.5 -lpthread -lcrypto -lm -ldl -lwebsock -lconfig -lssl -lworkqueue -lbeanstalk 

The symbol is defined in both libraries:

 

Marco Graziano | Founder & CEO | Visible Energy, Inc. | 530 Lytton Avenue, 2nd Floor, Palo Alto, CA 94301
Tel: (650)353-7812  | Cell: (650)644-8867
Before you print this email or/ attachments, please consider the negative environmental impacts associated with printing. 

Praveen Kariyanahalli | 3 Feb 22:39 2015

Memory (heap meta-data) corruption while using buffervent_openssl apis


Client (bufferevent + openssl) crash only under load situation.  Valgrind points to this backtrace. Any help is greatly appreciated ? Please let us know if you need any more information.

Thanks
-Praveen

Version: 2.0.22

==695== Invalid write of size 8
==695==    at 0x52CF66B: evmap_io_add (evmap.c:328)
==695==    by 0x52BC638: event_add_internal (event.c:2073)
==695==    by 0x52BC150: event_add (event.c:1966)
==695==    by 0x5504678: bufferevent_openssl_new_impl (bufferevent_openssl.c:1368)
==695==    by 0x550482B: bufferevent_openssl_socket_new (bufferevent_openssl.c:1440)
==695==    by 0x43211A: tls_connect_timer_cb (my_client_peer.c:528)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 232 bytes inside a block of size 608 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x52BE3F7: event_mm_free_ (event.c:2696)
==695==    by 0x52C878B: _bufferevent_decref_and_unlock (bufferevent.c:650)
==695==    by 0x52C8874: bufferevent_free (bufferevent.c:681)
==695==    by 0x435747: my_client_peer_delete (my_client_peer.c:1257)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x55034A0: consider_writing (bufferevent_openssl.c:881)
==695==    by 0x5503D41: be_openssl_outbuf_cb (bufferevent_openssl.c:1119)
==695==    by 0x52C0B58: evbuffer_run_callbacks (buffer.c:486)
==695==    by 0x52C0C51: evbuffer_invoke_callbacks (buffer.c:508)
==695==    by 0x52C61AD: evbuffer_add_reference (buffer.c:2718)
==695==    by 0x41EF6E: my_client_pkt_send (my_client_msg.c:75)
==695==    by 0x445807: my_client_tunn_event_cb (my_client_tun_intf.c:157)
==695==    by 0x52BA162: event_persist_closure (event.c:1301)
==695==    by 0x52BA271: event_process_active_single_queue (event.c:1345)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 232 bytes inside a block of size 608 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x52BE3F7: event_mm_free_ (event.c:2696)
==695==    by 0x52C878B: _bufferevent_decref_and_unlock (bufferevent.c:650)
==695==    by 0x52C8874: bufferevent_free (bufferevent.c:681)
==695==    by 0x435747: my_client_peer_delete (my_client_peer.c:1257)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x550260C: stop_reading (bufferevent_openssl.c:422)
==695==    by 0x55028CE: conn_closed (bufferevent_openssl.c:528)
==695==    by 0x5502F56: do_write (bufferevent_openssl.c:694)
==695==    by 0x55033ED: consider_writing (bufferevent_openssl.c:874)
==695==    by 0x5503D41: be_openssl_outbuf_cb (bufferevent_openssl.c:1119)
==695==    by 0x52C0B58: evbuffer_run_callbacks (buffer.c:486)
==695==    by 0x52C0C51: evbuffer_invoke_callbacks (buffer.c:508)
==695==    by 0x52C61AD: evbuffer_add_reference (buffer.c:2718)
==695==    by 0x41EF6E: my_client_pkt_send (my_client_msg.c:75)
==695==    by 0x445807: my_client_tunn_event_cb (my_client_tun_intf.c:157)
==695==    by 0x52BA162: event_persist_closure (event.c:1301)
==695==    by 0x52BA271: event_process_active_single_queue (event.c:1345)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 232 bytes inside a block of size 608 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x52BE3F7: event_mm_free_ (event.c:2696)
==695==    by 0x52C878B: _bufferevent_decref_and_unlock (bufferevent.c:650)
==695==    by 0x52C8874: bufferevent_free (bufferevent.c:681)
==695==    by 0x435747: my_client_peer_delete (my_client_peer.c:1257)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x5502659: stop_writing (bufferevent_openssl.c:435)
==695==    by 0x55028DA: conn_closed (bufferevent_openssl.c:529)
==695==    by 0x5502F56: do_write (bufferevent_openssl.c:694)
==695==    by 0x55033ED: consider_writing (bufferevent_openssl.c:874)
==695==    by 0x5503D41: be_openssl_outbuf_cb (bufferevent_openssl.c:1119)
==695==    by 0x52C0B58: evbuffer_run_callbacks (buffer.c:486)
==695==    by 0x52C0C51: evbuffer_invoke_callbacks (buffer.c:508)
==695==    by 0x52C61AD: evbuffer_add_reference (buffer.c:2718)
==695==    by 0x41EF6E: my_client_pkt_send (my_client_msg.c:75)
==695==    by 0x445807: my_client_tunn_event_cb (my_client_tun_intf.c:157)
==695==    by 0x52BA162: event_persist_closure (event.c:1301)
==695==    by 0x52BA271: event_process_active_single_queue (event.c:1345)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 232 bytes inside a block of size 608 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x52BE3F7: event_mm_free_ (event.c:2696)
==695==    by 0x52C878B: _bufferevent_decref_and_unlock (bufferevent.c:650)
==695==    by 0x52C8874: bufferevent_free (bufferevent.c:681)
==695==    by 0x435747: my_client_peer_delete (my_client_peer.c:1257)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x5503FB5: be_openssl_destruct (bufferevent_openssl.c:1183)
==695==    by 0x52C85F5: _bufferevent_decref_and_unlock (bufferevent.c:622)
==695==    by 0x52C8874: bufferevent_free (bufferevent.c:681)
==695==    by 0x435747: my_client_peer_delete (my_client_peer.c:1257)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 232 bytes inside a block of size 560 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x41EE2F: my_client_pktbuf_free (my_client_msg.c:54)
==695==    by 0x52BFFEC: evbuffer_chain_free (buffer.c:198)
==695==    by 0x52C251D: evbuffer_drain (buffer.c:972)
==695==    by 0x5502FA2: do_write (bufferevent_openssl.c:703)
==695==    by 0x55033ED: consider_writing (bufferevent_openssl.c:874)
==695==    by 0x5503D41: be_openssl_outbuf_cb (bufferevent_openssl.c:1119)
==695==    by 0x52C0B58: evbuffer_run_callbacks (buffer.c:486)
==695==    by 0x52C0C51: evbuffer_invoke_callbacks (buffer.c:508)
==695==    by 0x52C61AD: evbuffer_add_reference (buffer.c:2718)
==695==    by 0x41EF6E: my_client_pkt_send (my_client_msg.c:75)
==695==    by 0x426213: my_client_generic_send_message (my_client_msg.c:1708)
==695==    by 0x4297B9: my_client_peer_send_hello (my_client_msg.c:2181)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==
==695== Invalid write of size 8
==695==    at 0x52CF66B: evmap_io_add (evmap.c:328)
==695==    by 0x52BC638: event_add_internal (event.c:2073)
==695==    by 0x52BC150: event_add (event.c:1966)
==695==    by 0x52E695D: _evdns_nameserver_add_impl (evdns.c:2496)
==695==    by 0x52E6D7C: evdns_base_nameserver_ip_add (evdns.c:2592)
==695==    by 0x52E9B9B: resolv_conf_parse_line (evdns.c:3471)
==695==    by 0x52E9ECE: evdns_base_resolv_conf_parse_impl (evdns.c:3572)
==695==    by 0x52E9D60: evdns_base_resolv_conf_parse (evdns.c:3508)
==695==    by 0x52EA1A7: evdns_base_new (evdns.c:3881)
==695==    by 0x41AF33: my_client_connect_to_peer_my_clients (my_client.c:4978)
==695==    by 0x430FC6: my_client_peer_timer_exp_cb (my_client_peer.c:285)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 1,480 bytes inside an unallocated block of size 2,960 in arena "client"
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x52EA318: evdns_nameserver_free (evdns.c:3930)
==695==    by 0x52EA4EB: evdns_base_free_and_unlock (evdns.c:3965)
==695==    by 0x52EA6DD: evdns_base_free (evdns.c:4001)
==695==    by 0x41A5AE: my_client_dns_getaddrinfo_cb (my_client.c:4778)
==695==    by 0x52EB9E9: evdns_getaddrinfo (evdns.c:4563)
==695==    by 0x41B02E: my_client_connect_to_peer_my_clients (my_client.c:5000)
==695==    by 0x430FC6: my_client_peer_timer_exp_cb (my_client_peer.c:285)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 1,480 bytes inside an unallocated block of size 2,960 in arena "client"
==695==
==695== Invalid write of size 8
==695==    at 0x52CF66B: evmap_io_add (evmap.c:328)
==695==    by 0x52BC638: event_add_internal (event.c:2073)
==695==    by 0x52BC150: event_add (event.c:1966)
==695==    by 0x431580: ssl_connect_timer_cb (my_client_peer.c:371)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 1,480 bytes inside an unallocated block of size 2,960 in arena "client"
==695==
==695== Invalid write of size 8
==695==    at 0x52CF8DD: evmap_io_del (evmap.c:384)
==695==    by 0x52BCE7B: event_del_internal (event.c:2251)
==695==    by 0x52BCBD7: event_del (event.c:2188)
==695==    by 0x52BB484: event_free (event.c:1809)
==695==    by 0x435B36: my_client_peer_delete (my_client_peer.c:1323)
==695==    by 0x430EE8: my_client_peer_timer_exp_cb (my_client_peer.c:267)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==    by 0x41E5BA: main (my_client.c:6024)
==695==  Address 0x86ff848 is 8 bytes inside a block of size 160 free'd
==695==    at 0x4A0739B: free (vg_replace_malloc.c:473)
==695==    by 0x48B3EB: vip_guard_mem_free (vip_gaurd_mem.c:157)
==695==    by 0x5BFD5F9: CRYPTO_free (mem.c:401)
==695==    by 0x5CA9915: EVP_MD_CTX_cleanup (digest.c:390)
==695==    by 0x5CA532E: ssleay_rand_bytes (md_rand.c:525)
==695==    by 0x5CA53DB: ssleay_rand_pseudo_bytes (md_rand.c:548)
==695==    by 0x5CA5C67: RAND_pseudo_bytes (rand_lib.c:173)
==695==    by 0x594394A: ssl_fill_hello_random (s23_clnt.c:294)
==695==    by 0x5951112: dtls1_client_hello (d1_clnt.c:801)
==695==    by 0x59505CB: dtls1_connect (d1_clnt.c:302)
==695==    by 0x595C8E0: SSL_connect (ssl_lib.c:943)
==695==    by 0x441DBC: create_ssl_conn_to_peer (my_client_misc.c:2134)
==695==    by 0x4346AB: my_client_peer_create (my_client_peer.c:1018)
==695==    by 0x41B1BB: my_client_connect_to_peer_my_clients (my_client.c:5022)
==695==    by 0x41ABF9: my_client_dns_getaddrinfo_cb (my_client.c:4886)
==695==    by 0x52EB9E9: evdns_getaddrinfo (evdns.c:4563)
==695==    by 0x41B02E: my_client_connect_to_peer_my_clients (my_client.c:5000)
==695==    by 0x430FC6: my_client_peer_timer_exp_cb (my_client_peer.c:285)
==695==    by 0x488AC6: timer_exec_pri (timer.c:612)
==695==    by 0x4885A1: timer_exec (timer.c:504)
==695==    by 0x41A165: my_client_base_timer_cb (my_client.c:4671)
==695==    by 0x52BA2CC: event_process_active_single_queue (event.c:1350)
==695==    by 0x52BA540: event_process_active (event.c:1420)
==695==    by 0x52BABA7: event_base_loop (event.c:1621)
==695==    by 0x41C5D9: my_client_main (my_client.c:5437)
==695==

valgrind: /jenkins/master/builder/x86_64/tmp/work/x86_64-poky-linux/valgrind/3.10.0-r15/valgrind-3.10.0/coregrind/m_mallocfree.c:304
(get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 224, hi = 0.

Gmane