Azat Khuzhin [Wed, 31 Jul 2019 07:34:38 +0000 (10:34 +0300)]
buffer: fix possible NULL dereference in evbuffer_setcb() on ENOMEM
[ @azat:
- add return heredoc for evbuffer_setcb()
- add unit test with event_set_mem_functions()
- look through the report from abi-compliance-checker/abi-dumper
]
There are three undefined variables: MKDIR_P, AM_V_GEN and AM_V_at.
Then I tried:
- autoconf-2.60 / automake-1.10
- autoconf-2.61 / automake-1.11
- autoconf-2.62 / automake-1.11.2
And only autoconf-2.62 & automake-1.11.2 is ok.
Therefore, I recommend changing the autoconf version from 2.59 to 2.62
and automake version from 1.9 to 1.11.2.
Plus autoconf 2.59 is too old - 2003.12.16 [1], so as automake 1.9 -
2004.08.11 [2], while $(AM_V_GEN)/$(AM_V_at) had been introduced in 371a1237 back in 2012.
cmake: set library names to be the same as with autotools
libtool has VERSION_INFO [1], cmake has SOVERSION/VERSION instead
(although it has different format). Also libtool has RELEASE [2] while
cmake do not have analog yet [3], hence manual symlinks should be
created.
Plus osx has compatibility_version/current_version dylib properties and
cmake do not have separate properties for them [4], hence manual LINK_FLAGS.
And also there INSTALL_NAME_DIR property which should be adjusted too.
So after all changes, here is an example before/after for osx and linux:
# osx
# autotools
.libs/libevent_pthreads-2.2.1.dylib
.libs/libevent_pthreads.dylib -> libevent_pthreads-2.2.1.dylib
/usr/local/lib/libevent_pthreads-2.2.1.dylib (compatibility version 2.0.0, current version 2.0.0)
# cmake
# before patch
lib/libevent_pthreads.2.2.0.dylib
lib/libevent_pthreads.dylib -> libevent_pthreads.2.2.0.dylib
@rpath/libevent_pthreads.2.2.0.dylib (compatibility version 2.2.0, current version 0.0.0)
# after patch
lib/libevent_pthreads-2.2.1.dylib
lib/libevent_pthreads.dylib -> libevent_pthreads-2.2.1.dylib
/vagrant/.cmake/inst/lib/libevent_pthreads-2.2.1.dylib (compatibility version 2.0.0, current version 2.0.0)
Keith Smiley [Mon, 8 Jul 2019 21:06:55 +0000 (14:06 -0700)]
Enable _GNU_SOURCE for Android
When targeting the Android NDK _GNU_SOURCE is not enabled by default:
```
/*
* With bionic, you always get all C and POSIX API.
*
* If you want BSD and/or GNU extensions, _BSD_SOURCE and/or _GNU_SOURCE are
* expected to be defined by callers before *any* standard header file is
* included.
*
* In our header files we test against __USE_BSD and __USE_GNU.
*/
#if defined(_GNU_SOURCE)
# define __USE_BSD 1
# define __USE_GNU 1
#endif
```
Because of this `pipe2` is not available:
```
#if defined(__USE_GNU)
int pipe2(int __fds[2], int __flags) __INTRODUCED_IN(9);
#endif
```
Just check that the _linking_ succeeds, which it does, it's just not
visible in the import, leading to a warning (or error):
```
evutil.c:2637:6: error: implicit declaration of function 'pipe2' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (pipe2(fd, O_NONBLOCK|O_CLOEXEC) == 0)
^
```
When targeting the NDK it should be safe to always opt into this. Clang
would pass the right flag for us automatically _if_ the source was C++
instead of C.
Keith Smiley [Tue, 2 Jul 2019 17:47:47 +0000 (10:47 -0700)]
Enable kqueue for APPLE targets
The CMAKE_CROSSCOMPILING variable is not set for Apple targets seemingly
because of cmake implementation details (more info
https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING.html).
Since Apple targets have working kqueue implementations this check makes
sure we enable it always when those are the targets, without users
having to explicitly set EVENT__HAVE_WORKING_KQUEUE
Azat Khuzhin [Sat, 15 Jun 2019 20:18:05 +0000 (23:18 +0300)]
evdns: add new options -- so-rcvbuf/so-sndbuf
This will allow to customize SO_RCVBUF/SO_SNDBUF for nameservers in this
evdns_base, you may want to adjust them if the kernel starts dropping
udp packages.
Since commit 506df426dbeb0187bbd3654bd286b4100628fb16, OPENSSL_INCS is
added to CPPFLAGS without any white space, as a result openssl detection
fails on:
configure:10395: checking openssl/ssl.h usability
configure:10395: /home/fabrice/buildroot-test/buildroot/output/host/bin/riscv32-linux-gcc -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wall -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64-I/home/fabrice/buildroot-test/buildroot/output/host/bin/../riscv32-buildroot-linux-gnu/sysroot/usr/include conftest.c >&5
<command-line>:0:0: warning: "_FILE_OFFSET_BITS" redefined
<command-line>:0:0: note: this is the location of the previous definition
<command-line>:0:23: error: division by zero in #if
On 64 bit systems with a lot of memory it is possible to overflow the
counter s->n (unsigned int) which keeps track of the amount of elements
within the heap.
On 32 bit systems with tightly packed memory layout (and adding the
same pointer again and again) an integer overflow could occur if "a"
reaches 2^30 because the multiplication with sizeof *p (4) would
overflow, effectively freeing memory of s->p which eventually leads to
a double free.
No sign of issue for any sane setup and therefore a purely defensive
measurement.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Refs: #799 (first version of the patch for backporting to 2.1.x only)
See-also: 181049739478d57500bd564539f17407437bfe8f ("Revert "Protect min_heap_push_ against integer overflow."")
Azat Khuzhin [Wed, 31 Jul 2019 08:25:47 +0000 (11:25 +0300)]
Revert "Protect min_heap_push_ against integer overflow."
This patch breaks the ABI compatibility, due to min_heap_idx expansion
[1]
And since major distros did not updated to 2.1.10 yet, this patch will
be reverted:
- debian: https://packages.debian.org/search?keywords=libevent-dev
- ubuntu: https://packages.ubuntu.com/search?keywords=libevent-dev
- fedora: https://apps.fedoraproject.org/packages/libevent-devel
Also there is one that upgraded already:
- archlinux: https://www.archlinux.org/packages/?q=libevent
But archlinux is for developers, so it should be fine I guess.
- struct event_base
Change: Size of this type has been changed from 672 bytes to 664 bytes.
Effect: The fields or parameters of such data type may be incorrectly initialized or accessed by old client applications.
abi-compliance-checker diff with 2.1.9 before this patch:
Binary compatibility: 69.2%
Source compatibility: 100%
Total binary compatibility problems: 1, warnings: 1
Total source compatibility problems: 0, warnings: 0
Azat Khuzhin [Thu, 16 May 2019 07:25:50 +0000 (10:25 +0300)]
Merge branch 'evbuffer-fixes-806-v2'
* evbuffer-fixes-806-v2:
evbuffer: fix last_with_datap after prepend with empty chain
test: regression for evbuffer_expand_fast_() with invalid last_with_datap
test: cover adjusting of last_with_datap in evbuffer_prepend()
* issue-807-accept4-getnameinfo-AF_UNIX:
http-server: add usage/help dialog
http: avoid use of uninitialized value for AF_UNIX/AF_LOCAL sockaddr
http-server: add ability to bind to unix-socket
build: struct sockaddr_un detection (sys/un.h, afunix.h)
Azat Khuzhin [Tue, 2 Apr 2019 20:25:08 +0000 (23:25 +0300)]
appveyor: check intermediate powershell commands exit codes and terminate early
Otherwise build errors will be ignored, i.e. if build fails but regress
binary exists (copied from artifacts) it will be runned instead of newly
compiled.
Azat Khuzhin [Sun, 31 Mar 2019 23:42:55 +0000 (02:42 +0300)]
Merge branch 'fix-uchex-warnings'
There is one more report that is false positive, see [1]:
"In bufferevent_openssl.c, pointer wm is dereferenced on line 871
before it is null checked on line 873."
- DNS_OPTION_NAMESERVERS_NO_DEFAULT
Do not "default" nameserver (i.e. "127.0.0.1:53") if there is no nameservers
in resolv.conf, (iff DNS_OPTION_NAMESERVERS is set)
- EVDNS_BASE_NAMESERVERS_NO_DEFAULT
If EVDNS_BASE_INITIALIZE_NAMESERVERS isset, do not add default
nameserver if there are no nameservers in resolv.conf (just set
DNS_OPTION_NAMESERVERS_NO_DEFAULT internally)
Azat Khuzhin [Sun, 24 Mar 2019 22:40:46 +0000 (01:40 +0300)]
Link test/regress with event_core/event_extra over event
Due to regress linked with event and event_core (both of them includes
evthread.c) there will be two different evthread_id_fn_ variables under
mingw64:
evthread_id_fn_: &0x5294f20a8
evthread_id_fn_: &0x4ba0030a8
And because of this evthread_use_pthreads() can/will set one copy of
variables while evthread*() functions will access another, which will
break a lot of things (for example main/del_notify test).
Azat Khuzhin [Tue, 12 Mar 2019 21:02:39 +0000 (00:02 +0300)]
cmake: sync warnings with autotools v2
By some reason gcc reports next error:
../http.c:3330:11: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
value = "";
Only under -Wwrite-strings, well this is logical, but this information
does not reflected in any documentation.
Follow-up: 8348b413 ("cmake: add various warning flags like autotools has")
Azat Khuzhin [Sun, 3 Mar 2019 15:58:57 +0000 (18:58 +0300)]
Merge branch 'evbuffer-empty-chain-handling'
* evbuffer-empty-chain-handling:
buffer: do not rely on ->off in advance_last_with_data()
buffer: fix evbuffer_remove_buffer() with empty chain in front
test: verify content of the buffer in evbuffer/remove_buffer_with_empty*
Enji Cooper [Mon, 25 Feb 2019 19:59:15 +0000 (11:59 -0800)]
Define `_GNU_SOURCE` properly/consistently per autoconf
Although `_GNU_SOURCE` can be defined as an arbitrary #define per the
glibc docs [1], it's best to define it in a manner consistent with the way
that autoconf defines it, i.e., `1`.
While this shouldn't matter in most cases, it does when the headers from
other projects follow the poorly defined GNU convention implemented by
autoconf and are included after the libevent's util.h header. An example
failure with clang, similar to the failure I encountered, is as follows:
```
$ printf "#define _GNU_SOURCE\n#define _GNU_SOURCE 1" | clang -c -x c -
<stdin>:2:9: warning: '_GNU_SOURCE' macro redefined [-Wmacro-redefined]
^
<stdin>:1:9: note: previous definition is here
^
1 warning generated.
```
This happened when compiling python [2] with a stale homebrew util.h file from
libevent (which admittedly would not happen in a correct libevent install, as the
header should be installed under /usr/local/include/event2/util.h). However, if
both headers had been combined (which is more likely), it would have failed as
shown above.
Removing the ad hoc definition unbreaks compiling python's pyconfig.h.in header
when included after util.h from libevent.
Azat Khuzhin [Sun, 24 Feb 2019 14:07:18 +0000 (17:07 +0300)]
Use kill() over raise() for raising the signal (fixes osx 10.14 with kqueue)
On OSX 10.14+ the raise() uses pthread_kill() (verified with dtruss) and
by some reason signals that has been raised with pthread_kill() do not
received by kqueue EVFILT_SIGNAL.
While on OSX 10.11 the raise()/pthread_kill() uses plain kill() and
everything work just fine (linux also does the same, but instead of
kill() it uses tgkill())
Here is a simple reproducer that installs alarm to show that the signal
does not received by the kqueue backend:
https://gist.github.com/azat/73638b8e3b0fa563a20dadcca9e652a1
Azat Khuzhin [Sun, 3 Feb 2019 15:47:14 +0000 (18:47 +0300)]
test/ssl/bufferevent_wm: explicitly break the loop once client/server received enough
There can be tricky cases (that can be reproduced by reducing
SO_RCVBUF/SO_SNDBUF to 6144, on linux, and be aware, since linux doubles
this const), when there is still write event pending, although we read
enough.
This should be fixed in a more sophisticated way, but to backport the
patch, let's simply break the loop manually.
The ssl/bufferevent_wm originally failed on solaris.
Azat Khuzhin [Tue, 29 Jan 2019 18:06:37 +0000 (21:06 +0300)]
test/et/et: use evutil_socket_t* over int* for pointer to the pair
Next code will not work correctly under win x64:
evutil_socket_t very_long_pair_name[2];
int *pair = very_long_pair_name; // <-- accessing the second word of the first element
Because sizeof(evutil_socket_t) == sizeof(intptr_t) == 8
P.S. in the 5334762f another test had been fixed instead of the one that
really fails.
Fixes: 5334762f ("test/et/et: fix it by using appropriate type for the SOCKET (evutil_socket_t)")
Refs: #750
(cherry picked from commit 0791a17204ff70bbea92520352a0c6e8d185fa4b)
Azat Khuzhin [Tue, 29 Jan 2019 07:54:39 +0000 (10:54 +0300)]
Merge branch 'win64-fixes'
* win64-fixes:
test/et/et: fix it by using appropriate type for the SOCKET (evutil_socket_t)
test/et/et: verify return codes
appveyor: switch to new VS/MinGW and x64
* http-EVHTTP_CON_READ_ON_WRITE_ERROR-fixes-v2:
http: try to read existing data in buffer under EVHTTP_CON_READ_ON_WRITE_ERROR
test: add logging for http/read_on_write_error and rearrange code
http: do not call deferred readcb if readcb is not set
Azat Khuzhin [Sat, 26 Jan 2019 15:52:33 +0000 (18:52 +0300)]
test: adjust expecting error for getaddrinfo() under EMFILE
When getaddrinfo() cannot allocate file descriptor glibc/musl-libc on
linux report EAI_SYSTEM error. But this is not true for freebsd libc [1]
(and hence apple libc [2]), they report EAI_NONAME error instead, so
adjust expectation.
Azat Khuzhin [Fri, 11 Jan 2019 18:52:11 +0000 (21:52 +0300)]
rpc: use *_new_with_arg() to match function prototype
In 755fbf16c ("Add void* arguments to request_new and reply_new
evrpc hooks") this new functions had been introduced, but newer used,
what for? So let's use them.