Re: [OpenBSD -current] xpdf: core dump
Stuart Henderson wrote: > On 2024/01/27 12:41, Marcel Logen wrote: > > I do a "pkg_add -u" almost every two weeks (after "sysupgrade -s"). > > Are there any errors or warnings? No. > What does pkg_check say? | t20# pkg_check -n -v | Packing-list sanity: ok | Direct dependencies: ok | Reverse dependencies: ok | Files from packages: ok | t20# Marcel
Re: [OpenBSD -current] xpdf: core dump
On 2024/01/27 12:41, Marcel Logen wrote: > I do a "pkg_add -u" almost every two weeks (after "sysupgrade -s"). Are there any errors or warnings? What does pkg_check say?
Re: [OpenBSD -current] xpdf: core dump
Matthieu Herrb wrote: On Fri, Jan 26, 2024 at 12:53:01PM +0100, Marcel Logen wrote: [...] > > | Information for inst:xpdf-4.04p1v0 [...] > > | xpdf:/usr/X11R6/lib/libX11.so.17.1: /usr/X11R6/lib/libX11.so.18.0 : > > WARNING: symbol(_XkeyTable) size mismatch, relink your program > > | QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > > '/tmp/runtime-user20' > > | Cannot mix incompatible Qt library (5.9.8) with this library (5.15.11) > > | Abort trap (core dumped) > You have some package installed that was not updated properly. Hm, OK ... > It has been almost 2 years since libX11 shared lib revision was bumped > to 18.0. Thanks. > go to /var/db/pkg and run: > > grep X11\\.17 */+CONTENTS > > to figure out which packages need some kind of manual update | t20$ grep X11\\.17 */+CONTENTS | t20$ | t20$ grep -e 'X11.*17' */+CONTENTS | motif-2.3.8p1/+CONTENTS:lib/X11/bindings/intergraph17 | t20$ grep -i -e 'x11' xpdf-4.04p1v0/+CONTENTS | @depend x11/qt5/qtbase,-main:qtbase-*:qtbase-5.15.11pl148 | t20$ grep -e 'depe' -e 'name' -e 'url' -e 'version' xpdf-4.04p1v0/+CONTENTS | @name xpdf-4.04p1v0 | @url https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/xpdf-4.04p1v0.tgz | @version 11 | @depend graphics/png:png-*:png-1.6.40 | @depend print/ghostscript/gnu-fonts:ghostscript-fonts-*:ghostscript-fonts-8.11p3 | @depend print/libpaper:libpaper-*:libpaper-2.1.3 | @depend x11/qt5/qtbase,-main:qtbase-*:qtbase-5.15.11pl148 | t20$ > (assuming > that you have run pkg_add -u on a regular basis in the last 2 years). I do a "pkg_add -u" almost every two weeks (after "sysupgrade -s"). Marcel
Re: [OpenBSD -current] xpdf: core dump
On Fri, Jan 26, 2024 at 12:53:01PM +0100, Marcel Logen wrote: > Hello, > > I'm using OpenBSD -current. Since some weeks (or months?) I get > a core dump when trying to start "xpdf". > > | t20$ head -n 1 /etc/motd > | OpenBSD 7.4-current (GENERIC.MP) #1625: Thu Jan 25 09:16:39 MST 2024 > > | t20$ uname -a > | OpenBSD t20 7.4 GENERIC.MP#1625 amd64 > > | t20$ pkg_info xpdf | grep -e 'Inf' -e 'Main' > | Information for inst:xpdf-4.04p1v0 > | Maintainer: The OpenBSD ports mailing-list > > | t20$ xpdf > | xpdf:/usr/X11R6/lib/libX11.so.17.1: /usr/X11R6/lib/libX11.so.18.0 : > WARNING: symbol(_XkeyTable) size mismatch, relink your program > | QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user20' > | Cannot mix incompatible Qt library (5.9.8) with this library (5.15.11) > | Abort trap (core dumped) > | t20$ > > What can I do, or is it a problem of the package maintainer? > Hi, You have some package installed that was not updated properly. It has been almost 2 years since libX11 shared lib revision was bumped to 18.0. go to /var/db/pkg and run: grep X11\\.17 */+CONTENTS to figure out which packages need some kind of manual update (assuming that you have run pkg_add -u on a regular basis in the last 2 years). -- Matthieu Herrb
Re: [OpenBSD -current] xpdf: core dump
Marcel Logen wrote (2024-01-26 12:53 CET): > | t20$ xpdf > | xpdf:/usr/X11R6/lib/libX11.so.17.1: /usr/X11R6/lib/libX11.so.18.0 : > WARNING: symbol(_XkeyTable) size mismatch, relink your program > | QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user20' > | Cannot mix incompatible Qt library (5.9.8) with this library (5.15.11) > | Abort trap (core dumped) > | t20$ > > What can I do, or is it a problem of the package maintainer? This happens after you ran pkg_add -u? My xpdf is not looking for libX11.so.17.1 anymmore and it works fine. - Stefan
[OpenBSD -current] xpdf: core dump
Hello, I'm using OpenBSD -current. Since some weeks (or months?) I get a core dump when trying to start "xpdf". | t20$ head -n 1 /etc/motd | OpenBSD 7.4-current (GENERIC.MP) #1625: Thu Jan 25 09:16:39 MST 2024 | t20$ uname -a | OpenBSD t20 7.4 GENERIC.MP#1625 amd64 | t20$ pkg_info xpdf | grep -e 'Inf' -e 'Main' | Information for inst:xpdf-4.04p1v0 | Maintainer: The OpenBSD ports mailing-list | t20$ xpdf | xpdf:/usr/X11R6/lib/libX11.so.17.1: /usr/X11R6/lib/libX11.so.18.0 : WARNING: symbol(_XkeyTable) size mismatch, relink your program | QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user20' | Cannot mix incompatible Qt library (5.9.8) with this library (5.15.11) | Abort trap (core dumped) | t20$ What can I do, or is it a problem of the package maintainer? TIA, Marcel
Re: xpdf core dump
On Mon, Jul 13, 2009 at 11:43:18PM +0100, Stuart Henderson wrote:
On 2009/07/13 22:23, Matthias Kilian wrote:
On Sun, Jul 12, 2009 at 01:31:29PM -0400, Predrag Punosevac wrote:
I think, I am just saying goodbye to xpdf after probably 20 years. I can
not even recall when I started using xpdf. I am now mupdf guy thanks
to Stuart and the gang!!!
mupdf is promising, but it still lacks some features (like copywaste,
it should work with right-click to select, but doesn't at the moment,
a function needs rewriting first.
#if 0 /* pdf_loadtextfromtree needs rewriting, so removing this temporarily */
I've a patch for this one, it works when pasting to terminals, but wont work
with firefox.
xpdf copy/paste have a better looking ouput anyway.
text search, zoom to width).
I don't miss zoom-to-width much, but I do miss search, it's the main
reason I have for switching back to xpdf temporarily.
also, aes is not implemented yet, only arc4encrypt, but I've only bumped
into that once so far.
aes is in sumatrapdf (win32 frontend to fitz). it could be backported easily.
$ head sumatrapdf-read-only/mupdf/fitz/*aes.c
== sumatrapdf-read-only/mupdf/fitz/crypt_aes.c ==
/* Most of this code is extracted from public domain libtomcrypt 1.17
(http://libtom.org/) */
#include fitz_base.h
#include fitz_stream.h
#define LTC_NO_ASM 1
/* This part extracted from tomcrypt.h in libtomcrypt 1.17 */
== sumatrapdf-read-only/mupdf/fitz/filt_aes.c ==
/* Written by Krzysztof Kowalczyk (http://blog.kowalczyk.info)
This code is in public domain.
*/
#include fitz_base.h
#include fitz_stream.h
typedef struct fz_aesc_s fz_aesc;
struct fz_aesc_s
{
the complete list of missing features (to me) is:
- rendering AcroForms
- rendering Notes (dont know exactly what it is. but if it should be
displayed...)
- search
- print
- table of contents (bookmarks)
for the in tree version:
- jbig
- JPXDecode. it is broken with jasper but upstream added openjpeg alternative
dependency (on Thu, 25 Jun 2009 10:52:28) which one works.
with jasper, on page 34 of:
http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/javascript/AcroJSGuide.pdf
$ mupdf -p 34 AcroJSGuide.pdf
error: cannot decode code stream
+ fitz/filt_jpxd.c:104: fz_processjpxd(): jasper error: jas_image_decode()
| fitz/stm_filter.c:32: fz_process(): cannot process filter
| fitz/filt_pipeline.c:134: fz_processpipeline(): cannot process tail filter
| fitz/stm_filter.c:32: fz_process(): cannot process filter
| fitz/stm_read.c:110: fz_readimp(): cannot process filter
| fitz/stm_read.c:281: fz_readbytex(): cannot read data
\ fitz/stm_open.c:45: fz_dropstream(): dropped unhandled ioerror
warning: truncated image; proceeding anyway
Re: xpdf core dump
Matthias Kilian k...@outback.escape.de wrote: mupdf is promising, but it still lacks some features (like copywaste, text search, zoom to width). ... and running with a remote DISPLAY. -- Christian naddy Weisgerber na...@mips.inka.de
Re: xpdf core dump
On 2009/07/14 11:52, Roberto Fernandez wrote: aes is in sumatrapdf (win32 frontend to fitz). it could be backported easily. that would be useful. I forgot where my test file which needs it is, but there are some around.. for the in tree version: - jbig we don't have jbig2dec in ports yet or I would have added this already :) - JPXDecode. it is broken with jasper but upstream added openjpeg alternative dependency (on Thu, 25 Jun 2009 10:52:28) which one works. with jasper, on page 34 of: http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/javascript/AcroJSGuide.pdf $ mupdf -p 34 AcroJSGuide.pdf error: cannot decode code stream + fitz/filt_jpxd.c:104: fz_processjpxd(): jasper error: jas_image_decode() | fitz/stm_filter.c:32: fz_process(): cannot process filter | fitz/filt_pipeline.c:134: fz_processpipeline(): cannot process tail filter | fitz/stm_filter.c:32: fz_process(): cannot process filter | fitz/stm_read.c:110: fz_readimp(): cannot process filter | fitz/stm_read.c:281: fz_readbytex(): cannot read data \ fitz/stm_open.c:45: fz_dropstream(): dropped unhandled ioerror warning: truncated image; proceeding anyway openjpeg has LP64 problems (in dwt_decode_tile) so, at the moment, jasper is a better choice for the package. I'll look at fixing openjpeg though.
Re: xpdf core dump
Matthias Kilian k...@outback.escape.de wrote: mupdf is promising, but it still lacks some features (like copywaste, text search, zoom to width). It is essentially a PDF display widget. Now somebody needs to write a document viewer around it. :- I just tried mupdf and xpdf side by side on my AlphaPC 164, a sufficiently slow machine, and mupdf is appreciably faster there. I wonder how it fares on ARM. -- Christian naddy Weisgerber na...@mips.inka.de
Re: xpdf core dump
On Sun, Jul 12, 2009 at 01:31:29PM -0400, Predrag Punosevac wrote: I think, I am just saying goodbye to xpdf after probably 20 years. I can not even recall when I started using xpdf. I am now mupdf guy thanks to Stuart and the gang!!! mupdf is promising, but it still lacks some features (like copywaste, text search, zoom to width). I have tested the latest xpdf on 4.5 stable. I can reproduce the same crash with the newest version. I am installing current at this very moment on a machine which will be used for testing purposes. I would be surprised that if xpdf behaves differently on current. Did you check wether the pdf file you're using is the same that sthen@ mentioned and that doesn't cause crashes for him and for me? I just want to be sure that we're testing the same file. $ md5 bpu02659.pdf MD5 (bpu02659.pdf) = b68c0a47869ab4147c35460d88366c96 http://openbsd.dead-parrot.de/print_texlive_base.diff http://openbsd.dead-parrot.de/x11_kde_graphics3.diff [...] Point taken. I will be testing TeXLive with your patches. I use TeXLive no less than 3-4 hours every day. good. [...] Do you remember last month your conversation with Matt when he was complaining about the crash on the similar document? I just could not reproduce it on 4.4/amd64 stable running bsd.mp kernel. I didn't have the time to debug it, but the second document he mentioned still causes crashes here. Ciao, Kili
Re: xpdf core dump
On 2009/07/13 22:23, Matthias Kilian wrote: On Sun, Jul 12, 2009 at 01:31:29PM -0400, Predrag Punosevac wrote: I think, I am just saying goodbye to xpdf after probably 20 years. I can not even recall when I started using xpdf. I am now mupdf guy thanks to Stuart and the gang!!! mupdf is promising, but it still lacks some features (like copywaste, it should work with right-click to select, but doesn't at the moment, a function needs rewriting first. #if 0 /* pdf_loadtextfromtree needs rewriting, so removing this temporarily */ text search, zoom to width). I don't miss zoom-to-width much, but I do miss search, it's the main reason I have for switching back to xpdf temporarily. also, aes is not implemented yet, only arc4encrypt, but I've only bumped into that once so far. I have tested the latest xpdf on 4.5 stable. I can reproduce the same crash with the newest version. I am installing current at this very moment on a machine which will be used for testing purposes. I would be surprised that if xpdf behaves differently on current. Did you check wether the pdf file you're using is the same that sthen@ mentioned and that doesn't cause crashes for him and for me? I just want to be sure that we're testing the same file. $ md5 bpu02659.pdf MD5 (bpu02659.pdf) = b68c0a47869ab4147c35460d88366c96 that's the one I have too.
Re: xpdf core dump
Matthias Kilian k...@outback.escape.de wrote: Did you check wether the pdf file you're using is the same that sthen@ mentioned and that doesn't cause crashes for him and for me? I just want to be sure that we're testing the same file. $ md5 bpu02659.pdf MD5 (bpu02659.pdf) = b68c0a47869ab4147c35460d88366c96 Yes, Kili it is that particular file. You have the right file. I checked again including md5 sum. It crashes the latest xpdf on 4.5 stable i386 running bsd.mp kernel. $ pkg_info xpdf Information for inst:xpdf-3.02.3 Best, Predrag
Re: xpdf core dump
Brynet bry...@gmail.com wrote: Predrag wrote: mupdf doesn't compile on stable Here are the patches you'll need on 4.5. -Brynet Hi Brynet, I can just say wow! I am just blown away. It took no more than 6 hours since I reported a problem with XPDF for OpenBSD community to suggest better alternative solution which doesn't use problematic library for rendering and even backported it to stable. Your patches worked as charm. I tested already mupdf on 4.5 stable and it rocks. I put mupdf to test on the same HP manual which crashed XPDF. No problems. It worked like a charm. Then I tested mupdf with some very complicated slides generated by Powerdot class of LaTeX presentations. Epdfview, and GGV have serious problems with that documents. Mupdf worked as charm. I can just say big thanks to Stuart who ported the mupdf to OpenBSD. Mupdf+pdfjam is all I personally need to deal with PDF documents. Thanks, Predrag
Re: xpdf core dump
On Sun, Jul 12, 2009 at 02:07:37AM -0400, Predrag Punosevac wrote: Brynet bry...@gmail.com wrote: Predrag wrote: mupdf doesn't compile on stable Here are the patches you'll need on 4.5. -Brynet Hi Brynet, I can just say wow! I am just blown away. It took no more than 6 hours since I reported a problem with XPDF for OpenBSD community to suggest better alternative solution which doesn't use problematic library for rendering and even backported it to stable. Your patches worked as charm. I tested already mupdf on 4.5 stable and it rocks. I put mupdf to test on the same HP manual which crashed XPDF. No problems. It worked like a charm. Then I tested mupdf with some very complicated slides generated by Powerdot class of LaTeX presentations. Epdfview, and GGV have serious problems with that documents. Mupdf worked as charm. I can just say big thanks to Stuart who ported the mupdf to OpenBSD. Mupdf+pdfjam is all I personally need to deal with PDF documents. Thanks, Predrag +1, mupdf is all I need know. -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
Re: xpdf core dump
On Sat, Jul 11, 2009 at 11:03:32PM +0100, Stuart Henderson wrote: I think that this is a well known issue but I would like to document it anyway. I am getting xpdf core dumped when I try to see the following document http://h2.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDFprodSeriesId=30377targetPage=http%3A%2F%2Fbizsupport1.austin.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fbpu02659%2Fbpu02659.pdf The document is rendering without problems when I use epdfview. Welcome to the wonderful world of N+1 slightly different versions and forks of xpdf (and poppler) ;-) P.S. Kili, if you have those patches for xpdf could you please post them on one place or send them to my private email. I will be testing this week HPLIP so I would like to test xpdf as well. I don't have patches for xpdf. If you want to test the latest xpdf, just try the -current port (it should build cleanly even on 4.5). But I've patches for texlife and kdegraphics that need testing: http://openbsd.dead-parrot.de/print_texlive_base.diff http://openbsd.dead-parrot.de/x11_kde_graphics3.diff Note that they don't contain Miod's patch to SplashXPath.cc, because texlive just doesn't contain the splash stuff, and kdegraphics contains a different fix (obviously taken from poppler). hmm, that url doesn't work (probably because of the session id), but assuming this is the same document, it works on xpdf (amd64 -current) for me; http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/bpu02659/bpu02659.pdf maybe it was fixed in the security update to 3.02pl3 or miod's out of bounds access that are only in OPENBSD_4_6/-current. I tried the -current port without Miod's diff, and even the OPENBSD_4_5 version on amd64 and i386, and it didn't crash. This seems to be one of those nice bugs that are difficult to reproduce. Ciao, Kili
Re: xpdf core dump
Matthias Kilian k...@outback.escape.de wrote: Welcome to the wonderful world of N+1 slightly different versions and forks of xpdf (and poppler) ;-) I think, I am just saying goodbye to xpdf after probably 20 years. I can not even recall when I started using xpdf. I am now mupdf guy thanks to Stuart and the gang!!! I don't have patches for xpdf. If you want to test the latest xpdf, just try the -current port (it should build cleanly even on 4.5). I have tested the latest xpdf on 4.5 stable. I can reproduce the same crash with the newest version. I am installing current at this very moment on a machine which will be used for testing purposes. I would be surprised that if xpdf behaves differently on current. But I've patches for texlife and kdegraphics that need testing: http://openbsd.dead-parrot.de/print_texlive_base.diff http://openbsd.dead-parrot.de/x11_kde_graphics3.diff Note that they don't contain Miod's patch to SplashXPath.cc, because texlive just doesn't contain the splash stuff, and kdegraphics contains a different fix (obviously taken from poppler). Point taken. I will be testing TeXLive with your patches. I use TeXLive no less than 3-4 hours every day. hmm, that url doesn't work (probably because of the session id), but assuming this is the same document, it works on xpdf (amd64 -current) for I tried the -current port without Miod's diff, and even the OPENBSD_4_5 version on amd64 and i386, and it didn't crash. This seems to be one of those nice bugs that are difficult to reproduce. This is very interesting because I can reproduce the bag with the latest version compiled on 4.5 stable. Do you remember last month your conversation with Matt when he was complaining about the crash on the similar document? I just could not reproduce it on 4.4/amd64 stable running bsd.mp kernel. Ciao, Kili Thanks Kili, Predrag
xpdf core dump
Hi Ports, I think that this is a well known issue but I would like to document it anyway. I am getting xpdf core dumped when I try to see the following document http://h2.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDFprodSeriesId=30377targetPage=http%3A%2F%2Fbizsupport1.austin.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fbpu02659%2Fbpu02659.pdf The document is rendering without problems when I use epdfview. I am running 4.5/i386 stable on this particular desktop. Cheers, Predrag P.S. Kili, if you have those patches for xpdf could you please post them on one place or send them to my private email. I will be testing this week HPLIP so I would like to test xpdf as well.
Re: xpdf core dump
On 2009/07/11 17:31, Predrag Punosevac wrote: Hi Ports, I think that this is a well known issue but I would like to document it anyway. I am getting xpdf core dumped when I try to see the following document http://h2.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDFprodSeriesId=30377targetPage=http%3A%2F%2Fbizsupport1.austin.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fbpu02659%2Fbpu02659.pdf The document is rendering without problems when I use epdfview. I am running 4.5/i386 stable on this particular desktop. Cheers, Predrag P.S. Kili, if you have those patches for xpdf could you please post them on one place or send them to my private email. I will be testing this week HPLIP so I would like to test xpdf as well. hmm, that url doesn't work (probably because of the session id), but assuming this is the same document, it works on xpdf (amd64 -current) for me; http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/bpu02659/bpu02659.pdf maybe it was fixed in the security update to 3.02pl3 or miod's out of bounds access that are only in OPENBSD_4_6/-current. but let me plug mupdf anyway because it's great ;-) xpdf takes quite a while to draw this on my machine - 3.3 seconds. mupdf literally *half* that, and imho the font rendering is far more pleasant. in -current, pkg_add mupdf. the -current port of this will most likely build on 4.5 too if you want to try it.
Re: xpdf core dump
in -current, pkg_add mupdf. the -current port of this will most likely build on 4.5 too if you want to try it. Hi Stuart, mupdf doesn't compile on stable cc -c -o /usr/obj/ports/mupdf-0.4/build-i386/ximage.o -Wall -std=c99 -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -I/usr/local/include -O2 -pipe -DHAVE_JASPER -DNEED_STRLCPY -DNEED_STRSEP -DNEED_GETOPT -Iapps/unix -Ifitz -Imupdf -Iapps apps/unix/ximage.c ...skipped mupdf for lack of libmupdf.a... *** Error code 1 I guess it has a problem to link to libmupdf.a library. It is probably not too difficult to patch so that it can compile on stable. It looks very interesting. By the way I forgot to say in my previous message that I am running bsd.mp kernel on 4.5/i386 stable. Somebody reported about month ago problem with xpdf on i386 and I recall not being able to reproduce the problem on amd64. I checked the same document with Acroread and renders without problems. I am mentioning that because unlike Opera and few other Linux binaries, Acroread works rock stable on bsd.mp kernel. I was very surprised. Cheers, Predrag
Re: xpdf core dump
William Yodlowsky b...@openbsd.rutgers.edu wrote: I have an xpdf package for 4.5-stable/i386 for xpdf-3.02.3 at: http://openbsd.rutgers.edu/xpdf-3.02.3.tgz SHA1 (xpdf-3.02.3.tgz) = 2de911e02efe00b71866245d091726aba30c087d This may become what goes into official -stable. Does it work for your problem pdf? Thanks. Hi William, xpdf-3.02.3 depends on xpdf-utils-3.02.3 so I installed both packages from your web-site. Unfortunately, new version of xpdf does not fix the problem. xpdf is still dumping core on that HP manual full of graphics By the way, if you are submitting xpdf to stable note that xfig-3.2.5p2 which is backported to stable due to the security reasons requires xpdf to run so you would have to build xfig-3.2.5p2 against xpdf-3.02.3 and xpdf-utils-3.02.3. I had no other dependency issues on my particular installation. Most Kind Regards, Predrag
Re: xpdf core dump
Predrag wrote: mupdf doesn't compile on stable Here are the patches you'll need on 4.5. -Brynet mupdf45.tgz Description: GNU Zip compressed data
