[asterisk-commits] kpfleming: trunk r94825 - in /trunk: ./ main/manager.c

[SVN commits to the Asterisk project]

Author: kpfleming
Date: Wed Dec 26 19:03:16 2007
New Revision: 94825

URL: http://svn.digium.com/view/asterisk?view=rev&rev=94825
Log:
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

........

Modified:
    trunk/   (props changed)
    trunk/main/manager.c

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.4-merged' - no diff available.

Modified: trunk/main/manager.c
URL: http://svn.digium.com/view/asterisk/trunk/main/manager.c?view=diff&rev=94825&r1=94824&r2=94825
==============================================================================
--- trunk/main/manager.c (original)
+++ trunk/main/manager.c Wed Dec 26 19:03:16 2007
@@ -2590,11 +2590,17 @@
 		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);