Re: Firefox 1.5 memory leaks
L. David Baron
working on one-laptop-per-child [1]) found that there's a *huge* leak
when accessibility is enabled:
https://bugzilla.mozilla.org/show_bug.cgi?id=330624
I'm wondering if this could be contributing to the reports of huge
memory leaks that we're getting with Firefox 1.5. I'd be interested in
knowing answers to the following:
* How can a user tell if Mozilla's accessibility code is enabled for
them? (Preferably in a way that doesn't depend on assuming that the
code that determines whether to enable it is correct.)
* If it is enabled, how can a user turn it off to test the effects of
disabling it?
(In GNOME, what triggers turning on Mozilla's accessibility code is the
preference Desktop -> Preferences -> Accessibility -> Assistive
Techology Support -> Enable assistive technologies. Changing it
requires logging out of GNOME and back in.)
Without knowing the answers to those (and I've poked around a little,
and they don't seem obvious), it's hard to know if this leak could be a
significant part of the reports of huge leaks in Firefox 1.5.
If, in fact, more of our users have this code enabled than we thought,
I'm wondering if release drivers should be more conservative about
approving accessibility fixes during release freezes on the basis that
they only affect users who use screen readers, magnifiers, etc. In
fact, I'm suspicious of such reasoning even if those are the only users
affected, since they deserve the stability that comes from gradually
restricting what can be checked in just as much as other users do.
-David
[1] https://www.redhat.com/archives/olpc-software/2006-March/msg00115.html
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Aaron Leventhal
Thank you for investigating this. I'm CC'ing Ginn Chen from Sun. His
team in Beijing wrote this code. Ginn, will your team be able to look at
this high priority bug? My new guys who will be working on Linux
accessibility haven't started yet.
I believe this is only a problem on Linux. First, the AppRootAccessible
object only exists on Linux. Secondly, the accessibility architecture on
Windows allows us to only create accessible objects if there is an
assistive technology asking for them. We don't even load that
accessibility code at all unless we need it there. On Linux it's not so
smooth. Everything needs to be set up via desktop prefs so it's all or
nothing.
Also, on OS X we never initialize accessibility.
David, are the huge leak reports happening on all platforms?
- Aaron
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>
T. V. Raman
David,
I believe that there are GNOME environment variables that also
influece what access APIs get enabled at the GNOME level, and
Firefox may also be triggering the loading the corresponding
access hooks based on that.
I agree with you that the accessibility code should receive more
attention from the mainstream rather than being set aside as
"that is only used by a small number of users" --- if nothing
else,
that would potentially lead the access code over time becoming
an interesting source of security attacks.
--Raman
>>>>> "L" == L David Baron <dba...@dbaron.org> writes:
L> I recently (thanks to the X pixmap measurements of some of
L> the folks working on one-laptop-per-child [1]) found that
L> there's a *huge* leak when accessibility is enabled:
L>
L> https://bugzilla.mozilla.org/show_bug.cgi?id=330624
L>
L> I'm wondering if this could be contributing to the reports
L> of huge memory leaks that we're getting with Firefox 1.5.
L> I'd be interested in knowing answers to the following:
L>
L> * How can a user tell if Mozilla's accessibility code is
L> enabled for them? (Preferably in a way that doesn't
L> depend on assuming that the code that determines whether
L> to enable it is correct.)
L>
L> * If it is enabled, how can a user turn it off to test
L> the effects of disabling it?
L>
L> (In GNOME, what triggers turning on Mozilla's
L> accessibility code is the preference Desktop ->
L> Preferences -> Accessibility -> Assistive Techology
L> Support -> Enable assistive technologies. Changing it
L> requires logging out of GNOME and back in.)
L>
L> Without knowing the answers to those (and I've poked
L> around a little, and they don't seem obvious), it's hard
L> to know if this leak could be a significant part of the
L> reports of huge leaks in Firefox 1.5.
L>
L> If, in fact, more of our users have this code enabled than
L> we thought, I'm wondering if release drivers should be
L> more conservative about approving accessibility fixes
L> during release freezes on the basis that they only affect
L> users who use screen readers, magnifiers, etc. In fact,
L> I'm suspicious of such reasoning even if those are the
L> only users affected, since they deserve the stability that
L> comes from gradually restricting what can be checked in
L> just as much as other users do.
L>
L> -David
L>
L> [1]
L> https://www.redhat.com/archives/olpc-software/2006-March/msg00115.html
L>
L> -- L. David Baron <URL: http://dbaron.org/ > Technical
L> Lead, Layout & CSS, Mozilla Corporation
L> _______________________________________________
L> dev-accessibility mailing list
L> dev-acce...@lists.mozilla.org
L> https://lists.mozilla.org/listinfo/dev-accessibility
--
Best Regards,
--raman
Email: ra...@users.sf.net
WWW: http://emacspeak.sf.net/raman/
AIM: emacspeak GTalk: tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
Peter Korn
Do you think this issue is unique to GNU/Linux? Or to Firefox running
on UNIX in general (e.g. Solaris)?
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> David,
>
> Thank you for investigating this. I'm CC'ing Ginn Chen from Sun. His
> team in Beijing wrote this code. Ginn, will your team be able to look
> at this high priority bug? My new guys who will be working on Linux
> accessibility haven't started yet.
>
> I believe this is only a problem on Linux. First, the
> AppRootAccessible object only exists on Linux. Secondly, the
> accessibility architecture on Windows allows us to only create
> accessible objects if there is an assistive technology asking for
> them. We don't even load that accessibility code at all unless we need
> it there. On Linux it's not so smooth. Everything needs to be set up
> via desktop prefs so it's all or nothing.
>
> Also, on OS X we never initialize accessibility.
>
> David, are the huge leak reports happening on all platforms?
>
> - Aaron
>
>
> L. David Baron wrote:
>> I recently (thanks to the X pixmap measurements of some of the folks
>> working on one-laptop-per-child [1]) found that there's a *huge* leak
>> when accessibility is enabled:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=330624
>>
>> I'm wondering if this could be contributing to the reports of huge
>> memory leaks that we're getting with Firefox 1.5. I'd be interested in
>> knowing answers to the following:
>>
>> * How can a user tell if Mozilla's accessibility code is enabled for
>> them? (Preferably in a way that doesn't depend on assuming that the
>> code that determines whether to enable it is correct.)
>>
>> * If it is enabled, how can a user turn it off to test the effects of
>> disabling it?
>>
>> (In GNOME, what triggers turning on Mozilla's accessibility code
>> is the
>> preference Desktop -> Preferences -> Accessibility -> Assistive
>> Techology Support -> Enable assistive technologies. Changing it
>> requires logging out of GNOME and back in.)
>>
L. David Baron
> Thank you for investigating this. I'm CC'ing Ginn Chen from Sun. His
> team in Beijing wrote this code. Ginn, will your team be able to look at
> this high priority bug? My new guys who will be working on Linux
> accessibility haven't started yet.
>
> I believe this is only a problem on Linux. First, the AppRootAccessible
> object only exists on Linux. Secondly, the accessibility architecture on
The bug I filed about nsAppRootAccessible is not related to this one.
This one is in cross-platform code in accessible/src/base/.
> David, are the huge leak reports happening on all platforms?
I've heard complaints on both Windows and Linux; not sure about Mac.
I'd also really appreciate if somebody could answer the basic questions
below about detecting and changing whether the accessibility code is
being used.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Aaron Leventhal
code is enabled. On Gnome the user could check the system pref for
accessibility. On Windows accessibility is turned on lazily but there's
no way to check if that happened.
On GNOME, this code is what checks for accessibility:
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2754
It first checks for an environment variable called GNOME_ACCESSIBILITY
If that's not set it checks "config.use_system_prefs.accessibility"
So presumeably you could force it off by setting
GNOME_ACCESSIBILITY=0
- Aaron
Aaron Leventhal
code is enabled. On Gnome the user could check the system pref for
accessibility. On Windows accessibility is turned on lazily but there's
no way to check if that happened.
On GNOME, this code is what checks for accessibility:
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2754
It first checks for an environment variable called GNOME_ACCESSIBILITY
If that's not set it checks "config.use_system_prefs.accessibility"
So presumeably you could force it off by setting
GNOME_ACCESSIBILITY=0
- Aaron
Aaron Leventhal
> On Monday 2006-03-20 16:14 -0500, Aaron Leventhal wrote:
> I've heard complaints on both Windows and Linux; not sure about Mac.
>>> If, in fact, more of our users have this code enabled than we thought,
>>> I'm wondering if release drivers should be more conservative about
>>> approving accessibility fixes during release freezes on the basis that
>>> they only affect users who use screen readers, magnifiers, etc. In
>>> fact, I'm suspicious of such reasoning even if those are the only users
>>> affected, since they deserve the stability that comes from gradually
>>> restricting what can be checked in just as much as other users do.
That's fine. It's prior to the release freezes that I need to
accelerate the development. I agree that in the quality phase its very
important to have a strong approval process.
Aaron Leventhal
> On Monday 2006-03-20 16:14 -0500, Aaron Leventhal wrote:
> I've heard complaints on both Windows and Linux; not sure about Mac.
>>> If, in fact, more of our users have this code enabled than we thought,
>>> I'm wondering if release drivers should be more conservative about
>>> approving accessibility fixes during release freezes on the basis that
>>> they only affect users who use screen readers, magnifiers, etc. In
>>> fact, I'm suspicious of such reasoning even if those are the only users
>>> affected, since they deserve the stability that comes from gradually
>>> restricting what can be checked in just as much as other users do.
L. David Baron
> I recently (thanks to the X pixmap measurements of some of the folks
> working on one-laptop-per-child [1]) found that there's a *huge* leak
> when accessibility is enabled:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=330624
>
> I'm wondering if this could be contributing to the reports of huge
> memory leaks that we're getting with Firefox 1.5. I'd be interested in
> knowing answers to the following:
>
> * How can a user tell if Mozilla's accessibility code is enabled for
> them? (Preferably in a way that doesn't depend on assuming that the
> code that determines whether to enable it is correct.)
To follow up on this point, aaronl did find a way to do this:
https://bugzilla.mozilla.org/show_bug.cgi?id=331120#c1
and I just turned it into an extension:
https://addons.mozilla.org/firefox/2407/
that adds an "about:accessibilityenabled" page that says whether
accessibility is or is not active. This is useful (for now) primarily
for users who would like to provide a data point about whether the large
leaks they were saying were related to this bug or not.
-David