all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: psainty@orcon.net.nz, pieter@vanoostrum.org, 38407@debbugs.gnu.org
Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines
Date: Wed, 04 Dec 2019 10:15:55 +0100	[thread overview]
Message-ID: <m2r21k78ok.fsf@gmail.com> (raw)
In-Reply-To: <lxpnhd9ecn.fsf@cochabamba.vanoostrum.org>

>>>>> On Tue, 03 Dec 2019 18:05:42 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> Yes, I was wondering about that myself.  But we need more details to
    Eli> understand better what, if anything, can be done about this.

    Eli> First, which part of SAVE_IT causes this?  I'm guessing it's this
    Eli> part:

    Eli>   #define SAVE_IT(ITCOPY, ITORIG, CACHE)	\
    Eli>     do {					\
    Eli>       if (CACHE)				\
    Eli> 	bidi_unshelve_cache (CACHE, true);	\
    Eli>       ITCOPY = ITORIG;				\
    Eli>       CACHE = bidi_shelve_cache ();		\  <<<<<<<<<<<<
    Eli>     } while (false)

Yes, itʼs bidi_shelve_cache

    Eli> If that is true, then I think the offending part of bidi_shelve_cache
    Eli> is this:

    Eli>   alloc = (bidi_shelve_header_size
    Eli> 	   + bidi_cache_idx * sizeof (struct bidi_it));
    Eli>   databuf = xmalloc (alloc);
    Eli>   bidi_cache_total_alloc += alloc;

    Eli>   memcpy (databuf, &bidi_cache_idx, sizeof (bidi_cache_idx));
    Eli>   memcpy (databuf + sizeof (bidi_cache_idx),                      <<<<<<<
    Eli> 	  bidi_cache, bidi_cache_idx * sizeof (struct bidi_it));  <<<<<<<
    Eli>   memcpy (databuf + sizeof (bidi_cache_idx)
    Eli> 	  + bidi_cache_idx * sizeof (struct bidi_it),
    Eli> 	  bidi_cache_start_stack, sizeof (bidi_cache_start_stack));

    Eli> And if this guess is also true, then I think the problem is that
    Eli> databuf + sizeof (bidi_cache_idx) is unaligned on 64-bit systems,
    Eli> since bidi_cache_idx is an int.

The '_unaligned_' bit of that memmove function name does not mean
thatʼs itʼs doing unoptimized unaligned copies: it means it accepts
unaligned pointers, and aligns them as necessary to enable fast
copying. Anyway, I made bidi_cache_idx an intptr_t, and it made no
difference.

I think that misalignment is vastly dwarfed by the following:

    (gdb) l bidi_shelve_cache
    973	{
    974	  unsigned char *databuf;
    975	  ptrdiff_t alloc;
    976
    977	  /* Empty cache.  */
    978	  if (bidi_cache_idx == 0)
    979	    return NULL;
    980
    981	  alloc = (bidi_shelve_header_size
    982		   + bidi_cache_idx * sizeof (struct bidi_it));
    (gdb) b 980
    Breakpoint 3 at 0x4b66aa: file bidi.c, line 981.
    (gdb) commands
    Type commands for breakpoint(s) 3, one per line.
    End with a line saying just "end".
    >p bidi_cache_idx
    >p bidi_cache_idx * sizeof(struct bidi_it)
    >end

    Thread 1 "emacs" hit Breakpoint 3, bidi_shelve_cache () at bidi.c:981
    981	  alloc = (bidi_shelve_header_size
    $25 = 30860
    $26 = 71842080

which means Emacs is copying 70MB of data every time bidi_shelve_cache
is called, and itʼs called *a lot* in this scenario. Could we not do
this shelving by pointer-swapping or similar rather than copying?

Robert





  reply	other threads:[~2019-12-04  9:15 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 21:52 bug#38407: 27.0.50; infinite loop with display of large file without newlines Pieter van Oostrum
2019-11-27 23:38 ` Phil Sainty
2019-11-28  0:30 ` Phil Sainty
2019-11-28  1:22 ` Phil Sainty
2019-11-28  6:51   ` Pieter van Oostrum
2019-11-28 15:14     ` Eli Zaretskii
2019-11-28 18:30       ` Pieter van Oostrum
2019-11-28 18:53         ` Eli Zaretskii
2019-11-28 22:09           ` Pieter van Oostrum
2019-11-29  7:12             ` Eli Zaretskii
2019-11-29 11:48               ` Phil Sainty
2019-11-29 13:20                 ` Eli Zaretskii
2019-11-29 13:48                 ` Dmitry Gutov
2019-11-29 14:26                   ` Eli Zaretskii
2019-11-29 14:31                     ` Dmitry Gutov
2019-11-29 15:03                       ` Eli Zaretskii
2019-11-29 16:53                         ` Dmitry Gutov
2019-11-29 19:28                           ` Eli Zaretskii
2019-11-29 17:24               ` Pieter van Oostrum
2019-11-29 19:30                 ` Eli Zaretskii
2019-11-30  8:25                   ` Pieter van Oostrum
2019-12-01  7:23                   ` Pieter van Oostrum
2019-12-01 10:37                     ` Phil Sainty
2019-12-01 16:35                       ` Pieter van Oostrum
2019-12-01 18:40                         ` Pieter van Oostrum
2019-12-02 16:23                         ` Eli Zaretskii
2019-12-01 17:45                       ` Eli Zaretskii
2019-12-02 10:27                         ` Robert Pluim
2019-12-03 11:20                           ` Robert Pluim
2019-12-03 16:05                             ` Eli Zaretskii
2019-12-04  9:15                               ` Robert Pluim [this message]
2019-12-04 15:45                                 ` Eli Zaretskii
2019-12-05  7:27                                   ` Robert Pluim
2019-12-05 15:01                                     ` Eli Zaretskii
2019-12-05 20:38                                       ` Phil Sainty
2019-12-06  8:04                                         ` Eli Zaretskii
2019-12-07  1:28                                           ` Phil Sainty
2019-12-07  7:56                                             ` Eli Zaretskii
2019-11-28 15:06   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2r21k78ok.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=38407@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=pieter@vanoostrum.org \
    --cc=psainty@orcon.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.