| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz 53398 (and others)
Because xpswrite uses libtiff to write images to XPS files, and libtiff
won't offer us any way to use our memory manager, it is possible to
get a corrupted image which tries to use silly amounts of memory, which
leads to system memory being exhausted.
In this commit; change the gs_memory_status_s structure to include the
'limit' from the memory allocator. Alter the various allocators to fill
in the value (or set it to -1 if there is no limit). In the xpswrite
device calculate the amount of memory needed for an uncompressed image,
if it becomes negative we know we broke a 64-bit signed integer, so
abort. If it didn't go negative, and the memory manager has a specified
limit, check to see if the image will fit in that. If not return
VMerror.
This prevents at least some of the memory exhaustion errors with
xpswrite and OSS-fuzz, because OSS-fuzz sets -K to limit memory use.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(squash of commits from filesec branch)
Most of this commit is donkeywork conversions of calls from
FILE * -> gp_file *, fwrite -> gp_fwrite etc. Pretty much every
device is touched, along with the clist and parsing code.
The more interesting changes are within gp.h (where the actual
new API is defined), gpmisc.c (where the basic implementations
live), and the platform specific levels (gp_mswin.c, gp_unifs.c
etc where the platform specific implementations have been
tweaked/renamed).
File opening path validation
All file opening routines now call a central routine for
path validation.
This then consults new entries in gs_lib_ctx to see if validation
is enabled or not. If so, it validates the paths by seeing if
they match.
Simple C level functions for adding/removing/clearing paths, exposed
through the gsapi level.
Add 2 postscript operators for path control.
<name> <string> .addcontrolpath -
Add the given <string> (path) to the list of paths for
controlset <name>, where <name> can be:
/PermitFileReading
/PermitFileWriting
/PermitFileControl
(Anything else -> rangecheck)
- .activatepathcontrol -
Enable path control. At this point PS cannot make any
more changes, and all file access is checked.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we properly "include what we use" let's sanitise the horrid
blah_DEFINED ifdeffery (i.e. kill it where possible).
Also, we update the .c dependencies in the base/psi makefiles to
be correct.
Unfortunately, this new correct set of dependencies causes nmake
to soil itself and die with an out of memory error. After much
experimentation, I've come to the conclusion that this is because
it copes poorly with given the same file as a dependency multiple
times.
Sadly, our style of declaring dependencies in the following style:
foo_h=$(BLAH)/foo.h $(std_h)
bar_h=$(BLAH)/bar.h $(foo_h) $(std_h)
baz_h=$(BLAH)/baz.h $(foo_h) $(std_h)
means that a .obj file that depends on $(foo_h) $(bar_h) and $(baz_h)
ends up depending on foo.h twice, and std.h three times.
I have therefore changed the style of dependencies used to be more
standard.
We still define:
foo_h=$(BLAH)/foo.h
so each .obj file rule can depend on $(foo_h) etc as required, but the
dependencies between each .h file are expressed in normal rules at the
end of the file in a dedicated "# Dependencies" section that we can now
autogenerate.
|
|
|
|
|
|
|
|
| |
There was a logical flaw in the revised iregister_root() implementation that
meant we only handled 2 of the 3 ways of calling it correctly, the third way
would result in a segfault.
Also, add a comment noting those three ways of calling the API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run a release build on a linux machine to make arch.h etc. Then
run toolbin/headercompile.pl to test compiling each headerfile
by itself.
Resolve all the missing #includes, add missing repeated include
guards and copyright statements.
Also, update all the header dependencies in the makefiles.
It is possible that the object dependencies in the makefiles can be
simplified now, but that's a task for another day.
|
|
|
|
|
|
|
|
|
| |
This commit is a squashed version of the gpdl-shared-device
branch. Essentially this is a first version of the new
language switching mechanism.
This does not build as part as "all", but rather as "experimental"
or "gpdl".
|
|
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based off the original chunk heap managers code, this uses splay
trees for free blocks to speed searching. (Dual, top-down,
semi-splaying trees, one ordered on size, and another on location).
Adding this memory manager runs into a problem with pdfwrite.
Because pdfwrite is not entirely behaved with memory freeing, it
can free the same blocks more than once. This primarily happens
in pdf_close.
The existing chunk memory manager seems to get away with this by
luck, whereas this revised version sees SEGVs in some {pcl,xps} ->
pdfwrite tests.
Accordingly, we add a special fudge; if we call gs_defer_frees(1)
then the memory manager defers freeing blocks by putting them
onto a linked list (but only once). When we then call
gs_defer_frees(0), the manager finalizes all the blocks on the
list (which may in turn add new blocks to the list!). Once
all the blocks have been finalized, they are then freed.
"All" the pdfwrite double frees come from inside pdf_close (or
all the ones I have seen at least). Accordingly we bracket
pdf_close with gs_defer_frees(1) and gs_defer_frees(0).
|
|
|
|
|
|
|
|
|
|
| |
The subclassing code uses a horribly unsafe hack to reset
the type of a device object. This fails when the device
object is not of the expected type (in this case, when it's
not from the i_alloc manager).
Add a new access function to the API to allow this to happen
safely regardless of manager type.
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix for 'red 62'. This is a SEGV seen at allocation event
62 when memory squeezing:
gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
Also, improve the macro for FREE in base/gxclmem.c
|
|
|
|
|
|
|
|
|
| |
By adding this to the gs_memory_status_t and returning it (if available)
from the gs_memory_status function of allocators, we can print the max
used even when it is not a DEBUG build and avoid the ugly gs_debug
hack previously used to print the max_used for a DEBUG build. The
time for tracking this is microscopic. Also the chunk_mem allocator
now tracks this always, not just for DEBUG builds.
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|