Closed Bug 32395 Opened 25 years ago Closed 25 years ago

5K memory leak regression on tinderbox

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: ruslan)

Details

(Keywords: memory-leak, regression)

DESCRIPTION: The tinderbox leak stats went up 5K (16K to 21K) due to the checkin by ruslan@netscape.com at 2000-03-18 10:39. I'm filing this as a bug so it doesn't get forgotten. The new leaks are as follows: TOTAL 21176 28.28% 23274603 -0.03% --NEW-LEAKS-------------------------------- nsStdURL 8 - LocationImpl 28 - nsDSURIContentListen 24 - nsJSContext 44 - nsPluginHostImpl 208 - nsDocumentOpenInfo 52 - nsFtpProtocolHandler 132 - nsFtpConnectionThrea 1028 - nsProxyEventClass 72 - nsStdURLParser 12 - nsProxyEventObject 376 - nsDocShell 232 - nsScriptNameSpaceMan 16 - nsAuthURLParser 12 - ImageRendererImpl 12 - nsLoadCookie 28 - nsDeviceContextGTK 124 - nsProxyObject 56 - nsProtocolProxyServi 56 - nsFTPChannel 208 - nsSocketTransport 632 105.19% nsDocLoaderImpl 176 100.00% GlobalWindowImpl 384 100.00% nsLocalFile 348 50.00% nsLoadGroup 12 50.00% nsInterfaceInfo 112 33.33% nsStr 3320 26.72% nsRegionGTK 200 25.00% nsBaseWidget 1120 25.00% nsVoidArray 400 19.05% nsSupportsArray 1000 19.05% TOTAL 10432 The root of the problem *seems* to relate to an nsFtpConnectionThread. It used to be released by nsThreadPoolRunnable::Run() like this (it's a refcount balancer log): -1 pthread_detach+0x00000471 -1 PR_Select+0x00000723 -1 nsThread::Main(void *)+0x000000BF 0 nsThreadPoolRunnable::Run(void)+0x00000091 | 1 nsThreadPool::GetRequest(void)+0x0000020C | | 1 nsSupportsArray::ElementAt(unsigned int)+0x00000043 | | 1 nsFtpConnectionThread::AddRef(void)+0x00000069 | -1 nsThreadPool::GetRequest(void)+0x00000278 | -1 nsSupportsArray::RemoveElementAt(unsigned int)+0x00000054 | -1 nsFtpConnectionThread::Release(void)+0x00000065 -1 nsThreadPoolRunnable::Run(void)+0x0000019B -1 nsFtpConnectionThread::Release(void)+0x00000065 but now all that happens is this: 0 pthread_detach+0x00000471 0 PR_Select+0x00000723 0 nsThread::Main(void *)+0x000000BF 0 nsThreadPoolRunnable::Run(void)+0x00000091 1 nsThreadPool::GetRequest(void)+0x0000020C | 1 nsSupportsArray::ElementAt(unsigned int)+0x00000043 | 1 nsFtpConnectionThread::AddRef(void)+0x00000069 -1 nsThreadPool::GetRequest(void)+0x00000278 -1 nsSupportsArray::RemoveElementAt(unsigned int)+0x00000054 -1 nsFtpConnectionThread::Release(void)+0x00000065 I think this nsFtpConnectionThread owns an nsFtpProtocolHandler which owns an nsFTPChannel which leaks a reference or two to an nsDocShell. However, there are three leaked references to the nsDocShell, so I'm not completely sure that's the root problem, and I certainly don't see what's causing it.
Keywords: mlk, regression
Fixed. A small change in behavior of setreuseconnection had caused ftphandler tp leak. Thanks for the quick catch.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified fixed: TOTAL 14936 -23.84% 23272986 0.02% --FIXED-LEAKS------------------------------ nsSupportsArray 840 -16.00% nsBaseWidget 896 -20.00% nsRegionGTK 160 -20.00% nsStr 2620 -21.08% nsVoidArray 288 -21.74% nsInterfaceInfo 84 -25.00% nsLoadGroup 8 -33.33% nsLocalFile 232 -33.33% GlobalWindowImpl 192 -50.00% nsSocketTransport 316 -50.00% nsDocLoaderImpl 88 -50.00% nsProxyEventClass 0 -100.00% nsJSContext 0 -100.00% nsFtpConnectionThrea 0 -100.00% nsProxyEventObject 0 -100.00% nsStdURL 0 -100.00% nsFTPChannel 0 -100.00% nsStdURLParser 0 -100.00% nsDocumentOpenInfo 0 -100.00% ImageRendererImpl 0 -100.00% nsScriptNameSpaceMan 0 -100.00% nsDocShell 0 -100.00% nsAuthURLParser 0 -100.00% nsPluginHostImpl 0 -100.00% nsProtocolProxyServi 0 -100.00% LocationImpl 0 -100.00% nsDSURIContentListen 0 -100.00% nsLoadCookie 0 -100.00% nsFtpProtocolHandler 0 -100.00% nsDeviceContextGTK 0 -100.00% nsProxyObject 0 -100.00% TOTAL 5724
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.