|Summary:||pstorastor always crashes with signal 11, so can not print at all|
|Component:||CUPS driver||Assignee:||leonardo <leonardo>|
strace from version 8.61
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 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
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. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422712
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 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.
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] 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.
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 available.
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.