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).
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:
--
,
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien
Related
Bugs:
#293Denis: 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.
Intel Pentium Silver N5000
No. With that variable set to 1 everything works perfect.
Last edit: Denis Karpovskii 2018-10-07
On Sunday, October 7, 2018 6:15:41 PM EDT Denis Karpovskii wrote:
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.
Yeah, it works now. Thank you.
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).
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....