Menu

#293 Segmentation fault when trying to open a djvu file with djview4

djvulibre
closed
nobody
None
5
2018-10-08
2018-10-07
No

Hi.
When I try to open any file with djview4, it crashes with a segmentation fault.
Attached a full backtrace.
I tried then to compile djvulibre and djview4 from sources and launch using the freshly created binaries, but it still crashes.
What I did:

# cd in djvulibre and djview sources
./configure --prefix=/usr/local
make -j4
sudo make install

# then launch djview using the freshly compiled version of the library
cd /usr/local/bin
LD_LIBRARY_PATH=/usr/local/lib ./djview ~/path/to/djvu/file
# segmentation fault

Affected files: Every file I tried to open from Djvu site

OS: KDE neon 18.04 (based on ubuntu 18.04).

1 Attachments

Related

Bugs: #293

Discussion

  • Janusz

    Janusz - 2018-10-07

    No problem here with

    Package: djview4
    Version: 4.10.6-6

    Debian Release: buster/sid

    Regards

    Janusz

    On Sun, Oct 07 2018 at 8:17 GMT, Denis Karpovskii wrote:


    [bugs:#293] Segmentation fault when trying to open a djvu file with djview4

    Status: open
    Group: djvulibre
    Created: Sun Oct 07, 2018 08:17 AM UTC by Denis Karpovskii
    Last Updated: Sun Oct 07, 2018 08:17 AM UTC
    Owner: nobody
    Attachments:

    • gdb_log.txt (13.1 kB; text/plain)

    Hi.
    When I try to open any file with djview4, it crashes with a segmentation fault.
    Attached a full backtrace.
    I tried then to compile djvulibre and djview4 from sources and launch using the freshly created binaries, but it still
    crashes.
    What I did:

    cd in djvulibre and djview sources

    ./configure --prefix=/usr/local
    make -j4
    sudo make install

    then launch djview using the freshly compiled version of the library

    cd /usr/local/bin
    LD_LIBRARY_PATH=/usr/local/lib ./djview ~/path/to/djvu/file

    segmentation fault

    Affected files: Every file I tried to open from Djvu site

    OS: KDE neon 18.04 (based on ubuntu 18.04).


    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/293/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

    --
    ,
    Janusz S. Bien
    emeryt (emeritus)
    https://sites.google.com/view/jsbien

     

    Related

    Bugs: #293

  • Leon Bottou

    Leon Bottou - 2018-10-07

    Denis: what kind of processor is found in your computer? Exact model..

    Also, does the crash subsists if you set the environment variable
    $ exportLIBDJVU_DISABLE_MMX=1.

     
  • Denis Karpovskii

    Denis: what kind of processor is found in your computer? Exact model..

    Intel Pentium Silver N5000

    Also, does the crash subsists if you set the environment variable

    No. With that variable set to 1 everything works perfect.

     

    Last edit: Denis Karpovskii 2018-10-07
    • Leon Bottou

      Leon Bottou - 2018-10-07

      On Sunday, October 7, 2018 6:15:41 PM EDT Denis Karpovskii wrote:

      Intel Pentium Silver N5000

      I just pushed a change in djvulibre-3.5 git that eliminates a test that was inherited from ancient processors and relies on the equally ancient SMSW instruction.
      The diff is at https://sourceforge.net/p/djvu/djvulibre-git/ci/8407dd3421f720ab2e1a61e3f1e60e08967f98db/

      The old code was known to work on a lot of intel64 processors, but yours may be different.
      Maybe this solves your problem.

      • Leon
       
      • Denis Karpovskii

        Yeah, it works now. Thank you.

         
  • Leon Bottou

    Leon Bottou - 2018-10-08
    • status: open --> closed
     
  • Leon Bottou

    Leon Bottou - 2018-10-08

    Fixed. Thanks.

    Your processor, the Pentium Silver N5000 is based on a Goldmond core which is a kind of Atom instead of a mainstream Intel x86 processor. Clearly there are differences in the obscure parts of the instruction set (I suspect the SMSW instruction).

     
  • Leon Bottou

    Leon Bottou - 2018-10-08

    More information at
    https://lwn.net/Articles/738209/

    Apparently the linux kernel now sets bit CR4.UMIP which causes a GP fault when SMSW is executed. The kernel is supposed to catch the trap and return a dummy value. Why this fails to happen on your system is unknown....

     

Log in to post a comment.

MongoDB Logo MongoDB