52.0.2743.82 (64-bit) to go, Aw snap is still there

[clutton]

On Sun, 2016-09-04 at 02:30 +0300, Arto Pekkanen wrote:
> 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.

No, you wasn't right about the memory. I just wrote - base allocator
works fine. Their home-brew assembler snippets work fine. I haven't
checked blink allocator as thoroughly as base, may be it's there
something not right. Do not assume that chromium is bug-free also.
Some shit may fire with conditions met.

For now I have GN ninja fully working (I believe I'll commit today), I
doubt that google would take it upstream, such a mess to add another
architecture. Nevertheless - I'm using macros is_bsd, with assumption
that code would use OS_BSD, and with some division
OS_OPENBSD/OS_FREEBSD further in C/C++ code, so it's more clean and has
more chances to be accepted. But may no mistake - they invest a lot of
resources to make this chrome work according to a plan, I don't think
that they would add another OS. Unless there are a lot of people
interested.

About Linuxism, - they divide code very simple, if you don't like the
functionality, you can rewrite it for your OS... The thing is - we use
a lot of code written for Linux.


> 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-chromium/attachments/20160904/2fa9394a/attachment.sig>