From: Kevin P. Fleming Date: Thu, 27 Dec 2007 01:03:16 +0000 (+0000) Subject: Merged revisions 94824 via svnmerge from X-Git-Tag: 1.6.0-beta1~286 X-Git-Url: http://git.asterisk.org/gitweb/?p=asterisk%2Fasterisk.git;a=commitdiff_plain;h=d756129b1d84a7ba95ab561af05ed55dd1ec5067;ds=sidebyside Merged revisions 94824 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r94824 | kpfleming | 2007-12-26 18:01:47 -0700 (Wed, 26 Dec 2007) | 2 lines make this comment explain the situation in an even more explicit fashion ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94825 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- diff --git a/main/manager.c b/main/manager.c index 56584fa..30e5247 100644 --- a/main/manager.c +++ b/main/manager.c @@ -2590,11 +2590,17 @@ static void *session_do(void *data) ast_log(LOG_EVENT, "Failed attempt from %s\n", ast_inet_ntoa(s->sin.sin_addr)); } - /* If the entire session occurs in a single context switch, then it's - * possible to get an unsafe memory condition by free()ing the memory - * before letting other threads run at least once. This actually seems - * like a workaround for a glibc bug. - */ + /* It is possible under certain circumstances for this session thread + to complete its work and exit *before* the thread that created it + has finished executing the ast_pthread_create_background() function. + If this occurs, some versions of glibc appear to act in a buggy + fashion and attempt to write data into memory that it thinks belongs + to the thread but is in fact not owned by the thread (or may have + been freed completely). + + Causing this thread to yield to other threads at least one time + appears to work around this bug. + */ usleep(1); destroy_session(s);