Blank "%%+" lines in DSCs causes segfaulting
I've found a bug apparently in some part of GhostView involving the parsing of DSC. The bug appears where there's a DSC 'continuation line' consisting just of "%%+", as apposed to "%%+ foo" or the like. This pair of Hello World documents illustrates: http://interglacial.com/~sburke/pub/PostScript/dsc_plusline_000.ps http://interglacial.com/~sburke/pub/PostScript/dsc_plusline_001.ps The 000 causes no problems. But 001 invariably causes segfaults (!) in kghostview under Linux and in gs under MacOSX. The only difference is that 001 has a blank "%%+" continuation line. They're short, so I'll also just include them here. Here's dsc_plusline_000.ps: -snip %!PS-Adobe-2.0 %%Title: That thing %%+I sencha %%Creator: Peter Potamus %%Page: 1 1 /pgsave save def /Times-Roman findfont 30 scalefont setfont 108 504 moveto (Hello, World!) show showpage pgsave restore %%EOF -snip And here's dsc_plusline_001.ps that causes the trouble: -snip %!PS-Adobe-2.0 %%Title: That thing %%+ %%+I sencha %%Creator: Peter Potamus %%Page: 1 1 /pgsave save def /Times-Roman findfont 30 scalefont setfont 108 504 moveto (Hello, World!) show showpage pgsave restore %%EOF -snip Here's what the relevent "gs -v" (from Fink) says: AFPL Ghostscript 8.51 (2005-04-18) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. And here's what the "kghostview -v" says: Qt: 3.3.4 KDE: 3.4.2-0.fc3.2 Red Hat KGhostView: 0.20 This is the output from the KDE crash handler's backtracer: Using host libthread_db library "/lib/tls/i686/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208137024 (LWP 14095)] [KCrash handler] #3 0x005d018c in memcpy () from /lib/tls/i686/libc.so.6 #4 0x00a1d982 in dsc_set_page_bbox () from /usr/lib/libkghostviewlib.so.0 #5 0x0820f68c in ?? () #6 0xfffb in ?? () #7 0x0098b54c in ?? () from /usr/lib/libstdc++.so.6 #8 0xbfffd7c0 in ?? () #9 0xfffb in ?? () #10 0x0820f68c in ?? () #11 0x00a2c7d4 in ?? () from /usr/lib/libkghostviewlib.so.0 #12 0xfffb in ?? () #13 0x0820f68c in ?? () #14 0xbfffd788 in ?? () #15 0x00a1e812 in dsc_init () from /usr/lib/libkghostviewlib.so.0 On that machine, "gs -v" says GNU Ghostscript 7.07 (2003-05-17) Clearly the workaround is to just not have blank "%%+" lines. But a proper bugfix would be nice. -- Sean M. Burke http://search.cpan.org/~sburke/ ___ bug-ghostscript mailing list bug-ghostscript@gnu.org http://lists.gnu.org/mailman/listinfo/bug-ghostscript
feature request: Pre-seeding the random number generator
This is a feature request: I'd really really appreciate if you could make the random number generator in ghostscript pre-seeded. (Perl has been doing this for about ten years-- in the surprisingly rare circumstances where programmers want /predictable/ pseudorandomness, they just need to explicitly feed srand an particular value. If you want a bit of inspiration from Perl's pre-seeding, the code for it is in here: http://www.devdaily.com/scw/c/perl-5.8.5/util.c.shtml and look for the function "Perl_seed(pTHX)".) I considered just replacing rand with something that reads from /dev/random, but besides portability problems, such file operations are apparently inaccessible in gs's (imminently default) SAFER mode. I used to pre-seed by just doing "realtime srand", but now I see that realtime has a very NONrandom value (see below). I know that PostScript docs typically warn that rand's generator is typically pretty dumb, but that doesn't mean it /has/ to be dumb in GhostScript. % perl -e 'system q[echo realtime dup srand rand exch stack |gs -q -] for(1..20)' 81 1361367 81 1361367 82 1378174 85 1428595 82 1378174 81 1361367 84 1411788 83 1394981 83 1394981 81 1361367 81 1361367 81 1361367 80 1344560 83 1394981 81 1361367 83 1394981 80 1344560 81 1361367 83 1394981 87 1462209 ___ bug-ghostscript mailing list bug-ghostscript@gnu.org http://lists.gnu.org/mailman/listinfo/bug-ghostscript
Re: feature request: Pre-seeding the random number generator
On 10/22/2006 03:14 AM, Didier LINK wrote: Le samedi 21 octobre 2006 à 14:56 -0800, Sean M. Burke a écrit : This is a feature request: I'd really really appreciate if you could make the random number generator in ghostscript pre-seeded. Why do you need this enhancement exactly ? I like to generate documents that contain, well, some degree of randomness, without having to duck out of PostScript to fetch a new srand seed. For example, I like to reload this: http://interglacial.com/~sburke/pub/PostScript/dynamically_generated_maze_simpler.ps.txt but I very often get the same two or three mazes over and over and over. This problem recurs with many other documents of mine that attempt randomness. If that sounds dull, tell me, and I can make up something totally compelling about how I'm actually the person generating the entire Albanian Lottery's cards using /just/ sh and GhostScript and a can of gold paint, and how the ghost of Hoxha is angry that I keep generating the same four or five cards over and over. How's that for a use-case and/or a rich comedic premise? (Perl has been doing this for about ten years-- in the surprisingly rare circumstances where programmers want /predictable/ pseudorandomness, they just need to explicitly feed srand an particular value. If you want a bit of inspiration from Perl's pre-seeding, the code for it is in here: http://www.devdaily.com/scw/c/perl-5.8.5/util.c.shtml and look for the function "Perl_seed(pTHX)".) I considered just replacing rand with something that reads from /dev/random, but besides portability problems, such file operations are apparently inaccessible in gs's (imminently default) SAFER mode. I think it's possible to introduce a better initial value in the code with a read from /dev/random but it's not portable on all architectures that's are supported by ghostscript. I need to investigate in this way. Excellent! At this point, anything would be better than the current behavior. (In the old days of my programming in other languages with poor pre-seeding: I used to do pretty well with taking the current process ID number (or, if under Windows, instead using GetTickCount, since Windows often reuses process IDs almost immediately), shift it four bits left, and xor that against the lower twelve bits of time or utime or something of the sort.) I used to pre-seed by just doing "realtime srand", but now I see that realtime has a very NONrandom value (see below). Yes I see, and it's plateform dependent, on my amd64 the random numbers generated by your perl script are a little bit better. But why do a srand at each iteration of the loop ? It's certainly better to initialize one time and use rrand function to iterate new random numbers inside gs. I'm wrong ? It was just minimal example code to illustrate the problem of realtime's value not being useful as an initial value for srand. I know that PostScript docs typically warn that rand's generator is typically pretty dumb, but that doesn't mean it /has/ to be dumb in GhostScript. Yes but they need to be compliant with the Adobe's specifications and reference implementation of postscript interpreter. I appreciate you noting that One Must Be Very Careful-- but I swear, if Adobe actually does mandate that the random number generator /not/ be pre-seeded, I will SHOWER you with gifts. ___ bug-ghostscript mailing list bug-ghostscript@gnu.org http://lists.gnu.org/mailman/listinfo/bug-ghostscript
