Created attachment 23743 [details] possibly monochrome raster print from an hp4195 ghostpcl 10.0.0 , build from Archlinux repo $ gdb --args gpcl6 -sDevice=display -dNOPAUSE dump.pcl .... Program received signal SIGSEGV, Segmentation fault. 0x000055555596165b in gx_path_new () (gdb) i s #0 0x000055555596165b in gx_path_new () #1 0x00005555559e8a6c in hpgl_PM () #2 0x00005555559ee596 in hpgl_do_reset () Sorry, don't really have time to recompile with syms + debug this further.
I don't have access to an archlinux box to test this, but an Ubuntu build of it works just fine. Things to try: 1) Build from our source, not from archlinux's, to rule out problems with any patches they may have added. 2) Run with -sDEVICE=bbox to rule out problems with the display device.
Hi, > Run with -sDEVICE=bbox to rule out problems with the display device. Done. Still segfaults. Doesn't look like Arch is doing anything special : one patch related to build timestamp, and ``` ./configure --prefix=/usr \ --with-ijs \ --with-jbig2dec \ --with-x \ --with-drivers=ALL \ --with-fontpath=/usr/share/fonts/gsfonts \ --without-versioned-path \ --enable-fontconfig \ --enable-freetype \ --enable-openjpeg \ --with-system-libtiff \ --with-libpaper \ --disable-compile-inits #--help # needed for linking with system-zlib ``` Will try filing a report with pkg maintainer anyway.
I've tried building from the 10.00.0 source (on Ubuntu) and I also cannot reproduce a problem with either a release or debug build. One thing; you've put -sDevice=display (and presumably -sDevice=bbox) when in fact that should be -sDEVICE=display. And yes, case is important. If you really are trying -sDevice instead of -sDEVICE then you won't have changed devices when you set bbox, so won't have eliminated the default device as a problem. If using DEVICE changes things then please reopen the bug and we'll look again.
Hi Ken, > One thing; you've put -sDevice=display (and presumably -sDevice=bbox) when > in fact that should be -sDEVICE=display. I did notice that and I had been trying -sDEVICE=bbox on the recent attempts. Someone else on Arch was able to reproduce and get a better backtrace: https://bugs.archlinux.org/task/77261?getfile=22314 Package maintainer also chimed in here https://bugs.archlinux.org/task/77261#comment214679 and mentions that apparently our package is built "against our system version libs and not the bundled ones."
(In reply to fenugrec from comment #4) > I did notice that and I had been trying -sDEVICE=bbox on the recent attempts. Oh well, scratch that then :-( > Someone else on Arch was able to reproduce and get a better backtrace: > https://bugs.archlinux.org/task/77261?getfile=22314 Well it looks like much the same trace, and its pretty much immediately in the execution, before the job actually gets run I believe. > Package maintainer also chimed in here > https://bugs.archlinux.org/task/77261#comment214679 > > and mentions that apparently our package is built "against our system > version libs and not the bundled ones." Yes, the Ghostscript family uses a number of other OSS libraries, and we ship the source for what we use. This means that we've tested those versions (and in some cases have extra patches). Package maintainers often choose to use the system shared libraries instead. There are arguments for and against that, I won't go into it here, but it does mean that: 1) We've never tested the specific set of code you are using 2) Can't reproduce your setup, because we don't know what system shared libraries you have, and probably couldn't reproduce your exact setup anyway. I'll desk check the code to see if I can deduce a problem, though it seems unlikely that system shared libraries are at fault. Well the only thing I can say is that the path being passed in has a pointer (segments) which is NULL. That does not occur for me, and it should not be possible though arguably the code should check. I'm not familiar enough with the PCL interpreter to have a useful opinion. The path in question is part of an hpgl_state_s structure, 'g.polygon.buffer.path' and there seems to be no checking done on that. At present I suspect this is either memory corruption, or uninitialised memory, both of which are going to be pretty much impossible to debug without running the exact same setup as you have. I did try an address sanitizer build and it declared no problems. All I can suggest for now is that you build from our source (with the third-party libraries we ship) which at least means you'll be using code we can replicate, should you be able to reproduce the problem.
Created attachment 23769 [details] gdb backtrace with debug info Thanks for the reply Ken. As I mentioned I don't really have time to dig into this but generated a slightly better backtrace, attached here. Not sure if helpful, since you already knew that pgls->g.polygon.buffer.path is NULL for some reason. Made a quick attempt at compiling with bundled libs but ran into issues that I have no energy to troubleshoot.
I was able to reproduce the problem, and have a "fix", but we're in the midst of servers moving homes, so I can't commit the change for a short while.
Finally pushed: https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=936d966618c8 Sorry for the delay.