Date: Wed, 31 Aug 2016 21:15:20 +0300 From: clutton <clutton@zoho.com> To: freebsd-chromium@freebsd.org Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there Message-ID: <1472667320.8146.46.camel@zoho.com> In-Reply-To: <1471486169.7533.8.camel@zoho.com> References: <1471486169.7533.8.camel@zoho.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-qIGtzypJAx01+Yx58uVM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) { =C2=A0 void *ret; =C2=A0 if (__posix_memalign(&ret, alignment, size) !=3D 0) { =C2=A0=C2=A0=C2=A0=C2=A0return nullptr; =C2=A0 } else { =C2=A0=C2=A0=C2=A0=C2=A0return ret; =C2=A0 } } int=C2=A0=C2=A0__posix_memalign(void **ptr, size_t alignment, size_t size); void __free(void* ptr); }=C2=A0=C2=A0// 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" --=-qIGtzypJAx01+Yx58uVM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXxx66AAoJEH2wP42yyP6QkAsP/0T5P2O7CfbOTdD7mDKbUA1n HzLJAjNPJC+xOKbiiP8rf/PgpweVA20YTUH1INlhRs8q2N6R/a9N5BLFCJqTCWL8 1nwIs0IroNvWHLmNezxqHMKrM6o5Gw1/APYjxMS+5HbSMI954nT7/y+dGCW1u3x7 66QS9Vx6WDRYQeHWA4IMVQVxMxEMsvI5GeYH5jMfmdLzyJ9IQOVBoHSDiKtrT5Nw x9Xzpt8h0eyNidigFRCeChucmKGOMMFRsA7vpZAjZzacUpITOZ1vHstqMFxkEw27 8+92AxTFTzkx5/IpaczWP/GhLvAFJFF6Vcfoypux+1BazuVpgB1zHKOqLNYDlJNu yypevcV7BIhmJdnWP9elHCOP2IWMnUl0IxP5mQq5inrkz4kM35QrgDq6hoaymJn0 jzz8P0rIkeDO4R0EUvBScUHrNsrIf4MR5gxx+zc8DzjHgaDW/yujhIRhTGAifKSI M4O6B801itWWtj+rxZg4DongHfo25z2BLRNItngIAg9L43GOJirANqy3e6T4hvMr pYwH2VYcPUr0D4HRFiw7CTlVFnd3exaUORbQfFu7GUB+JDKCPI69QQfBSxSu1nIT rXu0jgQU3ZPDDfvkecTdgFHcOvNMiykgNyrZqV4uZ1wsl8TicsMcXWuDyBa+MMzD iZUXpTG/9o+nOWYezUkP =0teb -----END PGP SIGNATURE----- --=-qIGtzypJAx01+Yx58uVM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1472667320.8146.46.camel>