bug#34138: 27.0.50; Delayed display of PDF file images

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: rudalics@gmx.at,  34138@debbugs.gnu.org,  politza@hochschule-trier.de,  
> tsdh@gnu.org
> Date: Sun, 20 Jan 2019 21:45:06 +0100
> 
> > Please start GDB from a directory other that the Emacs src directory,
> > I'd like to see the C backtrace that way.
> 
> Ok, transcript attached.  But now there's no Lisp backtrace (more on
> this below).
> 
> Thread 1 (Thread 0x7fda7bf18bc0 (LWP 5399)):
> #0  0x00007fda7ea7f291 in __pselect (nfds=16, readfds=0x7ffd68a79c30, 
> writefds=0x7ffd68a79bb0, exceptfds=0x0, timeout=<optimized out>, 
> sigmask=<optimized out>)
>     at ../sysdeps/unix/sysv/linux/pselect.c:69
> #1  0x00000000005bca5d in really_call_select (arg=arg@entry=0x7ffd68a796f0)
>     at /mnt/data/steve/git/emacs-master/src/thread.c:580
> #2  0x0000000000542d88 in flush_stack_call_func (func=func@entry=0x5bca12 
> <really_call_select>, arg=arg@entry=0x7ffd68a796f0)
>     at /mnt/data/steve/git/emacs-master/src/alloc.c:5229
> #3  0x00000000005bd24f in thread_select (func=<optimized out>, 
> max_fds=max_fds@entry=16, rfds=rfds@entry=0x7ffd68a79c30, wfds=<optimized 
> out>, efds=efds@entry=0---Type <return> to continue, or q <return> to quit---
> x0, timeout=timeout@entry=0x7ffd68a79e80, sigmask=0x0)
>     at /mnt/data/steve/git/emacs-master/src/thread.c:610
> #4  0x00000000005d7c64 in xg_select (fds_lim=16, 
> rfds=rfds@entry=0x7ffd68a79f20, wfds=0x7ffd68a79ea0, efds=efds@entry=0x0, 
> timeout=timeout@entry=0x7ffd68a79e80, sigmask=sigmask@entry=0x0)
>     at /mnt/data/steve/git/emacs-master/src/xgselect.c:117
> #5  0x000000000059daf3 in wait_reading_process_output 
> (time_limit=time_limit@entry=172, nsecs=nsecs@entry=0, read_kbd=-1, 
> do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, 
> wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at 
> /mnt/data/steve/git/emacs-master/src/process.c:5405
> #6  0x0000000000424e63 in sit_for (timeout=timeout@entry=0x2b2, 
> reading=reading@entry=true, display_option=display_option@entry=1)
>     at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
> #7  0x00000000004f769e in read_char (commandflag=1, map=map@entry=0x3563eb3, 
> prev_event=0x0, used_mouse_menu=used_mouse_menu@entry=0x7ffd68a7a30b, 
> end_time=end_time@entry=0x0) at 
> /mnt/data/steve/git/emacs-master/src/lisp.h:751
> #8  0x00000000004f81ec in read_key_sequence 
> (keybuf=keybuf@entry=0x7ffd68a7a3d0, prompt=prompt@entry=0x0, 
> dont_downcase_last=dont_downcase_last@entry=false, 
> can_return_switch_frame=can_return_switch_frame@entry=true, 
> fix_current_buffer=fix_current_buffer@entry=true, 
> prevent_redisplay=prevent_redisplay@entry=false)
>     at /mnt/data/steve/git/emacs-master/src/lisp.h:1386
> #9  0x00000000004f9730 in command_loop_1 ()
>     at /mnt/data/steve/git/emacs-master/src/lisp.h:1056

Still weird: this says that Emacs simply waits for any input to
arrive, a.k.a. "is idle".

You've mentioned before that one of the two scenarios where you see
this problem produces a much longer delay -- could you repeat the same
procedure during that long delay, and show the backtrace from that
session?  Maybe we will see something more interesting there.

Thanks.