Status

()

Core
X-remote
P3
normal
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: bz, Assigned: dbaron)

Tracking

({memory-leak})

Trunk
x86
Linux
memory-leak
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STEPS TO REPRODUCE:

1) Try to debug string buffer leaks
2) Come out with the following stack:

n/a     .root
  1       __libc_start_main+0x000000D3  (/lib/tls/libc.so.6)
    1       main (../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1750)
      1       main1 (../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1227)
        1       nsGTKRemoteService::Startup(char const*, char const*) (../../../../mozilla/toolkit/components/remote/nsGTKRemoteService.cpp:121)
          1       nsCString::operator=(char const*) (../../../dist/include/string/nsTString.h:118)
            1       nsCSubstring::Assign(char const*, unsigned int) (../../../../mozilla/xpcom/string/src/nsTSubstring.cpp:318)
              1       nsCSubstring::ReplacePrep(unsigned int, unsigned int, unsigned int) (../../../../mozilla/xpcom/string/src/nsTSubstring.cpp:192)
                1       nsCSubstring::MutatePrep(unsigned int, char**, unsigned int*) (../../../../mozilla/xpcom/string/src/nsTSubstring.cpp:145)
                  1       nsStringBuffer::Alloc(unsigned int) (../../../../mozilla/xpcom/string/src/nsSubstring.cpp:213)
                    1       NS_LogAddRef_P (../../../mozilla/xpcom/base/nsTraceRefcntImpl.cpp:1012)

3) Figure out that nsGTKRemoteService and all its strings are leaking.
FWIW, I plan to check in the string buffer leak logging soon, so this will be showing up on tinderbox leak tests too.
Keywords: mlk
Flags: blocking1.9a2?

Comment 2

12 years ago
Is this SM-only? And are you checking for leaks at XPCOM shutdown or when NS_LogTerm is called?
> Is this SM-only?

Firefox leaks so many strings through shutdown that I can't do what I did for Seamonkey (which was just look at the two strings that leaked), and nsGtkRemoteService doesn't do addref/release logging, so it's hard to check that it got leaked directly.

All that said, I see absolutely no way that the nsGtkRemoteService destructor could get called.  Do you?  So if it ever gets created, it leaks.

And I'm checking for leaks by looking at the XPCOM_MEM_LEAK_LOG output file, whenever that gets written out.

Comment 4

12 years ago
Well hrm... we're not leaking the gtkremoteservice (because it's a static singleton), but it does have two string members. That's not so good, I wonder why I let that happen; I've only intended to use static singletons for classes without any members.
Yeah, I care about the string leaks more than about the service itself.

Updated

12 years ago
Priority: -- → P3
Flags: blocking1.9a2? → blocking1.9-
Created attachment 270512 [details] [diff] [review]
patch

Not sure why you think it's static -- it has a standard generic factory constructor like other services, but its refcounting methods aren't implemented.
Attachment #270512 - Flags: review?(benjamin)

Comment 7

11 years ago
Comment on attachment 270512 [details] [diff] [review]
patch

Huh. I'm pretty sure I meant to make it static... I wonder whether this will cause problems; let's try it.
Attachment #270512 - Flags: review?(benjamin) → review+

Updated

11 years ago
Duplicate of this bug: 386008

Updated

10 years ago
Keywords: checkin-needed
Whiteboard: [checkin to mozilla-central when it's open]
Would rather wait until mozilla-central instead of getting approval for 1.9 for this leak fix?
Assignee: benjamin → dbaron
Checked in to trunk, 2007-07-03 14:21 -0700.

(I just forgot to mark it fixed.)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [checkin to mozilla-central when it's open]
You need to log in before you can comment on or make changes to this bug.