From owner-freebsd-chromium@freebsd.org Wed Aug 31 18:15:40 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCC6CBC8F68 for ; Wed, 31 Aug 2016 18:15:40 +0000 (UTC) (envelope-from clutton@zoho.com) Received: from sender153-mail.zoho.com (sender153-mail.zoho.com [74.201.84.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB818E25 for ; Wed, 31 Aug 2016 18:15:40 +0000 (UTC) (envelope-from clutton@zoho.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:subject:from:to:date:in-reply-to:references:content-type:mime-version; b=DuLgs/xdkunFSOqCzscZ36ulpbSco6K31OCXBBjDj4MbelykE0lxMRqXtfFzIJCEejtL9a0Dwhsc EVaF2OTDiENSIWLloJZ9QefTI1EXk6MjVwAVQZXD+j/2Y4Tpmd8s Received: from [192.168.11.5] (mktechs.net [46.229.54.117]) by mx.zohomail.com with SMTPS id 1472667325691173.59351699881984; Wed, 31 Aug 2016 11:15:25 -0700 (PDT) Message-ID: <1472667320.8146.46.camel@zoho.com> Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there From: clutton To: freebsd-chromium@freebsd.org Date: Wed, 31 Aug 2016 21:15:20 +0300 In-Reply-To: <1471486169.7533.8.camel@zoho.com> References: <1471486169.7533.8.camel@zoho.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-qIGtzypJAx01+Yx58uVM" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-Zoho-Virus-Status: 1 X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 18:15:40 -0000 --=-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-- From owner-freebsd-chromium@freebsd.org Sat Sep 3 07:37:25 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A784BCE267 for ; Sat, 3 Sep 2016 07:37:25 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7748BEB1 for ; Sat, 3 Sep 2016 07:37:25 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 734D3BCE266; Sat, 3 Sep 2016 07:37:25 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 709F0BCE265 for ; Sat, 3 Sep 2016 07:37:25 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 561DDEB0 for ; Sat, 3 Sep 2016 07:37:25 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.15.2/8.15.2) with ESMTP id u837bPLf099886 for ; Sat, 3 Sep 2016 07:37:25 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.15.2/8.15.2/Submit) id u837bPvw099885; Sat, 3 Sep 2016 07:37:25 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201609030737.u837bPvw099885@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Sat, 3 Sep 2016 07:37:25 +0000 From: portscout@FreeBSD.org To: chromium@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 07:37:25 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/chromium@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ www/chromium | 52.0.2743.116 | 52.0.2743.117 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-chromium@freebsd.org Sat Sep 3 23:30:47 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D970BCF293 for ; Sat, 3 Sep 2016 23:30:47 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2097135B for ; Sat, 3 Sep 2016 23:30:46 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from karviainen.kapsi.fi ([217.30.184.182] helo=roundcube.kapsi.fi) by mail.kapsi.fi with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1bgKOY-00057I-Em; Sun, 04 Sep 2016 02:30:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 04 Sep 2016 02:30:42 +0300 From: Arto Pekkanen To: clutton Cc: freebsd-chromium@freebsd.org In-Reply-To: <1472667320.8146.46.camel@zoho.com> References: <1471486169.7533.8.camel@zoho.com> <1472667320.8146.46.camel@zoho.com> Message-ID: <1d42dcb1faf8cbe4fbf24066a4163134@kapsi.fi> X-Sender: isoa@kapsi.fi User-Agent: RoundCube Webmail/0.9.4 X-SA-Exim-Connect-IP: 217.30.184.182 X-SA-Exim-Mail-From: isoa@kapsi.fi X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mail.kapsi.fi) X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 23:30:47 -0000 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