New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users
Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
sctp socket still got polling by timer thread even if it is closed
Reported by heguo....@gmail.com, Aug 22 2014 Back to list
What steps will reproduce the problem?
1. when receive SCTP_CANT_STR_ASSOC
2. sctp_close(socket)
3.user_sctp_timer_iterate still hava a timer on it

What is the expected result?
when socket is closed, user_sctp_timer_iterate should not have a timer on it

What do you see instead?


What version of the product are you using? On what operating system?
linux, latest webrtc as the time of writing

Please provide any additional information below.
everything is working fine, however, when i used valgrind to detect memory problems, found out user_sctp_timer_iterate still have a timer on it which is already closed.

this is critical, could lead to program crash.

below is first part of valgrind log, full log is attached.

==7400== Memcheck, a memory error detector
==7400== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==7400== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==7400== Command: ./ms
==7400== Parent PID: 19544
==7400==
==7400== Thread 8:
==7400== Invalid read of size 4
==7400==    at 0x5331394: pthread_mutex_lock (pthread_mutex_lock.c:50)
==7400==    by 0x4AD12E: sctp_notify_assoc_change (sctputil.c:2800)
==7400==    by 0x4AF1F8: sctp_abort_an_association (sctputil.c:4185)
==7400==    by 0x49C572: sctp_threshold_management (sctp_timer.c:167)
==7400==    by 0x49DE8E: sctp_t1init_timer (sctp_timer.c:1004)
==7400==    by 0x4AFB02: sctp_timeout_handler (sctputil.c:1702)
==7400==    by 0x4B4BB9: user_sctp_timer_iterate (user_sctp_timer_iterate.c:88)
==7400==    by 0x532ED8B: start_thread (pthread_create.c:304)
==7400==    by 0x620004C: clone (clone.S:112)
==7400==  Address 0x722c578 is 248 bytes inside a block of size 584 free'd
==7400==    at 0x4C282ED: free (vg_replace_malloc.c:366)
==7400==    by 0x46AA90: SCTPDataChannel::CloseSCTPSocket() (SCTPDataChannel.cpp:569)
==7400==    by 0x46C188: SCTPDataChannel::Disconnect() (SCTPDataChannel.cpp:100)
==7400==    by 0x46C1B6: SCTPDataChannel::~SCTPDataChannel() (SCTPDataChannel.cpp:58)
==7400==    by 0x46C228: SCTPDataChannel::~SCTPDataChannel() (SCTPDataChannel.cpp:63)
==7400==    by 0x4651CF: SCTPServer::OnSCTPCallbackMessage(Message*) (SCTPServer.cpp:491)
==7400==    by 0x4678BA: SCTPServer::ProcessLoop() (SCTPServer.cpp:1156)
==7400==    by 0x4716E1: webrtc::ThreadLinux::Run() (thread_linux.cc:310)
==7400==    by 0x4717D8: StartThread (thread_linux.cc:33)
==7400==    by 0x532ED8B: start_thread (pthread_create.c:304)
==7400==    by 0x620004C: clone (clone.S:112)
==7400==
==7400== Invalid read of size 4
==7400==    at 0x5330DA9: __pthread_mutex_lock_full (pthread_mutex_lock.c:139)
==7400==    by 0x4AD12E: sctp_notify_assoc_change (sctputil.c:2800)
==7400==    by 0x4AF1F8: sctp_abort_an_association (sctputil.c:4185)
==7400==    by 0x49C572: sctp_threshold_management (sctp_timer.c:167)
==7400==    by 0x49DE8E: sctp_t1init_timer (sctp_timer.c:1004)
==7400==    by 0x4AFB02: sctp_timeout_handler (sctputil.c:1702)
==7400==    by 0x4B4BB9: user_sctp_timer_iterate (user_sctp_timer_iterate.c:88)
==7400==    by 0x532ED8B: start_thread (pthread_create.c:304)
==7400==    by 0x620004C: clone (clone.S:112)
==7400==  Address 0x722c578 is 248 bytes inside a block of size 584 free'd
==7400==    at 0x4C282ED: free (vg_replace_malloc.c:366)
==7400==    by 0x46AA90: SCTPDataChannel::CloseSCTPSocket() (SCTPDataChannel.cpp:569)
==7400==    by 0x46C188: SCTPDataChannel::Disconnect() (SCTPDataChannel.cpp:100)
==7400==    by 0x46C1B6: SCTPDataChannel::~SCTPDataChannel() (SCTPDataChannel.cpp:58)
==7400==    by 0x46C228: SCTPDataChannel::~SCTPDataChannel() (SCTPDataChannel.cpp:63)
==7400==    by 0x4651CF: SCTPServer::OnSCTPCallbackMessage(Message*) (SCTPServer.cpp:491)
==7400==    by 0x4678BA: SCTPServer::ProcessLoop() (SCTPServer.cpp:1156)
==7400==    by 0x4716E1: webrtc::ThreadLinux::Run() (thread_linux.cc:310)
==7400==    by 0x4717D8: StartThread (thread_linux.cc:33)
==7400==    by 0x532ED8B: start_thread (pthread_create.c:304)




 
valgrind.txt
26.2 KB View Download
Project Member Comment 1 by juberti@webrtc.org, Aug 25 2014
Cc: jiayl@webrtc.org
Labels: Mstone-39
Owner: lally@webrtc.org
Comment 2 by lally@webrtc.org, Aug 29 2014
Status: Assigned
Eeesh.  I'll have a look.
I will upload my test program source code when I simplify the code. if i disable LINGER, the application will crash. I think it is socket lifetime issue, after close, the timer thread still process on deleted object. really thank webrtc team to look at it 
Hi la, I attached sctp client test source code. inside tar file, valgrind.txt is included.

