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>