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

[Stephen Berman]

On Sun, 20 Jan 2019 19:42:58 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> 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 18:14:13 +0100
>> 
>> > It means, during the time of the delay, type from the shell prompt:
>> >
>> >   $ gdb -p PID
>> >
>> > where PID is the numeric process-id of the Emacs process; you should
>> > find that in advance, e.g. by running "ps".  Once GDB starts and shows
>> > its prompt, "(gdb)", type:
>> >
>> >   (gdb) thread apply all bt
>> >
>> > This should show the C-level backtrace.  Then:
>> >
>> >   (gdb) source /path/to/emacs/src/.gdbinit
>> >   (gdb) xbacktrace
>> >
>> > The last command should show the Lisp-level backtrace.
>> 
>> Ah, thanks.  I started gdb from the path of the emacs executable and the
>> Lisp backtrace was shown after typing "thread apply all bt";
>
> 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).

>> FWIW, while the backtrace was being shown in the shell, the raw PDF
>> changed to the image display in Emacs.
>
> I don't understand how could Emacs be running while GDB was showing
> the backtrace.  It shouldn't happen, because the executable to which
> GDB is attached is supposed to be stopped in its tracks.  What does
> this show, after you attach GDB and GDB shows its prompt?
>
>   (gdb) show non-stop
>
> It should say that non-stop mode is OFF.

It did say this.  And this time the Emacs display did not change until
after continuing from gdb, then the PDF image was immediately displayed.

>> Lisp Backtrace:
>> "image-size" (0x70824720)
>> 0x354bf60 PVEC_COMPILED
>> "gethash" (0x70820b38)
>> "pdf-cache--data-get" (0x70820d40)
>> "pdf-cache-number-of-pages" (0x70820f10)
>> ---Type <return> to continue, or q <return> to quit---
>> "terminal-live-p" (0x70820ea8)
>> "framep-on-display" (0x708210b8)
>> "overlayp" (0x70824718)
>> 0x92591e8 PVEC_COMPILED
>> "overlayp" (0x70824a48)
>> 0x92591e8 PVEC_COMPILED
>> "redisplay--update-region-highlight" (0x70824fd0)
>> "run-hook-with-args" (0x70824fc8)
>> "ignore" (0x70825310)
>> "apply" (0x70825308)
>> 0x9420638 PVEC_COMPILED
>> "redisplay_internal (C function)" (0x0)
>
> This Lisp backtrace contradicts the C backtrace of the main thread:
>
>> Thread 1 (Thread 0x7f9109a29bc0 (LWP 5077)):
>> #0  0x00007f910c590291 in __pselect (nfds=16, readfds=0x7ffc70826670, 
>> writefds=0x7ffc708265f0, 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=0x7ffc70826130)
>>     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=0x7ffc70826130)
>>     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=0x7ffc70826670, wfds=<optimized 
>> out>, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffc708268c0, sigmask=0x0)
>>     at /mnt/data/steve/git/emacs-master/src/thread.c:610
>> #4  0x00000000005d7c64 in xg_select (fds_lim=16, 
>> rfds=rfds@entry=0x7ffc70826960,---Type <return> to continue, or q <return> 
>> to quit---
>>  wfds=0x7ffc708268e0, efds=efds@entry=0x0, 
>> timeout=timeout@entry=0x7ffc708268c0, 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=97, nsecs=nsecs@entry=0, read_kbd=-1, 
>> do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), 
>> 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=make_number(97), 
>> 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=XIL(0x35f3093), prev_event=XIL(0), 
>> used_mouse_menu=used_mouse_menu@entry=0x7ffc70826d4b, 
>> 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=0x7ffc70826e10, prompt=prompt@entry=XIL(0), 
>> 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
>
> The C backtrace says we are idling, waiting for some input inside
> pselect, while the Lisp backtrace says we are in the image-size
> function, which was somehow invoked from pre-redisplay-function.  I'm
> confused...

As mentioned and as the transcript shows, there was no Lisp backtrace
this time.  I then tried again, starting emacs from the shell in the
emacs/src path, and the gdb session was the same as above: non-stop off,
no Lisp backtrace, and emacs display changed only after continuing from
gdb.  Then I repeated exactly what I did for my previous post: started
Emacs from the window manager menu (openbox), started gdb from the emacs
executable path in the shell, and again, non-stop was off and again
there was no Lisp backtrace, but this time, the buffer display did
change to the PDF image while the backtrace was being shown.  Maybe
there's a race condition involved in the delay.  I guess that doesn't
diminish your confusion...

Steve Berman

txtZEm84AuEpD.txt
Description: gdb backtrace