executable sctp_test can run on ubuntu 11.04, 
valgrind --leak-check=full --show-reachable=yes --trace-children=yes --log-file=valgrind.txt ./sctp_test

run a few times, memory problem can occur.
what this test is trying to do is that when SCTP_CANT_STR_ASSOC is received, another thread (main thread for demo) will close sctp socket by using usrsctp_close, however, sometimes sctp timer thread still read/write this DELETED socket, leads to application crash.

steps to compile the source manually:
1). compile each .cpp file
g++ -I. -I/home/webrtc/webrtc_0608_2014/trunk -I/home/webrtc/webrtc_0608_2014/trunk/webrtc -I/home/webrtc/webrtc_0608_2014/trunk/third_party/usrsctp/usrsctplib -DPOSIX -fno-rtti -pthread -fPIC -g -O0 -c main.cpp

where /home/webrtc/webrtc_0608_2014/ is webrtc source tree, replace with whatever version you use.

do the same for SCTPDataEngine.cpp and SCTPDataChannel.cpp

2). link
g++ -L. -o sctp_test main.o SCTPDataChannel.o SCTPDataEngine.o -lsystem_wrappers -lusrsctplib  -pthread -lrt -lpthread

where system_wrappers and usrsctplib are copied over from webrtc out directory.

command to do memory check:
valgrind --leak-check=full --show-reachable=yes --trace-children=yes --log-file=valgrind.txt ./sctp_test

please reproduce the problem, let me know if need my help.
this problem is too critical, prevent me using it.

really really thanks


sctp_client_test.tar.gz
1.1 MB Download
Project Member Comment 5 by ldixon@webrtc.org, Sep 4 2014
Labels: SCTP
Comment 6 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Network
Comment 7 by vrk@webrtc.org, Nov 3 2014
Labels: -Mstone-39 Mstone-41 EngTriaged
Project Member Comment 8 by pthatcher@webrtc.org, Jan 7 2015
Labels: -Mstone-41 Mstone-42
Project Member Comment 9 by pthatcher@webrtc.org, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 10 by tnakamura@webrtc.org, Jan 29 2016
Cc: pthatcher@webrtc.org
Labels: -Mstone-44
heguo.qin@, do you know if this problem is still present? I don't see any CLs linked to this bug, so I don't think it's been fixed, but it would be nice if you could confirm.

I'm also removing the milestone label since this bug hasn't been updated in quite some time.
Project Member Comment 11 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Project Member Comment 12 by kjellander@webrtc.org, Dec 1 2016
Owner: ----
Status: Available
Removing lally@webrtc.org since he left Google a while ago.
Sign in to add a comment