Just found another issue (this time in recently merged WS code):

=================================================================
==985==ERROR: AddressSanitizer: heap-use-after-free on address 0xb24323e5 at pc 0xb6a06f1c bp 0x9fffc694 sp 0x9fffc260
WRITE of size 2 at 0xb24323e5 thread T22
    #0 0xb6a06f1b in __interceptor_memcpy.part.43 (/usr/lib/libasan.so.5+0x41f1b)

0xb24323e5 is located 229 bytes inside of 512-byte region [0xb2432300,0xb2432500)
freed by thread T0 (app) here:
    #0 0xb6a849df in free (/usr/lib/libasan.so.5+0xbf9df)
    #1 0xb64b6e07 in evbuffer_drain (/usr/lib/libevent_core-2.2.so.1+0x9e07)

previously allocated by thread T22 here:
    #0 0xb6a84d17 in __interceptor_malloc (/usr/lib/libasan.so.5+0xbfd17)
    #1 0xb64b3d1b  (/usr/lib/libevent_core-2.2.so.1+0x6d1b)
    #2 0x61223 in onIceCandidateHandler /home/dima/git/app/src/webrtc/local.c:116
    #3 0x19296f in onNewIceLocalCandidate /home/dima/git/webrtc-c/src/source/PeerConnection/PeerConnection.c:471

I have libevent-based web server that handles incoming WS connections, exchanging WebRTC ice candidates between server and client. The issue is that used WebRTC library handles incoming connection in separate thread and when new json data is ready it should be sent back to the client in main (libevent-based) thread. In debugging code, I found that the data race happened when both threads work with same WS connection: main thread handles incoming data in ws_evhttp_read_cb() and calls evbuffer_drain() and another thread trying to send data back using evws_send() (crashes internally in evbuffer_add()).

From my point of view, everything should work fine because both evbuffer_drain() and evbuffer_add() are using different evbuffers (input and output respectively), but they share the same bufferevent and I guess this is a root cause.

How to properly work around this issue?

1. Add internal bufferevent locks?
2. Use another logic?