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.
# gs-esp --version 8.15.3 #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
Created attachment 3616 [details] example
Created attachment 3617 [details] strace
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. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422712
Please re-test with the current GPL Ghostscript release.
Ok. Tested with latest version. # gs --version 8.61 # 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.
Created attachment 3618 [details] strace from version 8.61 anything else ?
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.
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.
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.
any workaround ?
Example of code that would fail is line 320 in src/gxclist.c in clist_init_states
regarding #12 I think if bits_size (see clist_init_data()) was a multiple of the alignment there would not be a problem.
Created attachment 3622 [details] patch 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 but it's hard to say for sure.
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.
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 .
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 ?
Created attachment 3625 [details] improved patch Improve comments and check that at least 100-byte buffer is always available.
The patch 3625 looks good, please commit.
The path is committed as a rev. 8440.