bug#38176: 27.0.50; pdf-tools images do not display

bug#38176: 27.0.50; pdf-tools images do not display

[Óscar Fuentes]

With pdf-tools installed (version 0.90 available on Melpa-stable), visit
a multi-page PDF document. Press <Space> until the end of the first page
is visible, press <Space> again. Normally the second page would be
displayed, but the window shows an empty area. Press <Down> cursor
arrow, the image of the second page turns visible. Press C-x 3 then C-x
1 and the image disappears.

On my setup, after performing the steps described above, the vertical
lines which pdf-tools surrounds the image with are drawn on the
minibuffer window.

Also, on one occasion, Emacs entered what seemed an unresponsive state
with 100% cpu utilization. After attaching gdb the stack frame was:

(gdb) bt
#0  0x0000563f84a110b8 in add_row_entry (row=0x563f9b8200a0)
    at ../../emacs/src/dispnew.c:4268
#1  0x0000563f84a16910 in scrolling_window (tab_line_p=<optimized out>, w=0x5b9b)
    at ../../emacs/src/dispnew.c:4491
#2  0x0000563f84a16910 in update_window
    (w=w@entry=0x563f86c70b40, force_p=force_p@entry=true) at ../../emacs/src/dispnew.c:3573
#3  0x0000563f84a17301 in update_window_tree
    (w=w@entry=0x563f86c70b40, force_p=force_p@entry=true) at ../../emacs/src/dispnew.c:3330
#4  0x0000563f84a1754b in update_frame (f=f@entry=0x563f8b6a7700, force_p=<optimized out>, 
    force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false)
    at ../../emacs/src/dispnew.c:3219
#5  0x0000563f84a4b485 in redisplay_internal () at ../../emacs/src/xdisp.c:15669
#6  0x0000563f84ae120f in read_char
    (commandflag=1, map=XIL(0x563f9475d8e3), prev_event=XIL(0), used_mouse_menu=0x7ffdbf70da1b, end_time=0x0) at ../../emacs/src/keyboard.c:2488
#7  0x0000563f84ae3b6a in read_key_sequence
    (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
    at ../../emacs/src/keyboard.c:9536
#8  0x0000563f84ae520c in command_loop_1 () at ../../emacs/src/lisp.h:1032
#9  0x0000563f84b4a377 in internal_condition_case
    (bfun=bfun@entry=0x563f84ae5030 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x563f84adc2f0 <cmd_error>) at ../../emacs/src/eval.c:1355
#10 0x0000563f84ad7154 in command_loop_2 (ignore=ignore@entry=XIL(0))
    at ../../emacs/src/lisp.h:1032
#11 0x0000563f84b4a2d1 in internal_catch
    (tag=tag@entry=XIL(0xcc30), func=func@entry=0x563f84ad7130 <command_loop_2>, arg=arg@entry=XIL(0)) at ../../emacs/src/eval.c:1116
#12 0x0000563f84ad70fb in command_loop () at ../../emacs/src/lisp.h:1032
#13 0x0000563f84adbf06 in recursive_edit_1 () at ../../emacs/src/keyboard.c:714
#14 0x0000563f84adc232 in Frecursive_edit () at ../../emacs/src/keyboard.c:786
#15 0x0000563f84a0e866 in main (argc=2, argv=<optimized out>)

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)



In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit)
 of 2019-11-09 built on sky
Repository revision: f8284f1e408b38e6a3c0e2a1d5a465fefac6800a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid

bug#38176: 27.0.50; pdf-tools images do not display

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> With pdf-tools installed (version 0.90 available on Melpa-stable), visit
> a multi-page PDF document. Press <Space> until the end of the first page
> is visible, press <Space> again. Normally the second page would be
> displayed, but the window shows an empty area. Press <Down> cursor
> arrow, the image of the second page turns visible. Press C-x 3 then C-x
> 1 and the image disappears.

Is this a problem with the pdf-tools package?  If so, perhaps the bug
report should go to the author of that package instead of the Emacs bug
tracker?  We only deal with in-tree and GNU ELPA bugs here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38176: 27.0.50; pdf-tools images do not display

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Is this a problem with the pdf-tools package?  If so, perhaps the bug
> report should go to the author of that package instead of the Emacs bug
> tracker?  We only deal with in-tree and GNU ELPA bugs here...

The problem started after a change on Emacs on the last 10 weeks. The
display is corrupted and occasionally Emacs enters an infinite (or at
least very long) loop.

I'm fairly sure this is a problem introduced by the recent changes on
the redisplay engine. As soon as I have time I'll do a bisection, but
don't hold your breath.

bug#38176: 27.0.50; pdf-tools images do not display

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The problem started after a change on Emacs on the last 10 weeks. The
> display is corrupted and occasionally Emacs enters an infinite (or at
> least very long) loop.

