aboutsummaryrefslogtreecommitdiffstats
path: root/res
diff options
context:
space:
mode:
authorrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2009-03-27 02:25:31 +0000
committerrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2009-03-27 02:25:31 +0000
commit4191eb75896b913e25a121aab1539345b907f16b (patch)
treefe388b00a7e1cc7d6b869dcc1af4fe0a05f4d66b /res
parentf1bfb6a0a6415e38a888492007672b194b3b1254 (diff)
Merged revisions 184531 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk ........ r184531 | russell | 2009-03-26 21:20:23 -0500 (Thu, 26 Mar 2009) | 20 lines Fix some issues with rwlock corruption that caused deadlock like symptoms. When dvossel and I were doing some load testing last week, we noticed that we could make Asterisk trunk lock up instantly when we started generating a bunch of calls. The backtraces of locked threads were bizarre, and many were stuck on an _unlock_ of an rwlock. The changes are: 1) Fix a number of places where a backtrace would be loaded into an invalid index of the backtrace array. It's an off by one error, which ends up writing over the rwlock itself. 2) Ensure that in the array of held locks, we NULL out an index once it is not being used so that it's not confusing when analyzing its contents. 3) Remove a bunch of logging referring to an rwlock operating being done with "deep reentrancy". It is normal for _many_ threads to hold a read lock on an rwlock. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@184547 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'res')
0 files changed, 0 insertions, 0 deletions