From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects Date: Sun, 24 May 2020 15:00:36 +0000 Message-ID: References: <83zha8cgpi.fsf@gnu.org> <83r1vibmyj.fsf@gnu.org> <83imgublku.fsf@gnu.org> <831rncjuwf.fsf@gnu.org> <83h7w5xvfa.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40570"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41321@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 24 17:13:04 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jcsJD-000ASB-C0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 May 2020 17:13:03 +0200 Original-Received: from localhost ([::1]:43384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcsJC-00054Y-Ea for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 May 2020 11:13:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcs8Z-0003eg-0K for bug-gnu-emacs@gnu.org; Sun, 24 May 2020 11:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcs8Y-00041Q-JG for bug-gnu-emacs@gnu.org; Sun, 24 May 2020 11:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jcs8Y-0000FC-HN for bug-gnu-emacs@gnu.org; Sun, 24 May 2020 11:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 May 2020 15:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41321 X-GNU-PR-Package: emacs Original-Received: via spool by 41321-submit@debbugs.gnu.org id=B41321.1590332482890 (code B ref 41321); Sun, 24 May 2020 15:02:02 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 24 May 2020 15:01:22 +0000 Original-Received: from localhost ([127.0.0.1]:38472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcs7t-0000EH-VC for submit@debbugs.gnu.org; Sun, 24 May 2020 11:01:22 -0400 Original-Received: from mail-ot1-f50.google.com ([209.85.210.50]:36184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcs7r-0000E1-NY for 41321@debbugs.gnu.org; Sun, 24 May 2020 11:01:20 -0400 Original-Received: by mail-ot1-f50.google.com with SMTP id h7so12092809otr.3 for <41321@debbugs.gnu.org>; Sun, 24 May 2020 08:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HHje3StXqblbWj6o2C9lFSZcqQEWFY7CuVzKH9Y/MwE=; b=EQL1XPeePTMm44Ymk+TkRdiVyesYNUUQMUwwvSyRJAM94w0mKNqTomLaaFbo/1Rivh k9xU4xOrz7LFY5JrDqGDgEL6BRL+g/Nh3KhSFjLa0ySd66iYrzeEwOPKXeKYzJhCA8Sz hfDH0XfgsQZg1avgsuXzhg7mZl5m1joN8StIEsEGuD65wDGS72wn+SL6HVzn1lKjtNzT IdtQN0JW4VgFS+O7GWwcUTjerE+J6b1EiEYMZQVUckGXbhRteONsipldhfAjGLk3oWL9 53ufy1yjRzXhadb4McuMEZBTIVJfCTUcGfYZGum72pam9CI6JwkBvYc/9vm2Y86Ftluu T7fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HHje3StXqblbWj6o2C9lFSZcqQEWFY7CuVzKH9Y/MwE=; b=U/sMIpR9ZvTpws3CjxyBT8nyWa8uznJFD6IVahdXjclcR3875padXLAXDOuIrQy8eS bRdOE4W6Svn79pT672K+o/YSq2SXqTuxGWLZrSNHHge1uTsbFFSPfGEhxL6APDPmBbyX wzSwGASZZzwA9cwRmT60lLEdwgaeKNOr4Taeu+p+3s5Q7lBHeAPDkObU0A/0Ic51cMq5 +taYu3uxITXTCJHV2AZzZtlbjOS6Q+6QcPumEqTeBASq698yN/L1BEpx/5JWGwLiilJA BqESOamPSvxk8/AcwDjOTyBYCl6ibWj2zeEX7JRE9f2JQVlb3/eUY+6X9z9rRVFS7tkJ 1Szw== X-Gm-Message-State: AOAM532VO2QpZtNOhDlM+82aB9ssrUDMsGlxC3LBfvrfYfzBCtuB+q96 G9MpBeFGbufIL+VbY59r+Xf3jeFxHeYC8N9QYsxCek0gLUo= X-Google-Smtp-Source: ABdhPJy7i/Um9c4AGo6I3e6eKlq8dRmPrzIDRqV03KKLblyTBCCgsp6MsRDmuPpkWmtMGXAC/vdrte4rI/vp/JLIypE= X-Received: by 2002:a05:6830:61b:: with SMTP id w27mr15901947oti.154.1590332473029; Sun, 24 May 2020 08:01:13 -0700 (PDT) In-Reply-To: <83h7w5xvfa.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180900 Archived-At: On Sun, May 24, 2020 at 2:24 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 23 May 2020 23:54:17 +0000 > > Cc: Stefan Monnier , 41321@debbugs.gnu.org > > > > I think I've worked it out: it's this mingw bug: > > https://sourceforge.net/p/mingw-w64/bugs/778/ > > Thank you for working on this tricky problem. > > FTR, I don't use that flavor of MinGW. So your flavor is even more broken than what Debian ships? That's interesting, which flavor is it? > > On mingw, if is included before/instead of stddef.h, > > alignof (max_align_t) == 16. > > The problem with the order of inclusion doesn't exist in my header > files, so alignof (max_align_t) is always 16. Okay, so that is our bug. > > However, as can be seen by the backtrace > > above, Eli's malloc only returned an 8-byte-aligned block. > > Isn't that strange? Lisp data is allocated via lmalloc, AFAIK, and > lmalloc is supposed to guarantee LISP_ALIGNMENT alignment. Or am I > missing something? No, it relies on the compile-time constants and never checks. The relevant code is: enum { MALLOC_IS_LISP_ALIGNED = alignof (max_align_t) % LISP_ALIGNMENT == 0 }; static bool laligned (void *p, size_t size) { return (MALLOC_IS_LISP_ALIGNED || (intptr_t) p % LISP_ALIGNMENT == 0 || size % LISP_ALIGNMENT != 0); } ... so laligned is a constant "true" function on your machine, since alignof (max_align_t) is 16 and LISP_ALIGNMENT is 16. static void * lmalloc (size_t size, bool clearit) { #ifdef USE_ALIGNED_ALLOC if (! MALLOC_IS_LISP_ALIGNED && size % LISP_ALIGNMENT == 0) { void *p = aligned_alloc (LISP_ALIGNMENT, size); if (clearit && p) memclear (p, size); return p; } #endif while (true) { void *p = clearit ? calloc (1, size) : malloc (size); if (laligned (p, size)) return p; free (p); size_t bigger = size + LISP_ALIGNMENT; if (size < bigger) size = bigger; } } That optimizes down to returning the malloc/calloc return value directly. IOW, alloc.c relies on malloc() being max_align_t-aligned, and never checks, not even in debug builds. That's something that needs to be fixed, since broken-malloc environments such as yours exist. > > That's not normally a problem, because mark_maybe_object doesn't > > care about alignment; but in conjunction with the gcc behavior > > change, we rely or mark_maybe_pointer to mark the pointer, and it > > doesn't, because the pointer is not aligned to a LISP_ALIGNMENT = > > 16-byte boundary. > > I still very much doubt that this has anything to do with stack > marking during GC, since I've shown in my backtrace that > current_buffer->overlays_before points to an overlay with invalid > markers. You haven't.