Ah, I see.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38176: 27.0.50; pdf-tools images do not display

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The problem started after a change on Emacs on the last 10 weeks. The
>> display is corrupted and occasionally Emacs enters an infinite (or at
>> least very long) loop.
>
> Ah, I see.

I tried installing pdf-tools, but its requirements are... not obvious.
Do you have a recipe to reproduce the bug without pdf-tools?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38176: 27.0.50; pdf-tools images do not display

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I tried installing pdf-tools, but its requirements are... not obvious.
> Do you have a recipe to reproduce the bug without pdf-tools?  

No, sorry.

As for pdf-tools requirements, you need gcc + automake + autoconf + make
and some extra libraries. This commands install the libraries in Debian
and derivatives:

$ sudo apt install libpng-dev zlib1g-dev
$ sudo apt install libpoppler-glib-dev
$ sudo apt install libpoppler-private-dev

bug#38176: 27.0.50; pdf-tools images do not display

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> As for pdf-tools requirements, you need gcc + automake + autoconf + make
> and some extra libraries. This commands install the libraries in Debian
> and derivatives:
>
> $ sudo apt install libpng-dev zlib1g-dev
> $ sudo apt install libpoppler-glib-dev
> $ sudo apt install libpoppler-private-dev

Thanks; I got it to work now.

The bug is here:

(defun pdf-view-scroll-up-or-next-page (&optional arg)

[...]

        (when (or (= (window-vscroll) (image-scroll-up arg))

It's comparing the output of window-vscroll (which returns the position
in number-of-lines, not pixels) with the return value of
image-scroll-up, which returns a value in pixels.  It's not documented
at all what the latter function is supposed to return, so it looks like
a bug to me that pdf-tools relies on it.

(The function has changed a bit lately, but I didn't trace whether it's
really changed its return value.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38176: 27.0.50; pdf-tools images do not display

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thanks; I got it to work now.
>
> The bug is here:

Thank you very much, Lars. I'll forward this info to the pdf-tools
developer.

This bug report will remain open until I have a response from him.

bug#38176: 27.0.50; pdf-tools images do not display

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 17 Nov 2019 19:25:34 +0100
> Cc: 38176@debbugs.gnu.org
> 
>         (when (or (= (window-vscroll) (image-scroll-up arg))
> 
> It's comparing the output of window-vscroll (which returns the position
> in number-of-lines, not pixels) with the return value of
> image-scroll-up, which returns a value in pixels.  It's not documented
> at all what the latter function is supposed to return, so it looks like
> a bug to me that pdf-tools relies on it.

This was supposed to be fixed already, see bug#37578.

bug#38176: 27.0.50; pdf-tools images do not display

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sun, 17 Nov 2019 19:25:34 +0100
>> Cc: 38176@debbugs.gnu.org
>> 
>>         (when (or (= (window-vscroll) (image-scroll-up arg))
>> 
>> It's comparing the output of window-vscroll (which returns the position
>> in number-of-lines, not pixels) with the return value of
>> image-scroll-up, which returns a value in pixels.  It's not documented
>> at all what the latter function is supposed to return, so it looks like
>> a bug to me that pdf-tools relies on it.
>
> This was supposed to be fixed already, see bug#37578.

Hm...  That and the related bug#37874 fixes the problem in doc-view that
the change in image-mode caused, if I read this correctly.  But the
problem here was with the out-of-tree pdf-tools package, which
apparently needs the same fixes that doc-view got.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38176: 27.0.50; pdf-tools images do not display

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: ofv@wanadoo.es,  38176@debbugs.gnu.org
> Date: Sun, 17 Nov 2019 19:54:44 +0100
> 
> >> It's comparing the output of window-vscroll (which returns the position
> >> in number-of-lines, not pixels) with the return value of
> >> image-scroll-up, which returns a value in pixels.  It's not documented
> >> at all what the latter function is supposed to return, so it looks like
> >> a bug to me that pdf-tools relies on it.
> >
> > This was supposed to be fixed already, see bug#37578.
> 
> Hm...  That and the related bug#37874 fixes the problem in doc-view that
> the change in image-mode caused, if I read this correctly.  But the
> problem here was with the out-of-tree pdf-tools package, which
> apparently needs the same fixes that doc-view got.

No, 37874 is about pdf-tools.  The author says there the fix is on a
branch, so maybe that's why Óscar doesn't have it yet.

bug#38176: 27.0.50; pdf-tools images do not display

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> This was supposed to be fixed already, see bug#37578.

Indeed. While in the process of forwarding Lars' insights to pdf-tools,
noticed that they implemented a fix (still unavailable from the
distribution channels).

The fact that the minibuffer window got corrupted and Emacs entered an
infinite loop made me think that the problem was on Emacs alone.

Closing.