-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak when connecting from client using WS spec revision 0 #1
Comments
Closed
Closed
Thanks... this area got refactordd a while back, there's a point where the main flow frees the headers which is commented, every other path uses bail_nuke_ah now. |
Closed
Closed
Closed
This was referenced Dec 24, 2022
Closed
Merkyrio
pushed a commit
to liveryvideo/libwebsockets
that referenced
this issue
May 2, 2024
There is potential deadlock between lws_create_context and lws_service. This TSAN message would give more details (proprietary code backtrace was stripped): ================== WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=516380) Cycle in lock order graph: M0 (0x7bb4000016b8) => M1 (0x7bb400000360) => M0 Mutex M1 acquired here while holding mutex M0 in thread T2: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_wsi_inject_to_loop libwebsockets/lib/core-net/wsi.c:354:2 (libwebsockets.so.19+0xbf8d7) warmcat#3 __lws_create_event_pipes libwebsockets/lib/core-net/vhost.c:1172:8 (libwebsockets.so.19+0xb490f) warmcat#4 lws_create_context libwebsockets/lib/core/context.c:1302:6 (libwebsockets.so.19+0x3e592) Mutex M0 previously acquired by the same thread here: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_create_context libwebsockets/lib/core/context.c:1301:2 (libwebsockets.so.19+0x3e580) Mutex M0 acquired here while holding mutex M1 in thread T8: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_sul_plat_unix libwebsockets/lib/plat/unix/unix-init.c:64:2 (libwebsockets.so.19+0x1e4a1) warmcat#3 __lws_sul_service_ripe libwebsockets/lib/core-net/sorted-usec-list.c:161:3 (libwebsockets.so.19+0xbd871) warmcat#4 _lws_plat_service_tsi libwebsockets/lib/plat/unix/unix-service.c:125:7 (libwebsockets.so.19+0x1fc07) warmcat#5 lws_plat_service libwebsockets/lib/plat/unix/unix-service.c:235:9 (libwebsockets.so.19+0x20237) warmcat#6 lws_service libwebsockets/lib/core-net/service.c:838:6 (libwebsockets.so.19+0xbd0c2) Mutex M1 previously acquired by the same thread here: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 _lws_plat_service_tsi libwebsockets/lib/plat/unix/unix-service.c:121:2 (libwebsockets.so.19+0x1fbee) warmcat#3 lws_plat_service libwebsockets/lib/plat/unix/unix-service.c:235:9 (libwebsockets.so.19+0x20237) warmcat#4 lws_service libwebsockets/lib/core-net/service.c:838:6 (libwebsockets.so.19+0xbd0c2) SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock ==================
Merkyrio
pushed a commit
to liveryvideo/libwebsockets
that referenced
this issue
May 2, 2024
There is potential deadlock between lws_create_context and lws_service. This TSAN message would give more details (proprietary code backtrace was stripped): ================== WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=516380) Cycle in lock order graph: M0 (0x7bb4000016b8) => M1 (0x7bb400000360) => M0 Mutex M1 acquired here while holding mutex M0 in thread T2: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_wsi_inject_to_loop libwebsockets/lib/core-net/wsi.c:354:2 (libwebsockets.so.19+0xbf8d7) warmcat#3 __lws_create_event_pipes libwebsockets/lib/core-net/vhost.c:1172:8 (libwebsockets.so.19+0xb490f) warmcat#4 lws_create_context libwebsockets/lib/core/context.c:1302:6 (libwebsockets.so.19+0x3e592) Mutex M0 previously acquired by the same thread here: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_create_context libwebsockets/lib/core/context.c:1301:2 (libwebsockets.so.19+0x3e580) Mutex M0 acquired here while holding mutex M1 in thread T8: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 lws_sul_plat_unix libwebsockets/lib/plat/unix/unix-init.c:64:2 (libwebsockets.so.19+0x1e4a1) warmcat#3 __lws_sul_service_ripe libwebsockets/lib/core-net/sorted-usec-list.c:161:3 (libwebsockets.so.19+0xbd871) warmcat#4 _lws_plat_service_tsi libwebsockets/lib/plat/unix/unix-service.c:125:7 (libwebsockets.so.19+0x1fc07) warmcat#5 lws_plat_service libwebsockets/lib/plat/unix/unix-service.c:235:9 (libwebsockets.so.19+0x20237) warmcat#6 lws_service libwebsockets/lib/core-net/service.c:838:6 (libwebsockets.so.19+0xbd0c2) Mutex M1 previously acquired by the same thread here: #0 pthread_mutex_lock warmcat#1 lws_mutex_refcount_lock libwebsockets/lib/core/libwebsockets.c:1471:2 (libwebsockets.so.19+0x48ff2) warmcat#2 _lws_plat_service_tsi libwebsockets/lib/plat/unix/unix-service.c:121:2 (libwebsockets.so.19+0x1fbee) warmcat#3 lws_plat_service libwebsockets/lib/plat/unix/unix-service.c:235:9 (libwebsockets.so.19+0x20237) warmcat#4 lws_service libwebsockets/lib/core-net/service.c:838:6 (libwebsockets.so.19+0xbd0c2) SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock ==================
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[I'm posting here because libwebsockets.org seems to be down.]
Each time I connect to my WS server using Safari 5.1.9 under OS X 10.6.8, Libwebsockets complains "WARN: Unknown client spec version 0". That's fine, but when I quit after running using Valgrind, Valgrind complains about leaked memory.
Here's the output from a run with four failed connections:
The problem: the header table isn't being freed. The fix is to make a change in handshake.c:230, changing:
to:
The "bail_nuke_ah" label adds a free() of the header table:
Note that the "goto bail"s and "goto bail_nuke_ah"s seem to be used almost interchangeably; someone should review them to make sure the right choices are being made.
The text was updated successfully, but these errors were encountered: