On Tue, Aug 5, 2014 at 1:09 AM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote:
Yes, that's correct. You have to clear them somehow before the
process exits or we leak.
Which, besides accounting, is not really a problem, since the process is
On 2014-08-06, 1:32 PM, Benjamin Smedberg wrote:
On 8/6/2014 1:20 PM, Chris Peterson wrote:
I don't understand this sentence, but I strongly oppose automatically
clearing Static*Ptr in the static destructor in any build. In the past
we have had static comptr cause final release of objects
On 8/8/2014 11:25 AM, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all. What
if one of these destructors runs code that writes something to the
disk for example, which we expect to go to the disk before we shut down?
Then we should assert in debug builds!
On 2014-08-08, 11:42 AM, Benjamin Smedberg wrote:
On 8/8/2014 11:25 AM, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all. What
if one of these destructors runs code that writes something to the
disk for example, which we expect to go to the disk before we
- Original Message -
OK, I guess that's better than what we have now... Still I thought the
goal of this class is to avoid static initializers, so why do we want a
trivial destructor for it in release builds?
So the compiler won't generate a static initializer that ensures the
On 2014-08-08, 12:20 PM, Nathan Froyd wrote:
- Original Message -
OK, I guess that's better than what we have now... Still I thought the
goal of this class is to avoid static initializers, so why do we want a
trivial destructor for it in release builds?
So the compiler won't generate
On Friday 2014-08-08 11:25 -0400, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all.
What if one of these destructors runs code that writes something to
the disk for example, which we expect to go to the disk before we
shut down?
User-visible actions should
On 8/6/14 7:11 AM, Benjamin Smedberg wrote:
Not only that, but it also makes our code correct. There is nothing
to guarantee that one of those destrcutors we're skipping right now
would not have observable side effects passed shutdown. So until
somone comes up with an idea on how to enforce
On 8/6/2014 1:20 PM, Chris Peterson wrote:
I don't understand this sentence, but I strongly oppose automatically
clearing Static*Ptr in the static destructor in any build. In the past
we have had static comptr cause final release of objects after XPCOM
shutdown, which causes crashes due to
Thanks, I now see distinction you are making. :)
On 8/6/14 10:32 AM, Benjamin Smedberg wrote:
On 8/6/2014 1:20 PM, Chris Peterson wrote:
I don't understand this sentence, but I strongly oppose automatically
clearing Static*Ptr in the static destructor in any build. In the past
we have had
On 2014-08-04, 7:09 PM, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey
On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote:
Static*Ptrs are there to avoid
static constructors and destructors so they can't clear themselves at
shutdown. That means that they behave quite differently than
regular smart pointers. Am I the only one who is bothered by
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote:
On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote:
Static*Ptrs are there to avoid
static constructors and destructors so they can't
On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote:
On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
On Sun, Aug 3,
On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote:
On Sun, Aug 3, 2014 at 11:01 PM,
On Mon, Aug 04, 2014 at 04:09:26PM -0700, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote:
On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM
I've been trying to get leak testing working on b2g[0] and I've
discovered a number of leaks[1][2][3] that are caused by StaticRefPtrs
that are never cleared at shutdown. Static*Ptrs are there to avoid
static constructors and destructors so they can't clear themselves at
shutdown. That means
17 matches
Mail list logo
