RESOLVED FIXED Bug 51367
Deallocate GregorianDateTime.timeZone (if allocated) when copying so that we don't leak memory.
https://bugs.webkit.org/show_bug.cgi?id=51367
Summary Deallocate GregorianDateTime.timeZone (if allocated) when copying so that we ...
Daniel Bates
Reported 2010-12-20 17:40:41 PST
When copying a GregorianDateTime object B to A using GregorianDateTime.copyFrom() we don't deallocate the timeZone of A before allocating a new timeZone buffer and copying the timeZone of B. Hence, we are leaking memory. Instead, we should deallocate the timeZone buffer of A then allocate a new timeZone buffer for A and copy the timeZone from B into it.
Attachments
Patch (1.14 KB, patch)
2010-12-20 17:43 PST, Daniel Bates
no flags
Patch (3.69 KB, patch)
2010-12-20 20:06 PST, Daniel Bates
eric: review+
Daniel Bates
Comment 1 2010-12-20 17:43:58 PST
Eric Seidel (no email)
Comment 2 2010-12-20 18:25:28 PST
Comment on attachment 77060 [details] Patch Can't we use an OwnArrayPtr here? That would be much cleaner.
Antonio Gomes
Comment 3 2010-12-20 18:26:31 PST
Comment on attachment 77060 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=77060&action=review > JavaScriptCore/wtf/DateMath.h:204 > + delete [] timeZone; should we also set it to '0', in case if (rhs.timeZone) fails?
Daniel Bates
Comment 4 2010-12-20 20:06:15 PST
Created attachment 77077 [details] Patch Updated patch based on Eric Seidel's suggestion.
Daniel Bates
Comment 5 2010-12-20 20:08:02 PST
(In reply to comment #3) > (From update of attachment 77060 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=77060&action=review > > > JavaScriptCore/wtf/DateMath.h:204 > > + delete [] timeZone; > > should we also set it to '0', in case if (rhs.timeZone) fails? Notice, we do this by line 209 in <http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/DateMath.h?rev=72884#L209>.
Eric Seidel (no email)
Comment 6 2010-12-20 20:15:40 PST
Comment on attachment 77077 [details] Patch OK... so now I wonder why we wouldn't just use Vector<char> here.
Eric Seidel (no email)
Comment 7 2010-12-20 20:16:17 PST
Comment on attachment 77077 [details] Patch This is strictly better than what we have, so OK.
Build Bot
Comment 8 2010-12-20 20:47:13 PST
Darin Adler
Comment 9 2010-12-21 11:18:42 PST
Comment on attachment 77077 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=77077&action=review Should find out why the Windows build broke. > JavaScriptCore/wtf/DateMath.cpp:1132 > - tm.timeZone = NULL; > + tm.timeZone.clear(); Side note: The most modern idiom for this is to assign to nullptr. We are going to deprecate clear(). > JavaScriptCore/wtf/DateMath.h:202 > + timeZone.set(new char[inZoneSize]); The most modern idiom for this is: timeZone = adoptArrayPtr(new char[inZoneSize]); We are going to deprecate set soon.
Daniel Bates
Comment 10 2010-12-21 11:28:02 PST
(In reply to comment #9) > (From update of attachment 77077 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=77077&action=review > > Should find out why the Windows build broke. Will look into and fix before landing. > > > JavaScriptCore/wtf/DateMath.cpp:1132 > > - tm.timeZone = NULL; > > + tm.timeZone.clear(); > > Side note: The most modern idiom for this is to assign to nullptr. We are going to deprecate clear(). Will change. > > > JavaScriptCore/wtf/DateMath.h:202 > > + timeZone.set(new char[inZoneSize]); > > The most modern idiom for this is: > > timeZone = adoptArrayPtr(new char[inZoneSize]); Will change. > > We are going to deprecate set soon.
Daniel Bates
Comment 11 2010-12-21 13:22:42 PST
Note You need to log in before you can comment on or make changes to this bug.