[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen Berman
Subject: bug#34138: 27.0.50; Delayed display of PDF file images
Date: Sun, 20 Jan 2019 21:45:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On Sun, 20 Jan 2019 19:42:58 +0200 Eli Zaretskii <address@hidden> wrote:

>> From: Stephen Berman <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden,
>> address@hidden
>> 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 (address@hidden)
>>     at /mnt/data/steve/git/emacs-master/src/thread.c:580
>> #2  0x0000000000542d88 in flush_stack_call_func (address@hidden 
>> <really_call_select>, address@hidden)
>>     at /mnt/data/steve/git/emacs-master/src/alloc.c:5229
>> #3  0x00000000005bd24f in thread_select (func=<optimized out>, 
>> address@hidden, address@hidden, wfds=<optimized out>, address@hidden, 
>> address@hidden, sigmask=0x0)
>>     at /mnt/data/steve/git/emacs-master/src/thread.c:610
>> #4  0x00000000005d7c64 in xg_select (fds_lim=16, address@hidden,---Type 
>> <return> to continue, or q <return> to quit---
>>  wfds=0x7ffc708268e0, address@hidden, address@hidden, address@hidden)
>>     at /mnt/data/steve/git/emacs-master/src/xgselect.c:117
>> #5  0x000000000059daf3 in wait_reading_process_output (address@hidden, 
>> address@hidden, read_kbd=-1, address@hidden, address@hidden(0), 
>> address@hidden, just_wait_proc=0) at 
>> /mnt/data/steve/git/emacs-master/src/process.c:5405
>> #6  0x0000000000424e63 in sit_for (address@hidden(97), address@hidden, 
>> address@hidden)
>>     at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
>> #7  0x00000000004f769e in read_char (commandflag=1, 
>> address@hidden(0x35f3093), prev_event=XIL(0), address@hidden, 
>> address@hidden) at /mnt/data/steve/git/emacs-master/src/lisp.h:751
>> #8  0x00000000004f81ec in read_key_sequence (address@hidden, 
>> address@hidden(0), address@hidden, address@hidden, address@hidden, 
>> address@hidden)
>>     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

Attachment: txtpvcS7dvgzT.txt
Description: gdb backtrace

reply via email to

[Prev in Thread] Current Thread [Next in Thread]