'fix' buffer overrun in eps9mid device leading to SEGV

Bug #701853 "Segmentation fault at base/gsbitops.c:121 in bits_fill_rectangle"

The actual fault here is considerably earlier in the actual sequence of
execution.

The device(s) check for consecutive unchanged raster lines, and only
emit new lines when two lines differ. In addition under some conditions
the device can 'consolidate' runs by OR'ing the data in a raster with
the same data in the next raster (I don't understand why this is needed)

In order to ensure that there is sufficient data (24 rasters) for the
process to complete safely the raster data is copied into a buffer which
is allocated large enough, and is set to zero if less lines than 24 are
read from the device.

However the code doing the OR'ing wasn't using this memory, it was using
the single scan line pulled from the device to check whether consecutive
lines are the same. This caused it to run off the end of that buffer and
overwrite the 'line_ptrs' member of the device structure. *Much* later
we would attempt to use the corrupted data and that would cause a SEGV.

fixed by making the code OR'ing the lines use the workign buffer, as
(I think) it should.

1 files changed, 1 insertions, 1 deletions

diff --git a/devices/gdevepsn.c b/devices/gdevepsn.c
index 5c1e9ac86..c69e4b533 100644
--- a/devices/gdevepsn.c
+++ b/devices/gdevepsn.c
@@ -272,7 +272,7 @@ eps_print_page(gx_device_printer *pdev, gp_file *prn_stream, int y_9pin_high,
                         /* can't print neighboring dots. */
                         int i;
                         for ( i = 0; i < line_size * in_y_mult; ++i )
-                                in_data[i] |= in_data[i + line_size];
+                                in[i] |= in[i + line_size];
                 }
 
                 if ( y_9pin_high )