From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Windows 9X crash (was: [PATCH] Override Windows default Win-* key combinations when using Emacs) Date: Fri, 15 Jan 2016 10:08:13 +0200 Message-ID: <831t9jgt8y.fsf@gnu.org> References: <568BBC58.50702@aprikoodi.fi> <83y4c43qkh.fsf@gnu.org> <5691667C.5000009@aprikoodi.fi> <838u3wkkvb.fsf@gnu.org> <5694E07E.8010005@aprikoodi.fi> <83fuy2kd2w.fsf@gnu.org> <56961607.2090504@aprikoodi.fi> <569634D6.6030404@aprikoodi.fi> <83oacpiial.fsf@gnu.org> <5697995B.5010306@aprikoodi.fi> <83mvs8gh7n.fsf@gnu.org> <56989810.70301@aprikoodi.fi> <5698A546.8020701@aprikoodi.fi> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1452845316 19619 80.91.229.3 (15 Jan 2016 08:08:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jan 2016 08:08:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jussi Lahdenniemi , Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 15 09:08:31 2016 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 1aJzQs-0004IK-Fo for ged-emacs-devel@m.gmane.org; Fri, 15 Jan 2016 09:08:30 +0100 Original-Received: from localhost ([::1]:45826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJzQm-0000AS-Qt for ged-emacs-devel@m.gmane.org; Fri, 15 Jan 2016 03:08:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJzQj-000094-1v for emacs-devel@gnu.org; Fri, 15 Jan 2016 03:08:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJzQf-0001wA-1f for emacs-devel@gnu.org; Fri, 15 Jan 2016 03:08:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJzQe-0001w6-UL; Fri, 15 Jan 2016 03:08:16 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4592 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aJzQe-00081y-7m; Fri, 15 Jan 2016 03:08:16 -0500 In-reply-to: <5698A546.8020701@aprikoodi.fi> (message from Jussi Lahdenniemi on Fri, 15 Jan 2016 09:52:38 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:198170 Archived-At: (Adding Fabrice, who wrote the new allocator code, to the discussion.) > Cc: emacs-devel@gnu.org > From: Jussi Lahdenniemi > Date: Fri, 15 Jan 2016 09:52:38 +0200 > > On 15.1.2016 8.56, Jussi Lahdenniemi wrote: > >> The first thing I'd like to know is what buffer is > >> that (I'm guessing *scratch* or *Messages*), and what is the value of > >> 'a' in this call frame: > > > > the value of the name variable in the Fget_buffer_create function is " > > *load*", and a in frame #4 is 0x02a22101. > > Ah, of course; when allocating 'b' in Fget_buffer_create, Emacs got the > pointer 0x...fc, which is NOT aligned at an 8-byte boundary as required > by USE_LSB_TAG. This messes up the tags and causes the crash. > > So, apparently, on Windows 98 HeapAlloc does not guarantee 8-byte > alignment of memory. Not that this would be documented anywhere... Right, this can explain everything. It probably means that a build configured --with-wide-int should also be tested there, as it has different alignment needs. > How should we fix this? I can write and test the fix, but I'd like to > hear your opinion on the preferred mechanism. What fix did you have in mind? Over-allocating and recording the offset in the initial part of the block that we don't pass to the application?