Comments (5)
I tried to reproduce the problem, but when I run your program I get:
root@ubuntu:/home/tuexen/Documents/usrsctp/programs# valgrind ./crash
==14110== Memcheck, a memory error detector
==14110== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14110== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14110== Command: ./crash
==14110==
==14112==
==14112== HEAP SUMMARY:
==14112== in use at exit: 0 bytes in 0 blocks
==14112== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14112==
==14112== All heap blocks were freed -- no leaks are possible
==14112==
==14112== For counts of detected and suppressed errors, rerun with: -v
==14112== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14111==
==14111== HEAP SUMMARY:
==14111== in use at exit: 0 bytes in 0 blocks
==14111== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14111==
==14111== All heap blocks were freed -- no leaks are possible
==14111==
==14111== For counts of detected and suppressed errors, rerun with: -v
==14111== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14113==
==14113== HEAP SUMMARY:
==14113== in use at exit: 0 bytes in 0 blocks
==14113== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14113==
==14113== All heap blocks were freed -- no leaks are possible
==14113==
==14113== For counts of detected and suppressed errors, rerun with: -v
==14113== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14115==
==14115== HEAP SUMMARY:
==14115== in use at exit: 0 bytes in 0 blocks
==14115== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14115==
==14115== All heap blocks were freed -- no leaks are possible
==14115==
==14115== For counts of detected and suppressed errors, rerun with: -v
==14115== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14114==
==14114== HEAP SUMMARY:
==14114== in use at exit: 0 bytes in 0 blocks
==14114== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14114==
==14114== All heap blocks were freed -- no leaks are possible
==14114==
==14114== For counts of detected and suppressed errors, rerun with: -v
==14114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14117==
==14117== HEAP SUMMARY:
==14117== in use at exit: 0 bytes in 0 blocks
==14117== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14117==
==14117== All heap blocks were freed -- no leaks are possible
==14117==
==14117== For counts of detected and suppressed errors, rerun with: -v
==14117== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14120==
==14120== HEAP SUMMARY:
==14120== in use at exit: 0 bytes in 0 blocks
==14120== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14120==
==14120== All heap blocks were freed -- no leaks are possible
==14120==
==14120== For counts of detected and suppressed errors, rerun with: -v
==14120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14121==
==14121== HEAP SUMMARY:
==14121== in use at exit: 0 bytes in 0 blocks
==14121== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14121==
==14121== All heap blocks were freed -- no leaks are possible
==14121==
==14121== For counts of detected and suppressed errors, rerun with: -v
==14121== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
In receive_cb
Connections closed
Still in receive_cb
root@ubuntu:/home/tuexen/Documents/usrsctp/programs#
So I can't reproduce the problem. Is it posible that you are not using the version of the code in the git repo? Without being able to reproduce it, I'm not able to fix it...
from usrsctp.
OK, thanks to Felix, I can no reproduce a problem. The reason is that the way I invoked it, a shell script was tested. When configuring it as
./configure --enable-static --disable-shared
and compiling and running it, I get
root@ubuntu:/home/tuexen/Documents/usrsctp/programs# valgrind ./crash
==5759== Memcheck, a memory error detector
==5759== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5759== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==5759== Command: ./crash
==5759==
In receive_cb
==5759==
==5759== Process terminating with default action of signal 11 (SIGSEGV)
==5759== General Protection Fault
==5759== at 0x4E4AAF3: __lll_unlock_elision (elision-unlock.c:33)
==5759== by 0x401B81: sofree (user_socket.c:258)
==5759== by 0x403E00: usrsctp_close (user_socket.c:2086)
==5759== by 0x401761: main (crash.c:54)
==5759==
==5759== HEAP SUMMARY:
==5759== in use at exit: 469,865 bytes in 465 blocks
==5759== total heap usage: 539 allocs, 74 frees, 511,056 bytes allocated
==5759==
==5759== LEAK SUMMARY:
==5759== definitely lost: 872 bytes in 4 blocks
==5759== indirectly lost: 24,960 bytes in 192 blocks
==5759== possibly lost: 3,360 bytes in 6 blocks
==5759== still reachable: 440,673 bytes in 263 blocks
==5759== suppressed: 0 bytes in 0 blocks
==5759== Rerun with --leak-check=full to see details of leaked memory
==5759==
==5759== For counts of detected and suppressed errors, rerun with: -v
==5759== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Killed
root@ubuntu:/home/tuexen/Documents/usrsctp/programs#
Let me have a look into this...
from usrsctp.
It looks like you are observing a different issue. I'm also getting this output now (after glibc update?). It looks like it's caused by doubled pthread_mutex_unlock call.
See my commit: banthar@cb401d7 After I enable PTHREAD_MUTEX_ERRORCHECK, ACCEPT_UNLOCK no longer crashes.
valgrind --trace-children=yes ./programs/test
Shows the original error (and invalid unlock):
==8724== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8724== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==8724== Command: /home/piotr/projekty/usrsctp/programs/.libs/lt-test
==8724==
In receive_cb
invalid unlock in user_socket.c:258
Connections closed
Still in receive_cb
==8724== Thread 3 SCTP/IP4 rcv:
==8724== Invalid read of size 4
==8724== at 0x4E57440: sctp_calc_rwnd (sctp_indata.c:86)
==8724== by 0x4E57488: sctp_set_rwnd (sctp_indata.c:64)
==8724== by 0x4E6E44D: sctp_send_sack (sctp_output.c:10877)
==8724== by 0x4E582D4: sctp_process_data (sctp_indata.c:2575)
==8724== by 0x4E69570: sctp_common_input_processing (sctp_input.c:6136)
==8724== by 0x4E45CCE: recv_function_raw (user_recv_thread.c:433)
==8724== by 0x50C60A3: start_thread (pthread_create.c:309)
==8724== Address 0x5703010 is 320 bytes inside a block of size 584 free'd
==8724== at 0x4C29E90: free (vg_replace_malloc.c:473)
==8724== by 0x4E49021: usrsctp_close (user_socket.c:2086)
==8724== by 0x400A64: main (test.c:54)
==8724==
==8724== Invalid read of size 4
==8724== at 0x4E5744F: sctp_calc_rwnd (sctp_indata.c:86)
==8724== by 0x4E57488: sctp_set_rwnd (sctp_indata.c:64)
==8724== by 0x4E6E44D: sctp_send_sack (sctp_output.c:10877)
==8724== by 0x4E582D4: sctp_process_data (sctp_indata.c:2575)
==8724== by 0x4E69570: sctp_common_input_processing (sctp_input.c:6136)
==8724== by 0x4E45CCE: recv_function_raw (user_recv_thread.c:433)
==8724== by 0x50C60A3: start_thread (pthread_create.c:309)
==8724== Address 0x5703010 is 320 bytes inside a block of size 584 free'd
==8724== at 0x4C29E90: free (vg_replace_malloc.c:473)
==8724== by 0x4E49021: usrsctp_close (user_socket.c:2086)
==8724== by 0x400A64: main (test.c:54)
==8724==
==8724== Invalid read of size 4
==8724== at 0x4E7517D: sctp_med_chunk_output (sctp_output.c:8285)
==8724== by 0x4E79CA2: sctp_chunk_output (sctp_output.c:10513)
==8724== by 0x4E6963C: sctp_common_input_processing (sctp_input.c:6196)
==8724== by 0x4E45CCE: recv_function_raw (user_recv_thread.c:433)
==8724== by 0x50C60A3: start_thread (pthread_create.c:309)
==8724== Address 0x57030b8 is 488 bytes inside a block of size 584 free'd
==8724== at 0x4C29E90: free (vg_replace_malloc.c:473)
==8724== by 0x4E49021: usrsctp_close (user_socket.c:2086)
==8724== by 0x400A64: main (test.c:54)
==8724==
==8724==
==8724== HEAP SUMMARY:
==8724== in use at exit: 448,244 bytes in 409 blocks
==8724== total heap usage: 570 allocs, 161 frees, 530,992 bytes allocated
==8724==
==8724== LEAK SUMMARY:
==8724== definitely lost: 0 bytes in 0 blocks
==8724== indirectly lost: 0 bytes in 0 blocks
==8724== possibly lost: 1,632 bytes in 6 blocks
==8724== still reachable: 446,612 bytes in 403 blocks
==8724== suppressed: 0 bytes in 0 blocks
==8724== Rerun with --leak-check=full to see details of leaked memory
==8724==
==8724== For counts of detected and suppressed errors, rerun with: -v
==8724== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
from usrsctp.
Ahh. Thanks a lot. Didn't know about PTHREAD_MUTEX_ERRORCHECK. I'm just setting up a new Linux VM for debugging this. That shouldn't be to hard to find. I think it even would make sense to add a configure option to use PTHREAD_MUTEX_ERRORCHECK on all mutexes...
from usrsctp.
OK. The problem with the ACCEPT_LOCK is solved. Now I see the same as you:
==22408== Memcheck, a memory error detector
==22408== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22408== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==22408== Command: ./crash
==22408==
In receive_cb
Connections closed
Still in receive_cb
==22408== Thread 3 SCTP/IP4 rcv:
==22408== Invalid read of size 4
==22408== at 0x4589A0: sctp_calc_rwnd (sctp_indata.c:86)
==22408== by 0x4589E4: sctp_set_rwnd (sctp_indata.c:64)
==22408== by 0x416F3B: sctp_send_sack (sctp_output.c:10877)
==22408== by 0x45989E: sctp_process_data (sctp_indata.c:2575)
==22408== by 0x40F376: sctp_common_input_processing (sctp_input.c:6136)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408== Address 0x549f240 is 320 bytes inside a block of size 584 free'd
==22408== at 0x4C2CE2B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x403E30: usrsctp_close (user_socket.c:2087)
==22408== by 0x401741: main (crash.c:54)
==22408== Block was alloc'd at
==22408== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x4019EF: soalloc (user_socket.c:178)
==22408== by 0x4030CF: sonewconn (user_socket.c:445)
==22408== by 0x408112: sctp_handle_cookie_echo (sctp_input.c:2858)
==22408== by 0x40D9DD: sctp_process_control (sctp_input.c:5360)
==22408== by 0x40F2C8: sctp_common_input_processing (sctp_input.c:5996)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408==
==22408== Invalid read of size 4
==22408== at 0x4589AF: sctp_calc_rwnd (sctp_indata.c:86)
==22408== by 0x4589E4: sctp_set_rwnd (sctp_indata.c:64)
==22408== by 0x416F3B: sctp_send_sack (sctp_output.c:10877)
==22408== by 0x45989E: sctp_process_data (sctp_indata.c:2575)
==22408== by 0x40F376: sctp_common_input_processing (sctp_input.c:6136)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408== Address 0x549f240 is 320 bytes inside a block of size 584 free'd
==22408== at 0x4C2CE2B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x403E30: usrsctp_close (user_socket.c:2087)
==22408== by 0x401741: main (crash.c:54)
==22408== Block was alloc'd at
==22408== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x4019EF: soalloc (user_socket.c:178)
==22408== by 0x4030CF: sonewconn (user_socket.c:445)
==22408== by 0x408112: sctp_handle_cookie_echo (sctp_input.c:2858)
==22408== by 0x40D9DD: sctp_process_control (sctp_input.c:5360)
==22408== by 0x40F2C8: sctp_common_input_processing (sctp_input.c:5996)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408==
==22408== Invalid read of size 4
==22408== at 0x41BFC8: sctp_med_chunk_output (sctp_output.c:8285)
==22408== by 0x42092A: sctp_chunk_output (sctp_output.c:10513)
==22408== by 0x40F430: sctp_common_input_processing (sctp_input.c:6196)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408== Address 0x549f2e8 is 488 bytes inside a block of size 584 free'd
==22408== at 0x4C2CE2B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x403E30: usrsctp_close (user_socket.c:2087)
==22408== by 0x401741: main (crash.c:54)
==22408== Block was alloc'd at
==22408== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22408== by 0x4019EF: soalloc (user_socket.c:178)
==22408== by 0x4030CF: sonewconn (user_socket.c:445)
==22408== by 0x408112: sctp_handle_cookie_echo (sctp_input.c:2858)
==22408== by 0x40D9DD: sctp_process_control (sctp_input.c:5360)
==22408== by 0x40F2C8: sctp_common_input_processing (sctp_input.c:5996)
==22408== by 0x44BBBE: recv_function_raw (user_recv_thread.c:433)
==22408== by 0x4E3F6A9: start_thread (pthread_create.c:333)
==22408==
==22408==
==22408== HEAP SUMMARY:
==22408== in use at exit: 449,800 bytes in 410 blocks
==22408== total heap usage: 571 allocs, 161 frees, 531,488 bytes allocated
==22408==
==22408== LEAK SUMMARY:
==22408== definitely lost: 0 bytes in 0 blocks
==22408== indirectly lost: 0 bytes in 0 blocks
==22408== possibly lost: 3,360 bytes in 6 blocks
==22408== still reachable: 446,440 bytes in 404 blocks
==22408== suppressed: 0 bytes in 0 blocks
==22408== Rerun with --leak-check=full to see details of leaked memory
==22408==
==22408== For counts of detected and suppressed errors, rerun with: -v
==22408== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
from usrsctp.
Related Issues (20)
- Windows | Expected Throughput HOT 4
- Is usrsctp_conninput threadsafe? HOT 2
- Deadlock: usrsctp_conninput and user_sctp_timer_iterate HOT 3
- On SCTP_NOTIFY_ASSOC_DOWN, the receive callback (recv_callback) gets called with zero information HOT 4
- Suddenly, the unsent data size becomes zero. Why? HOT 15
- How to port to a new platform? HOT 2
- SCTP multihoming: Source address selection based on destination route entry
- High CPU Load durring datatransfer HOT 2
- pkg-config file is broken when CMAKE_INSTALL_{INCLUDE,LIB}DIR is absolute
- WiFI issue
- TRASHIT() macro should set pointer to NULL in usrsctplib/user_queue.h HOT 1
- No netinet6/ip6protosw.h on FreeBSD 14 HOT 1
- How to sent each chunks immediately when it is available in the server
- What the meaning of xxx_upcall?
- sample program echo_server response abort message HOT 3
- building fails at warning about parentheses: HOT 7
- CVE-2022-46871 impact on libusrsctp HOT 1
- Aborted with sctp_timeout_handler: tmr->self corrupted, but tmr->self is null in the core dump HOT 6
- Aborted with sodealloc(): so_count -58769387 -- suspected use-after-free in sctp_timeout_handler HOT 2
- Broken build on macOS 13.4 (apple sillicon) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from usrsctp.