Re: [webkit-dev] If you like writing memory smashers, you'll love this

> On Dec 15, 2014, at 17:31, Geoffrey Garen wrote: > > As of r177317, FastMalloc can be disabled at runtime. This means that you can > use system memory analysis tools like GuardMalloc, MallocScribble, > Instruments allocation tracking, leaks, and heap to debug memory issues in > WebKit night

[webkit-dev] If you like writing memory smashers, you'll love this

As of r177317, FastMalloc can be disabled at runtime. This means that you can use system memory analysis tools like GuardMalloc, MallocScribble, Instruments allocation tracking, leaks, and heap to debug memory issues in WebKit nightly builds, spade builds, and release builds. FastMalloc automat

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

Nice. Thanks for the links. We should do the same, at least add a #ifdef for the worker support. It is a step in the right direction. On 12/15/14 4:54 PM, TAMURA, Kent wrote: Yes. openDatabase on WorkerGlobalScope: https://www.chromestatus.com/metrics/feature/timeline/popularity/313 openDat

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

Yes. openDatabase on WorkerGlobalScope: https://www.chromestatus.com/metrics/feature/timeline/popularity/313 openDatabaseSync on WorkerGlobalScope: https://www.chromestatus.com/metrics/feature/timeline/popularity/314 openDatabase on Window: (We can't remove this yet.) https://www.chromestatus.c

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

That's interesting information. Did you add usage counters before the removal? Any idea how much usage there is? On 12/15/14 4:28 PM, TAMURA, Kent wrote: FYI. We removed Web SQL support for Workers in Blink, and already shipped the removal in Google Chrome stable channel. The removal made t

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

FYI. We removed Web SQL support for Workers in Blink, and already shipped the removal in Google Chrome stable channel. The removal made the code much simpler because we don't need synchronous-version classes. On Sat, Dec 6, 2014 at 9:13 AM, Benjamin Poulain wrote: I hope we will be able to

Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

Ok, I've created a new bug with the instruments trace here: https://bugs.webkit.org/show_bug.cgi?id=139654 I'll see what I can do about a sample project soon. I've also got a bit of new information to share. We released a new beta of the app in

Re: [webkit-dev] Interdiff fixed on bugs.webkit.org

Thanks for fixing this! - R. Niwa On Mon, Dec 15, 2014 at 10:04 AM, David Kilzer wrote: > > I just fixed the 'interdiff' feature of Bugzilla. Now you can diff your > diffs while you diff! > > The issue was apparently being tracked here: Bug 82517: Bugzilla should > provide diffs between two pa

Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

Can you attach the Instruments trace leading up to the crash, and/or a reduced copy of the app that can reproduce the crash, to bugzilla? Thanks, Geoff > On Dec 11, 2014, at 7:34 PM, Ian Ragsdale wrote: > > Actually, looking again, I was running the profile on the device, not the > simulator

[webkit-dev] A quick note on Ref and RefPtr changes

Howdy folks, Thanks to the magic of C++11, we don’t need PassRef and PassRefPtr anymore, as we can use rvalue references and move semantics to achieve churn-free ownership transfers. I’ve already removed PassRef entirely, and PassRefPtr will be next. Given how widely it’s used in the codebase,

[webkit-dev] Interdiff fixed on bugs.webkit.org

I just fixed the ‘interdiff’ feature of Bugzilla. Now you can diff your diffs while you diff! The issue was apparently being tracked here: Bug 82517: Bugzilla should provide diffs between two patches Example: