From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: GC and stack marking Date: Wed, 21 May 2014 20:12:45 -0700 Message-ID: <537D6B2D.90208@dancol.org> References: <83sio2nb4s.fsf@gnu.org> <83r43mmt25.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6VcNSgdx3KgsGN7KHOGeVwC2P6h9JTB8A" X-Trace: ger.gmane.org 1400728390 23929 80.91.229.3 (22 May 2014 03:13:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 May 2014 03:13:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Barry OReilly Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 22 05:13:04 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WnJRH-0005tP-Ji for ged-emacs-devel@m.gmane.org; Thu, 22 May 2014 05:13:03 +0200 Original-Received: from localhost ([::1]:34465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnJRG-00042k-L2 for ged-emacs-devel@m.gmane.org; Wed, 21 May 2014 23:13:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnJRD-00042c-A6 for emacs-devel@gnu.org; Wed, 21 May 2014 23:13:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnJRC-0001kO-7Z for emacs-devel@gnu.org; Wed, 21 May 2014 23:12:59 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnJRA-0001hx-CC; Wed, 21 May 2014 23:12:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1oz7uWh3soRPYkaH1jmPhiaPCEIKjaPCkVzx5sMcbvA=; b=EcPMvkZ+hXfmklBXPlz8fc/ySezX7deKBM3MlJqHgR7ViZZ2J16peyvVzgLdEXpBKMjBc6MDkNGwVc8AtNbEDMYTUXkNVQ9gW1gdnyer5oa2qZ38/sljLDeTZB6auQDMVGTsH8++rXJ0MBCGBdMOdR2gvlzzEH2Ehki5K7KoAr6osCNz+DAoK63EtwoC7GPB8dROVdR23dYz0FBcI3DSdYkGC4j3XsR6e1V2dxU1qkQ2tekrocVGtoAsGve9RjHhd5s4MAYdjIDdKPgAdee53tQGmgtDZnp0D44YL+kHyccrLpLYiahMz5wjNOD3K36q4+4TAqLCX4GYT7xaL8i33Q==; Original-Received: from [2601:8:b240:264::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WnJR2-0008Ja-88; Wed, 21 May 2014 20:12:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <83r43mmt25.fsf@gnu.org> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172012 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6VcNSgdx3KgsGN7KHOGeVwC2P6h9JTB8A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/21/2014 07:43 PM, Eli Zaretskii wrote: >> Date: Wed, 21 May 2014 16:49:22 -0400 >> From: Barry OReilly >> Cc: emacs-devel@gnu.org >> >> Even if we're only talking about the stack variables in the frames tha= t are >> active during your particular problematic case (and perhaps in the idl= e >> Emacs GC case)? >=20 > I thought you were asking about having the compiler generate the code > to do that, which would then happen everywhere. >=20 > If you propose doing that selectively, I don't know how this would be > possible, since on the C level you don't have a way of telling how > much stack is allocated in a given function. >=20 >> Have you already ruled out whether stack_top_variable contributes one = of >> the bytes in your false positive lookup in the mem_node tree? >=20 > Yes. I looked at all the local variables in that stack frame, and > their addresses on the stack are different from the one that triggers > the problem. What about cleaning the stack (memset from the top to the high water mark) every once in a while? --6VcNSgdx3KgsGN7KHOGeVwC2P6h9JTB8A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTfWstAAoJEMAaIROpHW7IFSIQALMxj72dj8Mhmx6PKhvSk83D 9j+62nWsTtobo3GN3IwbM9fzKN2A+unpyP/AvwR0EFwQILlF5MD/Agri1/3qeB6H mcsCkD09xxI5tfZ2YsvreJqj5LtJPxUh4d3D0hH52w+DePMNKubqGr82YIvixhS3 hm4nphWGdXUAt8EqoK6weZwea0kV1fC9dGzk9ZR98mSf21gFcWkgDSDPYjaXPTAx Q4uAtaDzmfyR9SpXjJCTZ89n3ae1jc6RsLGRYqT4InmCkDi2/V65tnu7UYo1uCxp xPWRNnW+tpaXUcgMLk+mzl2Z8W0jc+nHaUPEouGstkKqfrHdWPFjKcjj2oN3FyHH ckSqyW02hm9bBsgvCb7l3L59IXq2e5edOg5hBQ6sR+u+/OvilaWGr11AjU//LDvy kKAx64A4Y2YPEu/lW2KZwtUEo4eHBmWdmQ2J57HaNBrXcFvitOovBiDapGL0Tn2d 0XRfrHuqvh2E9OtCcslGfk2sy9LJClIomdFAR5kYHrbUAd86zsMORVpFO9t6sIpf ZpX9Mcfop3V7LuzeT84gEMwKFnHuU+bzJ/94evfb0NCojvjxAfTmQfjevy2fq/Wn 9mmKrpVPQahJZ67qiNGJMK8tBf4ZoR7uRaTlHwuHq51H4X1gaS3bFk8M83YR0JPk lTQUXYkBpdoAdB4eownd =rQW1 -----END PGP SIGNATURE----- --6VcNSgdx3KgsGN7KHOGeVwC2P6h9JTB8A--