Bug#995392: ghostscript: ps2pdf trashes some characters
Control: notfound -1 9.53.3~dfsg-8 Apologies, I somehow missed the part about pdftotext and the glyph's normal appearance in your original message. I can reproduce that with both files produced by 9.54.0~dfsg-5 but *not* the one produced by 9.53.3~dfsg-8 (attached for reference), using the same pdftotext version (poppler-utils 20.09.0-3.1) for all files. chartest-gs-jaa-9.53.3.pdf Description: Adobe PDF document
Bug#995392: ghostscript: ps2pdf trashes some characters
Hi Vincent, For what it's worth, I do not see the corruption you're describing with `gv chartest-gs.pdf` nor when converting it myself from your input file using versions 9.53.3~dfsg-8 or 9.54.0~dfsg-5. I noticed that your file used a different internal conversion command compared to when I try it with ps2pdf 9.54.0~dfsg-5: Yours: %%Invocation: path/gs -dPrinted=false -P- -dSAFER -dCompatibilityLevel=1.5 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.5 ? Mine: %%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 ? Invoking it like your command manually did not make a difference for me though, with the output file being identical except for the expected differences in the version string, timestamps, and UUIDs. I have attached my `ps2pdf chartest.pdf chartest-gs-jaa.pdf` output file (created with 9.54.0~dfsg-5). Cheers, JustAnotherArchivist chartest-gs-jaa.pdf Description: Adobe PDF document
Bug#898048: gdb: Couldn't write extended state status: Bad address
Dear all, I was now able to test my hypothesis that this is/was a bug in Linux that has been fixed since. Here's what I tried: 0. Under the old system, the test failed with the previously mentioned error message. To make sure it wasn't caused by some weird system state, I rebooted the machine and tested again. This did not change anything. 1. I upgraded linux-image-amd64 from 4.9+80+deb9u5 to 4.9+80+deb9u6. This installed linux-image-4.9.0-8-amd64 version 4.9.130-2 in addition to the previously installed and used linux-image-4.9.0-7-amd64 version 4.9.110-3+deb9u2. After rebooting into the new kernel, the test still failed. 2. Since that didn't help, I tried the exact same kernel image that works on the other, very similar machine, i.e. downgraded linux-image-4.9.0-8-amd64 to 4.9.110-3+deb9u4. After rebooting, the test still failed. I then upgraded all installed packages to their latest versions. Unsurprisingly given the differences in package versions, that didn't change anything. So I went back to the original idea that it's a GDB bug. I searched around a bit whether there were any other known issues with GDB and/or this CPU model, and I found a thread about cuda-gdb failing on certain versions with this Intel 6140 CPU [0] and the related GDB bug report [1]. It indicates that some bugs related to this CPU's (extended) instruction set have been fixed in a higher GDB version, which lead me to try out newer versions. Lo and behold, it works correctly with GDB 8.0 (both compiled from source and the 8.0-1 Debian package). I bisected the 2288 commits between GDB 7.12 and 8.0 and identified upstream commit 51547df6 [2] as the one fixing this issue. Cheers, JAA [0] https://devtalk.nvidia.com/default/topic/1038201/cuda-gdb/cuda-gdbserver-cannot-be-connected-unknown-register-ymm0h-requested/ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22137 [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=51547df62c155231530ca502c485659f3d2b66cb
Bug#898048: gdb: Couldn't write extended state status: Bad address
Dear Bill, dear Héctor, I am also experiencing this issue, and I may be able to narrow it down a bit further. Specifically, I have two different stretch machines, only one of which has this issue. The two machines are very similar in terms of software: one was last upgraded in early Septemberwhile the other was only installed about two weeks ago. As for the underlying hardware (these are VMs), there are some differences; most notably, they use a different CPU (Intel E5-2680v4 vs. Intel 6140). The minimal example works fine on the former VM and fails with the stated message on the latter. The two machines use identical versions of almost all installed packages, including gdb (7.12-6) and libc6 (2.24-11+deb9u3). There are only few exceptions, most of which seem completely unrelated (e.g. slightly different versions of Python and git). There is however one important difference, and that's the kernel: the working machine is running linux-image-4.9.0-8-amd64 (4.9.110-3+deb9u4) while the "broken" one uses linux-image-4.9.0-7-amd64 (4.9.110-3+deb9u2). Unfortunately, I cannot test at this time whether upgrading the kernel on the "broken" machine fixes the issue due to long-running processes. I will report back once I get a chance to do so. Cheers, JAA
