Bug 689600 - pstorastor always crashes with signal 11, so can not print at all
Summary: pstorastor always crashes with signal 11, so can not print at all
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver (show other bugs)
Version: 0.00
Hardware: PC Linux
: P4 blocker
Assignee: leonardo
Depends on:
Reported: 2007-12-08 11:14 UTC by colchaodemola
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Word Size: ---

example (23.72 KB, application/postscript)
2007-12-08 11:19 UTC, colchaodemola
strace (21.09 KB, application/x-bzip)
2007-12-08 11:22 UTC, colchaodemola
strace from version 8.61 (6.61 KB, application/x-bzip)
2007-12-08 17:46 UTC, colchaodemola
patch (642 bytes, patch)
2007-12-12 14:22 UTC, Alex Cherepanov
Details | Diff
improved patch (1.17 KB, patch)
2007-12-13 12:53 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description colchaodemola 2007-12-08 11:14:29 UTC
I am trying to print on my Epson R200 on my arm machine , and i always get
pstoraster crashed on signal 11. And i can never print anything.
Comment 1 colchaodemola 2007-12-08 11:17:38 UTC
# gs-esp --version

#cat testpage.ps | /usr/bin/gs-esp -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE
-dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=%stdout -c -
>/dev/null 2>/dev/null
Segmentation fault

I just attached the testpage
Comment 2 colchaodemola 2007-12-08 11:19:25 UTC
Created attachment 3616 [details]
Comment 3 colchaodemola 2007-12-08 11:22:37 UTC
Created attachment 3617 [details]
Comment 4 colchaodemola 2007-12-08 11:25:50 UTC
Forgot to mention , it does not crash on my i386 machine.
Just on my arm machine.
There is already a bug in debian BUG REPORTS since may/2007 with some people
with the same problem but no solution.


Comment 5 Michael Sweet 2007-12-08 13:53:59 UTC
Please re-test with the current GPL Ghostscript release.

Comment 6 colchaodemola 2007-12-08 17:42:50 UTC
Ok. Tested with latest version.
# gs --version

# cat testpage.ps | /usr/bin/gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE
-dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=%stdout -c -
>/dev/null 2>/dev/null
Segmentation fault

I attached the new strace from this version.
Comment 7 colchaodemola 2007-12-08 17:46:05 UTC
Created attachment 3618 [details]
strace from version 8.61

anything else ?
Comment 8 Alex Cherepanov 2007-12-09 06:49:34 UTC
As usual with exotic architectures, we need an access to a computer where the
problem can be reproduced; gs works fine on x86.

ebay has no ARM systems on sale now besides a few obsolete PDA's.
I doubt any ISP offers a shell account on an ARM box.
Comment 9 Ray Johnston 2007-12-09 12:08:22 UTC
I do have an ARM (actually an Intel XScale which has an ARM core) that I have
running embedded linux.

Are you running little-endian (mine is and that's really the only build that
I can support).

Note that I use Ghostscript on this gumstix XL6P board to print via cups on
that system and it works fine, although I'm still at 8.60.
Comment 10 Alex Cherepanov 2007-12-09 15:32:06 UTC
This problem is caused by access to unaligned data in the "clist" device,
in particular to "states" structures. It is not specific to cups.

ARM processors don't tolerate unaligned structures and throw a bus error or
silently round the pointer depending on the model.
Comment 11 colchaodemola 2007-12-09 15:35:35 UTC
any workaround ?
Comment 12 Ray Johnston 2007-12-11 10:24:13 UTC
Example of code that would fail is line 320 in src/gxclist.c in clist_init_states
Comment 13 Henry Stiles 2007-12-11 11:12:02 UTC
regarding #12 I think if bits_size (see clist_init_data()) was a multiple of the
alignment there would not be a problem.
Comment 14 Alex Cherepanov 2007-12-12 14:22:13 UTC
Created attachment 3622 [details]

Align the pointer to gx_clist_state array in gx_device_clist_writer device
to the natural boundary to avoid misaligned memory access and bus errors
on ARM processors.

Regression testing behaves strange recently. Probably, there's no regressions
it's hard to say for sure.
Comment 15 leonardo 2007-12-12 14:43:18 UTC
regarding the patch 3622 :

1. I do not understand why it drops the initialization ofcdev->cend.
2. It effectively shorten cdev->cbuf in 1-3 bytes, but few lines above the 
check for the buffer can fit cmd_largest_size is not updated, so the patch is 
not consistent.
Comment 16 Alex Cherepanov 2007-12-12 16:33:02 UTC
Initialization of cdev->cend is not dropped. It is moved above the alignment
adjustment because the pointer to the end of the buffer should not change.

The other 2 pointers move 0..7 bytes forward (on LP64 models) forward
at the expense of the 100-byte padding added 
between cdev->cbuf and cdev->cend .
Comment 17 leonardo 2007-12-13 11:27:14 UTC
Alex wrote :

[beg quote]
The other 2 pointers move 0..7 bytes forward (on LP64 models) forward
at the expense of the 100-byte padding added 
between cdev->cbuf and cdev->cend .
[end quote]

I'm not infavor of this rebus in code. The 100 is a buffer space rather than 
pad. Reading tha patched code one can't figure out where 100 comes from, and he 
obviousely sees that the real buffer size is inconsistent with the check. Could 
you please compute the buffer size precizelly to exclude possible 
misunderstanding ?
Comment 18 Alex Cherepanov 2007-12-13 12:53:42 UTC
Created attachment 3625 [details]
improved patch

Improve comments and check that at least 100-byte buffer is always
Comment 19 leonardo 2007-12-13 13:51:05 UTC
The patch 3625 looks good, please commit.
Comment 20 Alex Cherepanov 2007-12-14 10:37:00 UTC
The path is committed as a rev. 8440.