MLK: nsPluginHostImpl::ScanPluginsDirectory()

VERIFIED FIXED in Future

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Bruce Mitchener, Assigned: av (gone))

Tracking

({memory-leak})

Trunk
Future
x86
Linux
memory-leak
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
In nsPluginHostImpl::ScanPluginsDirectory(), it does:

nsPluginInfo info = { sizeof(info) };
nsresult res = pluginFile.GetPluginInfo(info);

At least on Unix, the GetPluginInfo method allocates memory, which is not 
subsequently freed in this code.

The info struct is passed into the constructor of a nsPluginTag, which copies 
the memory.

Cc'ing valeski so that someone who is more on top of leaks than I am currently 
is aware of it.
(Reporter)

Updated

18 years ago
Keywords: mlk
(Assignee)

Comment 1

18 years ago
bruce wrote:
>The info struct is passed into the constructor of a nsPluginTag, which copies 
>the memory.

After which pluginFile.FreePluginInfo(info) is called. Are you saying it does 
not do the job on Unix?
(Reporter)

Comment 2

18 years ago
Thanks for making me look at this closer. I should've seen this the first time. 
:)

The 3 allocations that leak are the lines:

219     info.fMimeTypeArray =(char **)PR_Malloc(num * sizeof(char *));
220     info.fMimeDescriptionArray =(char **)PR_Malloc(num * sizeof(char *));
221     info.fExtensionArray =(char **)PR_Malloc(num * sizeof(char *));

The FreePluginInfo() method does indeed free up most of the memory, but it fails 
to free the actual arrays themselves. (It handles their contents just fine.)

Looking at all of the other nsPluginFile implementations, this leak does not 
happen on OS/2, MacOS, or Windows.  I feel ill after just looking at the BeOS 
implementation (it doesn't deallocate anything!).

So, this looks to be unix only, and a separate bug ought to be filed on the BeOS 
people's implementation since it is a larger problem.  I'll file that one now.

To fix this, you just need something like:
PR_Free(info.fMimeTypeArray);
PR_Free(info.fMimeDescriptionArray);
PR_Free(info.fExtensionArray);

after the for loop.
OS: All → Linux
Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.
Target Milestone: --- → Future
(Assignee)

Comment 4

17 years ago
Looks like it is fixed now.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 5

17 years ago
marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.