Its normal behavior? I don't expect events before call bufferevent_socket_connect

AFAICS it should not happen.
This sounds like a simple and reproducible issue.
Can you show a code sample?

Oops. I can't reproduce it now. How i can enable max logging for libevent library without rebuild? When it starts again I will try to collect more information.
libevent-src.zip

I reproduce it. Output from "libevent-src.zip"

Starting...
TCP port: 40487
Start event loop
Client thread is ready
call tcp_accept_connection_callback
call tcp_server_read_callback
call tcp_client_event_callback: 33
BEV_EVENT_ERROR
BEV_EVENT_READING
call tcp_client_event_callback: 128
BEV_EVENT_CONNECTED

Step by step:

• Build example source code: g++ libevent-src.cpp -lpthread -levent -levent_core -levent_pthreads
• Run binary
• Connect to TCP port using telnet tool
• Send any message
• tcp_client_event_callback call twice

Reproducing is not 100%

How i can enable max logging for libevent library without rebuild?

event_enable_debug_logging(EVENT_DBG_ALL)

libevent-src.zip

Thanks. You code has some issues, but this should not affect.

I reproduce it.

Can you provide strace log for such failure?
i.e. run program like this strace -s 1000 -f -tt -o strace.log /path/to/bin

And also separate output with event_enable_debug_logging(EVENT_DBG_ALL) but w/o strace.

You code has some issues, but this should not affect.

Could you tell me more, please?

Can you provide strace log for such failure

Of course. I will let you know how the results are.

I modified source code for fast reproduce -- each data read we starting new connection. After 3-4 times issue is reproduce.
libevent-update-1.zip

Problem signature in logs:

21128 12:11:17.231254 write(1, "call tcp_client_event_callback: 33\n", 35) = 35
21128 12:11:17.231437 write(1, "BEV_EVENT_ERROR\n", 16) = 16
21128 12:11:17.231607 write(1, "BEV_EVENT_READING\n", 18) = 18

strace.zip

stdout:
stdout.zip

Libevent version is 2.1.11-stable

Like I thought the problem that you've enabled EV_READ before connect, you should not do so, since you can read from unconnected socket.

Could you tell me more, please?

Sure.
Although maybe it is just a test sample and I should not be so critical.

Anyway here are some comments after a brief look:

Basic anti patterns:

• you are using busy loops for waiting of the event
• global variables

libevent anti patterns:

• you are using separate thread for the event_base, it is better to have event_base per thread
• you don't need to call evutil_make_socket_nonblocking() manually you can just pass -1 as fd and this will be done automatically
• it is better to use EV_SIGNAL in programs that are using libevent, that way you will be able to use non-signal-safe functions in signal handlers, also note, that event_base_loopexit() is not signal safe