Date: Sun, 04 Sep 2016 02:30:42 +0300 From: Arto Pekkanen <isoa@kapsi.fi> To: clutton <clutton@zoho.com> Cc: freebsd-chromium@freebsd.org Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there Message-ID: <1d42dcb1faf8cbe4fbf24066a4163134@kapsi.fi> In-Reply-To: <1472667320.8146.46.camel@zoho.com> References: <1471486169.7533.8.camel@zoho.com> <1472667320.8146.46.camel@zoho.com>
next in thread | previous in thread | raw e-mail | index | archive | help
So I was right from the very start: the Chromium codebase assumes
certain behaviour from the memory allocation API of the host system, and
if this behavour is not in line with Linux (and Android), then problems
are to be expected. Yeah. Yet another fine example of how Open Source is
becoming synonymous with "Designed for Linux".
Is there any hope to get these changes propagated upstream to Chromium
developers?
It would be really nice to have upstream collaboration, because if the
upstream yet again changes things ever so slightly, things will
mysteriously break.
clutton kirjoitti 31.08.2016 21:15:
> On Thu, 2016-08-18 at 05:09 +0300, clutton wrote:
>> I've just fixed the Aw, snap. I believe so.
>
> Ok, time to admit the defeat. I haven't fixed the issue in time, and I
> planned to do so till the summer is there. Being to much arrogant I
> started just before the end of time. I still can't believe I haven't
> fixed this in time.
>
> I'll work on this, but not so intensively, now I just can't left it.
> I learned about the codebase so much. And all those small improvements
> shouldn't be wasted anyway (I haven't posted any because they worth
> nothing without fixing the bug). I'll do it more slowly and
> considerably now.
>
> Number 1 issue is to bring new gn ninja generation system, every
> documentation assumes that you use gn, in future they will remove gyp
> generator. It would be much easier to work then.
> Number 2 is probably to clean the mess in our pathes.
>
> Some thoughts for maintainers/developers:
>
> Don't try debugging if you don't have enough RAM, I distributed the
> compilation to distcc, but RAM was an issue, even with another ssd
> attached as a swap it was tooooo slow to work with debugger, I did a
> lot of tricks to make it possible though, And have a lot of
> frustrations when those tricks mangle the code. I wish I could just put
> that monster in RAM press bt and don't wait 5 minutes till it's done.
>
> Memory allocation in base works fine, I might missed something but
> debugging bit after bit was fine, then I finally did stubs, then I
> finally found that new shim allocator have those stubs already, some
> fixes would be needed though, for now I used this:
> allocator_shim_default_dispatch_to_libc.cc
> extern "C" {
> void* __malloc(size_t size);
> void* __calloc(size_t n, size_t size);
> void* __realloc(void* address, size_t size);
> void* __memalign(size_t alignment, size_t size) {
> void *ret;
> if (__posix_memalign(&ret, alignment, size) != 0) {
> return nullptr;
> } else {
> return ret;
> }
> }
> int __posix_memalign(void **ptr, size_t alignment, size_t size);
> void __free(void* ptr);
> } // extern "C"
>
> But they assume linux and android, and they implement posix_memalign
> through memalign, I did the opposite. For now I have that unnecessary
> chain. It works but it could work faster without chain.
>
> I haven't debugged heavily blink memory allocator, which I should have
> done instead of base allocator... There are some approaches to make it
> not to crush, but they are just hardcode patching, not fixing. And some
> patches I thought work just delaying the freezing.
>
> Next, chromium team patch libraries, those in third_party directory, I
> debugged some of them, seems fine. No difference in work comparing to
> our. But that is probably is something to look at more. Ninja sucks,
> once I put the most recent re2 library by mistake and ninja compiled it
> without hesitation. Then I had coredumps on that library.
>
>
> Ok, probably all, because writing everything would be to much for non
> prepared reader. Better send patches. "Talk is cheap. Show me the code"
--
Arto Pekkanen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d42dcb1faf8cbe4fbf24066a4163134>