From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau 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:47:51 +0100 Message-ID: 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> <831t9jgt8y.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0116060015b3fb05295c4dc2 X-Trace: ger.gmane.org 1452851310 28079 80.91.229.3 (15 Jan 2016 09:48:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jan 2016 09:48:30 +0000 (UTC) Cc: Jussi Lahdenniemi , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 15 10:48:29 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 1aK0zd-00060r-ER for ged-emacs-devel@m.gmane.org; Fri, 15 Jan 2016 10:48:29 +0100 Original-Received: from localhost ([::1]:46105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK0zc-0002UM-Ew for ged-emacs-devel@m.gmane.org; Fri, 15 Jan 2016 04:48:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK0zO-0002U4-B9 for emacs-devel@gnu.org; Fri, 15 Jan 2016 04:48:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aK0zN-0002nA-9D for emacs-devel@gnu.org; Fri, 15 Jan 2016 04:48:14 -0500 Original-Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:36397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK0zL-0002ms-H0; Fri, 15 Jan 2016 04:48:11 -0500 Original-Received: by mail-ob0-x22a.google.com with SMTP id ba1so516564336obb.3; Fri, 15 Jan 2016 01:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IMZNVEEwUpOK8s3E93wQJFHGIv2o/p65PPEnwMe42ng=; b=fNFd31mfuBmPxArdYxF0CeqiXq4eQ0hZYP601HPhXdR3IH6hba3x49/OvDYKFsifTa APfuEBh1CBl9hR7Zhtuv/glnFdbg6bW77gQBfHIn9Mo9ONHHSeDev7WJO8kOsNJBff/B CLAM+joj8dGqCVd+Gh+maPvnTUSJQ6h4WU9jVqgq74bUTP1hEJJD4xf/1KluZU976MCw P7ZIfrTCkvB44CEEOjxtzvxWYYifEWlc0te9/ybERF8Qk25g1Gl6pfmoTuHnFHmoqLwr uC9JvO/coDjqiD3mgp11y3xxgumBvBBG21+qnNI5Cyt8z2JCye4CvrmHTJNQMKCE1ULl p+Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IMZNVEEwUpOK8s3E93wQJFHGIv2o/p65PPEnwMe42ng=; b=S/8R/Cftcnooy0bnd6XVotpp8sICOoozVn8i5qbXWe/nXN8EFtBF6EhRSlvvuUDCA9 EXTK2P6VqRVw1DMJBZ9rM+8b6qBCJ4k5hQqcprTV3yhfCtN4O35iR9GVEt2VpF/jV64J H/C3FgextK/VWDf8MUGScw3sTHDLbPkwjI/POha7kt5V6PLiyVaZO0pX4LPBkG4vercv 8JIKs2Z2jLix0btXRBN+ArOzQDuhzqW/UjsTDbEtRGX9GKEsL96z3tptg2UNu2f1UFT2 kRGtT1tHdXVlf/pVcWKgz9ts3/3zY+LSmoTK6NQMneAjDUn00xaLmjcvoWMHiAZRrDGk QKeg== X-Gm-Message-State: ALoCoQnw31Mm/fT9pXK2pN1j7sjC6j1xSzKT2CT0KkSfwItXcqw/+WDk2c8xXr2vzTFW1TqkX6wkfywyD27NlcTzG8pYOzJSQQ== X-Received: by 10.60.54.168 with SMTP id k8mr7751606oep.51.1452851290548; Fri, 15 Jan 2016 01:48:10 -0800 (PST) Original-Received: by 10.202.79.215 with HTTP; Fri, 15 Jan 2016 01:47:51 -0800 (PST) In-Reply-To: <831t9jgt8y.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c01::22a 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:198175 Archived-At: --089e0116060015b3fb05295c4dc2 Content-Type: text/plain; charset=UTF-8 Hi, Strange that HeapAlloc() returns 4-byte aligned blocks and that is not documented. I used to have MSDN cdroms from that time I would write a small program doing random allocation and checking the alignment of the blocks returned. Just to make sure that the problem does not lie elsewhere (?) Fabrice 2016-01-15 9:08 GMT+01:00 Eli Zaretskii : > (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? > --089e0116060015b3fb05295c4dc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Strange that HeapAlloc() returns 4-= byte aligned blocks and that is not documented.
I used to have MS= DN cdroms from that time
I would write a small program doing rand= om allocation
and checking the alignment of the blocks returned.<= /div>
Just to make sure that the problem does not lie elsewhere (?)

Fabrice

2016-01-15 9:08 GMT+01:00 Eli Zaretskii <eliz@gnu.org= >:
(Adding Fabrice, who wro= te the new allocator code, to the discussion.)

> Cc: emacs-devel@gnu.org
> From: Jussi Lahdenniemi <juss= i@aprikoodi.fi>
> 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, Emac= s got the
> pointer 0x...fc, which is NOT aligned at an 8-byte boundary as require= d
> by USE_LSB_TAG.=C2=A0 This messes up the tags and causes the crash. >
> So, apparently, on Windows 98 HeapAlloc does not guarantee 8-byte
> alignment of memory.=C2=A0 Not that this would be documented anywhere.= ..

Right, this can explain everything.=C2=A0 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?=C2=A0 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?=C2=A0 Over-allocating and recording the
offset in the initial part of the block that we don't pass to the
application?

--089e0116060015b3fb05295c4dc2--