* Bernhard R. Link [2007-07-19 16:09:21 +0200]: > package gv > tags 332431 + unreproducible > thanks > > Hi, I've tried to reproduce 332431, but I do not get crash looking at > page 2 of http://www.arxiv.org/ps/astro-ph/0407201, neither with the > sarge versions (3.6.1-10, &sarge1, &sarge2), nor with etch's 3.6.2-3 > nor with unstable's 3.6.3. > > Can you still see this bug? Could you send a backtrace where the write > you speak about is called?
Yes, I can reproduce the bug under sarge with the 3.6.1-10sarge2 version. I can't reproduce the crash under etch. (There is only a milder problem, that gv and evince --- but NOT gs -sDEVICE=x11 --- fail to display most of the text on that page; but that may only signal a bug in that PostScript file, most probably in the figure on that page.) Here is the backtrace: Program received signal SIGPIPE, Broken pipe. 0xb7ca895e in write () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7ca895e in write () from /lib/tls/libc.so.6 #1 0x08053cd0 in ?? () #2 0x00000009 in ?? () #3 0x080d6158 in ?? () #4 0x00000200 in ?? () #5 0x00000000 in ?? () #6 0x0000000d in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0xb7e7a6b0 in ?? () from /usr/X11R6/lib/libXt.so.6 #10 0x0808d868 in ?? () #11 0xbfa0ffb4 in ?? () #12 0xbfa0ffc8 in ?? () #13 0xb7e51dd3 in _XtRemoveAllInputs () from /usr/X11R6/lib/libXt.so.6 #14 0xb7e51dd3 in _XtRemoveAllInputs () from /usr/X11R6/lib/libXt.so.6 #15 0xb7e52301 in XtAppNextEvent () from /usr/X11R6/lib/libXt.so.6 #16 0xb7e4698c in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6 #17 0x080601c5 in ?? () #18 0x0808d868 in ?? () #19 0x02a00060 in ?? () #20 0x00000001 in ?? () #21 0x00000001 in ?? () #22 0x00000004 in ?? () #23 0x00000000 in ?? () #24 0x00000001 in ?? () #25 0x00000000 in ?? () #26 0xbfa103c4 in ?? () #27 0xb7f07e9b in _dl_map_object_deps () from /lib/ld-linux.so.2 #28 0xb7bf3974 in __libc_start_main () from /lib/tls/libc.so.6 #29 0x0804bcb1 in ?? () The write is for 512 bytes to fd 9, and the buffer contents are rather unremarkable: (gdb) x/s 0x080d6158 0x80d6158: "0.49999 0.5039\n0.5078 0.51171 0.51562 0.51952 0.52343 0.52734 0.53124 0.53515 0.53905 0.54296\n0.54687 0.55077 0.55468 0.55859 0.56249 0.5664 0.5703 0.57421 0.57812 0.58202\n0.58593 0.58984 0.59374 0.59"... My libc6 package is 2.3.2.ds1-22sarge6. My libxt6 package is 4.3.0.dfsg.1-14sarge4. Kernels are custom 2.6.13.4 and 2.6.12.6 (I can reproduce this on several systems). The process at the reading end of the pipe is /usr/bin/gs, so I should mention that on my sarge systems this is /usr/bin/gs-gpl, from version 8.01-5 of the gs-gpl package. I now see (from strace output) that gs dies with SIGSEGV just before its parent gv receives the SIGPIPE. Running gs under gdb, then, with the same arguments gv is using (-sDEVICE=x11 -dTextAlphaBits=4 -dGraphicsAlphaBits=2 -dMaxBitmap=10000000 -dNOPLATFONTS -dNOPAUSE -dQUIET -dSAFER) results in: Program received signal SIGSEGV, Segmentation fault. 0x080d7aa3 in jpeg_mem_term () (gdb) bt #0 0x080d7aa3 in jpeg_mem_term () #1 0x080d7ac4 in jpeg_mem_term () #2 0x080d7ac4 in jpeg_mem_term () [and so on ad infinitum]. That backtrace doesn't make much sense to me, and if I disassemble the code near $eip I don't see what can have caused the segmentation fault. If I remove the -dMaxBitmap=10000000 option, I finally get a PostScript error: Error: /unknownerror in --%op_show_continue-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1050/1123(ro)(G)-- --dict:0/20(G)-- --dict:71/200(L)-- --dict:137/300(L)-- --dict:20/20(L)-- --dict:137/300(L)-- Current allocation mode is local Current file position is 71894 GPL Ghostscript 8.01: Unrecoverable error, exit code 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
