35180 - charset menu and its in-memory datasource

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect, P3)

Description

[Bruce Mitchener]

Inverting beard's leak tool shows that this in-memory data source is still in-
memory at exit.  Why? Do we dynamically regenerate the menus everytime someone 
looks at them?  Do we cache the generated menus? Can we unload this datasource 
once the menus are created?

Is this XP behavior?  I'm marking it Mac-only at the moment.

malloc
operator new(unsigned long, const std::nothrow_t&)
operator new(unsigned long)
NS_NewRDFInMemoryDataSource(nsISupports*, const nsID&, void**)
nsGenericFactory::CreateInstance(nsISupports*, const nsID&, void**)
nsComponentManagerImpl::CreateInstance(const nsID&, nsISupports*, const nsID&, 
void**)
nsComponentManager::CreateInstance(const nsID&, nsISupports*, const nsID&, void**
)
nsCharsetMenu::Init()
nsCharsetMenu::nsCharsetMenu()
NS_NewCharsetMenu(nsISupports*, const nsID&, void**)
nsGenericFactory::CreateInstance(nsISupports*, const nsID&, void**)
nsComponentManagerImpl::CreateInstance(const nsID&, nsISupports*, const nsID&, 
void**)
nsComponentManager::CreateInstance(const nsID&, nsISupports*, const nsID&, void**
)
nsServiceManagerImpl::GetService(const nsID&, const nsID&, nsISupports**, 
nsIShutdownListener*)
nsServiceManagerImpl::GetService(const char*, const nsID&, nsISupports**, 
nsIShutdownListener*)
nsServiceManager::GetService(const char*, const nsID&, nsISupports**, 
nsIShutdownListener*)
RDFServiceImpl::GetDataSource(const char*, nsIRDFDataSource**)
nsXULDocument::CheckTemplateBuilder(nsIContent*)
nsXULDocument::ResumeWalk()
nsXULDocument::OnStreamComplete(nsIStreamLoader*, nsISupports*, unsigned int, 
unsigned int, const char*)
nsStreamLoader::OnStopRequest(nsIChannel*, nsISupports*, unsigned int, const 
unsigned short*)
nsResChannel::EndRequest(unsigned int, const unsigned short*)
nsResChannel::OnStopRequest(nsIChannel*, nsISupports*, unsigned int, const 
unsigned short*)
nsFileChannel::OnStopRequest(nsIChannel*, nsISupports*, unsigned int, const 
unsigned short*)
nsOnStopRequestEvent::HandleEvent()
nsStreamListenerEvent::HandlePLEvent(PLEvent*)
PL_HandleEvent
PL_ProcessPendingEvents
nsEventQueueImpl::ProcessPendingEvents()
nsMacNSPREventQueueHandler::ProcessPLEventQueue()

Comment 1

[saari (gone)]

The mac doesn't destroy a generated menu until you look at a different one (I 
can't thanks to MacOS menu manager design). So if you just looked at the charset 
menu and shutdown via a key combo, I'm not surprised you see this. If you never 
opened the charset menu, or opened a different menu after it, then there is 
something else going on.

Comment 2

[saari (gone)]

After talking with bruce and pav it looks like this is not related to menus but
the component itself.

Comment 3

[Frank Tang]

bruce, it is not clear from the bug rereport what is the *expecting behavior*. 
Is the problem that we leak the data source ?

cata- this is your code. Please take a look at it and discuss with waterson and 
bruce. Thanks.

Comment 4

[Bruce Mitchener]

There are multiple issues: 1) the datasource isn't freed up before exit. 2) it 
is in memory at all: Why does it need to be? Does the charset menu change?  Can 
we only have the datasource in memory while generating the menu rather than 
leave it loaded all the time, consuming RAM?

Ideally, this datasource would only be loaded when absolutely necessary and then 
unloaded right after that.

Comment 5

[sairuh (rarely reading bugmail)]

->teruko for qa.

Comment 6

[cata]

Answers:

1) The in memory datasource *is* being freed upon exit. The destructor calls the 
Done() method, which has the line:
NS_IF_RELEASE(mInner);

So we can only leak that if we leak the whole nsCharsetMenu object. Is that the 
case?

2) Yes, the charset menu changes. Some of its items are a cache of the most 
recently encountered character sets.

So, please let me know if you have any concrete suggestions on improving this 
code. I am working on it right now and I could go ahead and implement them.

Other than that, I don't really know what to do with this bug...

Comment 7

[Frank Tang]

valeski- do you can need this for embedding ?

Comment 8

[Frank Tang]

bstell, please take the lead to look at this and talk to cata about this. mark 
it as M21 for now.

Comment 9

[Frank Tang]

Change it to M22

Comment 10

[Steve Dagley]

So did M22 turn into future?  Can we get a more up to date prognosis on this bug?

Comment 11

[kill this account]

--> ftang

Comment 12

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 13

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 14

[Martin Creutziger [:MMx]]

Because we are not working on anything dealing with old Mac since 1.3.1 anymore,
I mark this "WONTFIX".
In case that it reoccurs in MacOS X, please file a new bug or reopen *and* move
this one to MacOS X.