--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: gs: Integer overflow breaks huge procedures
- From: Lauri Alanko <la@iki.fi>
- Date: Sun, 18 May 2003 20:25:13 +0300
- Message-id: <E19HRuL-00037Y-00@la.iki.fi>
Package: gs
Version: 7.06-1.1
Severity: normal
Tags: upstream
There's a problem with how gs handles procedure definitions. This works
fine:
(echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \
yes 1 | head -60000 ; echo "} quit") | gs -q -dNODISPLAY -
However, this causes a very obscure rangecheck error:
(echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \
yes 1 | head -70000 ; echo "} quit") | gs -q -dNODISPLAY -
And in fact any procedure definition of similar size will fail in the
same way.
I delved into the problem, and it seems that it's a simple overflow
problem: in iscan.c:658 gs tries to build a large array of size > 65536,
but, as seen in iref.h:370, object sizes are stored in a 16 bit integer.
The allocation succeeds, but its size is wrong. Hence, trouble.
The Right Thing would be to support longer arrays, but failing that, at
least the size should be checked before allocation and a more sensible
diagnostic produced. I don't understand gs's internal workings well
enough to produce a patch, though.
And no, the problem does not occur only in pathological cases. Combine
autotrace, which generates very complex PS figures from bitmaps, with
html2ps, which embeds all figures into procedures, and the mess is
ready. That's how I encountered it.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux la.iki.fi 2.4.18 #1 Mon Jul 22 17:03:02 EEST 2002 i586
Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1
Versions of packages gs depends on:
ii gs-common 0.3.3 Common files for different Ghostsc
ii libc6 2.3.1-11 GNU C Library: Shared libraries an
ii libgimpprint1 4.2.5-2 Gimp-Print printer drivers - core
ii libpaper1 1.1.12 Library for handling paper charact
ii libpng12-0 1.2.5-10 PNG library - runtime
ii xlibs 4.2.1-5 X Window System client libraries
ii zlib1g 1:1.1.4-9 compression library - runtime
-- no debconf information
--- End Message ---
--- Begin Message ---
- To: 364936-done@bugs.debian.org, 459930-done@bugs.debian.org, 169678-done@bugs.debian.org, 587272-done@bugs.debian.org, 193775-done@bugs.debian.org, 115122-done@bugs.debian.org, 175267-done@bugs.debian.org, 177763-done@bugs.debian.org, 193609-done@bugs.debian.org, 194147-done@bugs.debian.org, 208941-done@bugs.debian.org, 213695-done@bugs.debian.org, 280473-done@bugs.debian.org, 103301-done@bugs.debian.org, 128890-done@bugs.debian.org, 144256-done@bugs.debian.org, 116266-done@bugs.debian.org, 16285-done@bugs.debian.org, 56968-done@bugs.debian.org, 71897-done@bugs.debian.org
- Subject: Closing orphan/obsolete bugs (gs and gs-aladdin)
- From: "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com>
- Date: Thu, 5 Jul 2012 15:26:04 +0100
- Message-id: <CAPQ4b8kkvW2C65NtVY71GFdiwf5O1D7AsHZUFK7mRdR5KstUFA@mail.gmail.com>
Hello,
Thanks for your interest in Debian, and sorry that the bugs were not
attended in due time.
gs and gs-aladdin were removed from Debian unstable long ago [1], 8+
years, at least with that package name.
Many of these reports don't have new information for years, or never
were really followed up by the people involved at the time; some even
without any activity for 10 to 15 years. Two or three of the reports
were indeed confirmed and cloned as bugs to the more recent
"ghostscript" package.
[1] http://packages.qa.debian.org/g/gs.html
[2] http://packages.qa.debian.org/g/gs-aladdin.html
The bugs are now orphan (no maintainer assigned), so they are not
going to be noticed by anybody and dealt with, and indeed many of them
were already marked as unreproducible or contain references to files
never provided, and needed to reproduce the bug.
For all of the reasons stated, I am thus closing the bug reports now.
If somebody wants to keep them open, please reconfirm that they are
still happening and assign them to a current package, so they are not
orphan and can really be tracked.
Regards.
--- End Message ---