Then next code sample will use free'd lock:
evthread_use_pthreads();
...
assert(!bufferevent_pair_new(base, BEV_OPT_THREADSAFE, pair));
...
bufferevent_free(pair[0]); # refcnt == 0 -> unlink
bufferevent_free(pair[1]); # refcnt == 0 -> unlink
...
event_base_free() -> finalizers -> EVTHREAD_FREE_LOCK(bev1->lock)
-> BEV_LOCK(bev2->lock) <-- *already freed*
While if you will reverse the order:
bufferevent_free(pair[1]); # refcnt == 0 -> unlink
bufferevent_free(pair[0]); # refcnt == 0 -> unlink
...
event_base_free() -> finalizers -> BEV_LOCK(bev2->lock)/!own_lock/BEV_UNLOCK(bev2->lock)
-> EVTHREAD_FREE_LOCK(bev1->lock) (own_lock)
It is ok now, but I guess that it will be better to relax order of
freeing pairs.
This will avoid leaking of event_debug_map_HT_GROW
I buildin it into libevent_glboal_shutdown() because
event_disable_debug_mode() -> event_free_debug_globals() ->
event_free_debug_globals_locks() will clean event_debug_map_lock_ that
used in event_disable_debug_mode().
For this fix, we need to make sure that passing too-large inputs to
the evbuffer functions can't make us do bad things with the heap.
Also, lower the maximum chunk size to the lower of off_t, size_t maximum.
This is necessary since otherwise we could get into an infinite loop
if we make a chunk that 'misalign' cannot index into.
This fixes following problems in shared library build:
* visibility=hidden was not enabled for gcc because of incorrect variable name
* test programs that need internal APIs caused link errors
There is a race between manual event_active and natural event activation. If both happen at the same time on the same FD, they would both be protected by the same event base lock except for 1 LoC where the fields of struct event are read without any kind of lock. This commit does those reads into local variables inside the lock and then invokes the callback with those local arguments outside the lock. In 2.0-stable, none of this is inside the lock; in HEAD, only the callback is read inside the lock. This gets the callback and all 3 arguments inside the lock before calling it outside the lock.
CMAKE_MODULE_PATH is usually a list instead of single entry. Especially
for projects contain sub cmake projects. My patch replace the
CMAKE_MODULE_PATH with fixed path, to locate the `.in` file.
In case when between this two close (close(F), close(F)) some open()
will be executed, than we will close newly opened fd.
Reported-by: xujiezhige@163.com
