Since new compilers has new checks (like -Wdangling-pointer), and so to
avoid extra checks in cmake/autotools, simply suppress if the pragma is
unknown.
gcc 12 complains:
[34/46] Building C object CMakeFiles/event_static.dir/event.c.o
/src/le/libevent/event.c: In function ‘event_signal_closure’:
/src/le/libevent/event.c:1384:32: warning: storing the address of local variable ‘ncalls’ in ‘*ev.ev_.ev_signal.ev_pncalls’ [-Wdangling-pointer=]
1384 | ev->ev_pncalls = &ncalls;
| ~~~~~~~~~~~~~~~^~~~~~~~~
/src/le/libevent/event.c:1378:15: note: ‘ncalls’ declared here
1378 | short ncalls;
| ^~~~~~
/src/le/libevent/event.c:1378:15: note: ‘ev’ declared here
Fixes the following:
[4/38] Building C object CMakeFiles/event_shared.dir/sha1.c.o
In function ‘SHA1Update’,
inlined from ‘SHA1Final’ at /src/le/libevent/sha1.c:274:5,
inlined from ‘builtin_SHA1’ at /src/le/libevent/sha1.c:292:5:
/src/le/libevent/sha1.c:228:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 7 [-Wstringop-overread]
228 | SHA1Transform(context->state, *(const unsigned char (*)[64])&data[i]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/src/le/libevent/sha1.c:228:13: note: referencing argument 2 of type ‘const unsigned char[64]’
/src/le/libevent/sha1.c: In function ‘builtin_SHA1’:
/src/le/libevent/sha1.c:80:13: note: in a call to function ‘SHA1Transform’
80 | static void SHA1Transform(uint32_t state[5], const unsigned char buffer[64]) {
| ^~~~~~~~~~~~~
* http: fix typo
* ws: fix comile error
On CentOS:
CC ws.lo
ws.c: In function 'get_ws_frame':
ws.c:244:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0; i < payload_len; i++) {
^
ws.c:244:3: note: use option -std=c99 or -std=gnu99 to compile your code
@widgetii:
"
=================================================================
==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
"
* upstream/pr/1360:
Remove bad copy-paste
Add locks for server WS, fixes#1357
@widgetii:
"Recently after studying [https-client.c code](https://github.com/libevent/libevent/blob/master/sample/https-client.c#L532) I found that I cannot use MbedTLS with `bufferevent_mbedtls_socket_new` same way as for OpenSSL in other than hello-world code. In mentioned sample code, ssl context is created by `SSL_new()` (as heap-based pointer), but for MbedTLS stack value is used. The issue is in different semantics because OpenSSL is responsible for memory allocation and release for its context, but for MbedTLS it turns out user should do the same manually.
I expect that in both cases, setting option `BEV_OPT_CLOSE_ON_FREE` will free all linked resources, but in case of MbedTLS I have memory leak after connection is closed.
My proposal is:
1. Provide new `mbedtls_ssl_new` helper-function for end-user that do the same job as `SSL_new()` and use it and example in sample:
```c
mbedtls_ssl_context *mbedtls_ssl_new(const mbedtls_ssl_config *conf) {
mbedtls_ssl_context *ssl = calloc(1, sizeof(*ssl));
mbedtls_ssl_init(ssl);
mbedtls_ssl_setup(ssl, conf);
return ssl;
}
```
2. Add `free(ctx->ssl)` right after https://github.com/libevent/libevent/blob/master/bufferevent_mbedtls.c#L68"
Fixes: #1354
Before it fails with:
exec ssh: pkg install -y mbedtls cmake python3
/bin/bash /Users/runner/work/_actions/vmactions/freebsd-vm/v0/run.sh execSSH
Config file: freebsd-13.0.conf
Pseudo-terminal will not be allocated because stdin is not a terminal.
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
Installing pkg-1.18.3...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1301000
- running kernel: 1300139
Ignore the mismatch and continue? [y/N]:
Failed to install the following 1 package(s): /tmp//pkg.txz.18yvwm
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Error: The process '/bin/bash' failed with exit code 1
And now with:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
Commenting for now, anyway we do not need such huge CI matrix, because
we have only public workers, and they are pretty busy.
Cc: @Neilpang
This adds few functions to use evhttp-based webserver to handle incoming
WebSockets connections. We've tried to use both libevent and libwebsockets in
our application, but found that we need to have different ports at the same
time to handle standard HTTP and WebSockets traffic. This change can help to
stick only with libevent library.
Implementation was inspired by modified Libevent source code in ipush project
[1].
[1]: https://github.com/sqfasd/ipush/tree/master/deps/libevent-2.0.21-stable
Also, WebSocket-based chat server was added as a sample.
In it's current form, libevent requires multiple struct evhttp objects to be created in order to enable listening on sockets with more than one type of encryption.
This change allows specifying per-socket how the associated bufferevents should be created.
Thus, it becomes possible to have multiple listening sockets with different encryption parameters using only one evttp.
Deleted usage of CMake feature 'file(REAL_PATH'
which is available from version 3.19
with an old 'get_filename_component' so that
older version of CMake can still be used
to configure the project.
There can be issues on 32-bit architectures to mmap 2+GiB file, and to
make this portable between different version of glibc, mmap64 was
prefered over _FILE_OFFSET_BITS
There are periodically some heap-use-after-free reported in ratelim
tests by TSan, which I cannot reproduce locally and even on CI it is
flaky.
Let's try to use recent clang, maybe it fixes some issues in sanitizers.
Refs: #1206
