Bug 692344 - Increase in memory usage from 8.71 to 9.02
Summary: Increase in memory usage from 8.71 to 9.02
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC All
: P2 normal
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-14 19:45 UTC by Marcos H. Woehrmann
Modified: 2012-04-12 16:58 UTC (History)
0 users

See Also:
Customer: 711
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2011-07-14 19:45:38 UTC
The customer reports:

On 8.71 I regularly ran unit-tests on linux (with above gs config), and limited the memory available to GS with -K9000 cmdline parameter to simulate the approximate amount of memory on our printer. This amount was enough for everything we've run with so far.

The same amount on 9.02 doesn't seem enough, and causes segfaults on linux. See below gdb log when running attached gsmem.ps on 9.02 on linux. On 8.71 the same job ran fine with memory limited to as low as -K6100.

(gdb) r -dNOPAUSE -dBATCH -K9000  -sOutputFile=out-%02d.bmp -Z: gsmem.ps Starting program: /home/kemp_fr/pdl/ghostscript-9.02/debugobj/gs -dNOPAUSE -dBATCH -K9000 -sOutputFile=out-%02d.bmp -Z: gsmem.ps % Init started, instance 0x0x99f3158, with args: -dNOPAUSE -dBATCH -K9000 -sOutputFile=out-%02d.bmp -Z: gsmem.ps Artifex Ghostscript 9.02 (2011-03-30) Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
% Start time = 0.205568, memory allocated = 1740836, used = 1615031 Loading NimbusMonL-Regu font from %rom%Resource/Font/NimbusMonL-Regu... 2437772 1118955 1852836 564211 1 done.
%%[ ProductName: Artifex Ghostscript ]%% [a+]gs_malloc(large object chunk)(107548) = 0x0: exceeded limit, used=9113086, max=9210928

Program received signal SIGSEGV, Segmentation fault.
0x082ae880 in gx_image_enum_begin (dev=0x9eee074, pis=0x9a0ae1c, pmat=0x9a0ae88, pic=0xbfea1220, pdcolor=0x9d0a8ac,
   pcpath=0x9d05d14, mem=0x99f3464, penum=0xa0efec4) at ./base/gxipixel.c:337
337             set_nonclient_dev_color(penum->icolor0, gx_no_color_index);
Comment 2 Marcos H. Woehrmann 2011-08-11 03:11:39 UTC
Not mentioned in the original Description was how ghostsrcript was configured:

They were built with the default unix-gcc.mak, with only the following modifications:
       FEATURE_DEVS=$(PSD)psl3.dev $(PSD)pdf.dev
       BAND_LIST_STORAGE=memory
       DEVICE_DEVS=$(DD)bmpmono.dev (all other DEVICE_DEVS* empty)
       GS_SHARED_OBJS=
Comment 3 Marcos H. Woehrmann 2011-08-16 05:06:21 UTC
With -K9000 I don't have any problems with running the gsmem.ps file with any Ghostsript 9.02.  Reducing the memory option to -K7000 shows that the first version that fails is bfaf616f:

% Init started, instance 0x0x9d39150, with args: -Ilib:/home/marcos/artfiex/fonts -dNOPAUSE -dBATCH -K7000 -sOutputFile=test.bmp -Z: ../gsmem.ps 
GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
% Start time = 1.14369, memory allocated = 1530216, used = 1395370
Loading NimbusMonL-Regu font from %rom%Resource/Font/NimbusMonL-Regu... 2207056 903561 1852836 562541 1 done.
%%[ ProductName: GPL Ghostscript SVN PRE-RELEASE ]%%
% Outputpage start time = 1.75247, memory allocated = 4388444, used = 2959013
% Outputpage end time = 1.84769, memory allocated = 4388444, used = 2959013
%%[Page: 1]%%
%%[LastPage]%%
% Start time = 1.84812, memory allocated = 3323356, used = 2556794
% Init done, instance 0x0x9d39150, with args: -Ilib:/home/marcos/artfiex/fonts -dNOPAUSE -dBATCH -K7000 -sOutputFile=test.bmp -Z: ../gsmem.ps 
% Final time = 1.85329, memory allocated = 2847544, used = 2075244
% Exiting instance 0x0x9d39150

vs

% Init started, instance 0x0x9f83150, with args: -Ilib:/home/marcos/artfiex/fonts -dNOPAUSE -dBATCH -K7000 -sOutputFile=test.bmp -Z: ../gsmem.ps 
GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
% Start time = 1.75126, memory allocated = 1990248, used = 1657535
Loading NimbusMonL-Regu font from %rom%Resource/Font/NimbusMonL-Regu... 2646992 1162398 1852836 562541 1 done.
%%[ ProductName: GPL Ghostscript SVN PRE-RELEASE ]%%
% Outputpage start time = 2.20135, memory allocated = 6578772, used = 5462887
% Outputpage end time = 2.20138, memory allocated = 6578772, used = 5462887
GPL Ghostscript SVN PRE-RELEASE 8.72: Unrecoverable error, exit code 1
% Final time = 2.21221, memory allocated = 5889696, used = 3408105
% Exiting instance 0x0x9f83150
Comment 4 Marcos H. Woehrmann 2011-08-16 14:54:55 UTC
The seg fault reported by the customer started with revision 94557da7c, before that Ghostscript would report an "Unrecoverable error" and exit gracefully.
Comment 5 Ken Sharp 2011-08-24 10:21:53 UTC
(In reply to comment #4)
> The seg fault reported by the customer started with revision 94557da7c, before
> that Ghostscript would report an "Unrecoverable error" and exit gracefully.

I think this just reflects changing memory layouts. For me this seg faults trying to free a NULL clip path, the path being NULL because the allocation failed due to restricted memory. The code to free a clip path doesn't test to see if the pointer to a structure is NULL before de-referencing it.

I suspect that previously the allocation of the paths was successful, but the allocation of colour structures failed. This leads to a graceful termination as the colour structure code *does* test to see if the pointer is NULL before de-referencing.

I've modified gx_cpath_free to test the pointer before attempting to dereference it. Unfortunately this causes the memory to shift around slightly, and the allocation of the clip path once more succeeds, and the colour structure fails (its very sensitive). Forcing the pointer to NULL in the debugger and proceeding shows that this failure condition is now prevented however.

Committed as 8cbd67605010b927192acb590b9a1fd8bf45a2a3 I am closing the bug but Marcos I'd be really grateful if you could test this quickly anyway.