64000 - localstore.rdf not flushed when I only use mail.

Status: RESOLVED WORKSFORME

(Core Graveyard :: RDF, defect, P1)

Description

[(not reading, please use [e-mail] instead)]

egads, this looks bad.

while working on bug #63853 (persisting "View | Message | Unread") I noticed
that if I launched mail alone, did stuff that should cause changes to
localstore.rdf, and quit, localstore.rdf did not get updated on disk.

if I launched mail and then browser, did stuff that should cause changes to
localstore.rdf, quit mail and then quit the browser, localstore.rdf got updated
on disk.

I'll investigate.

Comment 1

[(not reading, please use [e-mail] instead)]

here's what it looks like so far:

for the localstore datasource we never call, RDFXMLDataSourceImpl::Flush()
because we never call RDFXMLDataSourceImpl::~RDFXMLDataSourceImpl() because we
are leaking it.  

probably something we are doing in mailnews.

I'm continuing to investigate.

Comment 2

[(not reading, please use [e-mail] instead)]

I've used the ref count balancer to see which RDFXMLDataSourceImpl objects are
leaking.

I attached the balance trees.

Comment 3

[(not reading, please use [e-mail] instead)]

Attachment: tree for object #1

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: tree for object #2

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: tree for object #3

Comment 6

[(not reading, please use [e-mail] instead)]

I was only watching RDFXMLDataSourceImpl, I'm not sure how nsMemoryImpl showed
up when I ran find-leakers.pl (see tree for object #2).

when I check for leaks when just using the browser, I still get a leaked
nsMemoryImply, but the other two leaks are not there.

Comment 7

[Chris Waterson]

Look for the leaking nsXULDocument, Luke.

Comment 8

[(not reading, please use [e-mail] instead)]

thanks for the tip, waterson.

I'm off to find the leaking nsXULDocument.

adding leak master dbaron to the cc list.

add bienvenu to the cc list, to keep him in the loop.

accepting.

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It sounds bad that you depend on destructors to do something important.

Leaking |nsXULDocument|s sound bad.  I'm tired of dealing with them, because
it's too often circularity through JS (lately involving XBL rather than
anonymous content), and nearly impossible to debug.  And we leak them all over
the place...

What does the leak log (XPCOM_MEM_LEAK_LOG) look like?

Comment 10

[(not reading, please use [e-mail] instead)]

this is p1 bad, in my book.

Comment 11

[scottputterman]

adding nsbeta1+ to this.

I agree with dbaron. We've changed lost of code in the past in mailnews to not
depend on destructors.  Is there anyway we can change it so that localstore.rdf
gets saved on shutdown regardless of whether a destructor is hit?  Finding the
leak is still good to. I'm sure this causes us to leak lots of other things.

Comment 12

[scottputterman]

moving to mozilla0.9

Comment 13

[scottputterman]

marking nsbeta1- and moving to future milestone.

Comment 14

[(not reading, please use [e-mail] instead)]

varada, I've got a hunch this leak might be a missing RemoveDataSource() call.

Comment 15

[Chase Tingley]

Oddly, WFM 2001093021 Linux.  If I run just -mail, I can resize the window,
toggle visibility of the sidebar, etc., and the changes seem to get written back
out.  

Comment 16

[Jerome Lacoste]

I tried this one with build 2002101015 on windows NT4. 
No problem for me.
As I also see that a user seems to have no problem on Linux, could this be that
this bug got solved by another checkin?
This bug is old, might be the case. 

sspitzer, can you double check?

Comment 17

[Jerome Lacoste]

I tried this one with build 2002101015 on windows NT4. 
No problem for me.
As I also see that a user seems to have no problem on Linux, could this be that
this bug got solved by another checkin?
This bug is old, might be the case. 

sspitzer, can you double check?

Comment 18

[benc]

tever is not RDF QA anymore

Comment 19

[Chase Tingley]

Still working on the trunk.

Closing as WFM.