On Thu, Nov 24, 2016 at 04:43:16PM +0000, Jerome BENOIT wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello Bill, thanks for your reply.
>
> On 24/11/16 10:26, Bill Allombert wrote:
> > On Thu, Nov 24, 2016 at 10:34:28AM +0100, Bill Allombert wrote:
> >> On Thu, Nov 24, 2016 at 04:55:28AM +0000, Jerome BENOIT wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA512
> >>>
> >>> Hello Again,
> >>>
> >>> On 24/11/16 02:52, Jerome BENOIT wrote:
> >>>>
> >>>>
> >>>> On 23/11/16 09:59, Bill Allombert wrote:
> >>>>> Can you generate a full strace dump ?
> >>>>
> >>>> Yes. Unfortunately I have not yet succeeded to decipher them.
> >>>>
> >>>> There is a `Broken pipe' somewhere.
> >>>> The piping seems to be related to the uncompresion of a `manual.siz.gx'.
> >>>
> >>> There are a myriad of processes: the messages around the `Broken pipe'
> >>> are:
> >>>
> >>> execve("/bin/gunzip", ["gunzip"], [/* 90 vars */]) = 0
> >>> [...]
> >>> rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
> >>> rt_sigaction(SIGHUP, NULL, {SIG_IGN, [], 0}, 8) = 0
> >>> rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], 0}, 8) = 0
> >>> rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
> >>> rt_sigaction(SIGXCPU, NULL, {SIG_DFL, [], 0}, 8) = 0
> >>> rt_sigaction(SIGXFSZ, NULL, {SIG_IGN, [], 0}, 8) = 0
> >>> rt_sigaction(SIGINT, {0x4035c0, [INT TERM XCPU], SA_RESTORER,
> >>> 0x7eff302e1040}, NULL, 8) = 0
> >>> rt_sigaction(SIGTERM, {0x4035c0, [INT TERM XCPU], SA_RESTORER,
> >>> 0x7eff302e1040}, NULL, 8) = 0
> >>> rt_sigaction(SIGXCPU, {0x4035c0, [INT TERM XCPU], SA_RESTORER,
> >>> 0x7eff302e1040}, NULL, 8) = 0
> >>> ioctl(0, TCGETS, 0x7ffef9ddf1c0) = -1 ENOTTY (Inappropriate ioctl
> >>> for device)
> >>> fstat(0, {st_mode=S_IFREG|0644, st_size=171476, ...}) = 0
> >>> read(0,
> >>> "\37\213\10\0\0\0\0\0\2\3\244\\\331\222\324H\226}\317\257\220\345\274T\233\1\346\3732c\363\240"...,
> >>> 32768) = 32768
> >>> brk(NULL) = 0x669000
> >>> brk(0x68a000) = 0x68a000
> >>> write(1, "#SIXFORMAT GapDocGAP\nHELPBOOKIN"..., 32768) = 32768
> >>> write(1, ".4-1\", [ 20, 4, 1 ], 98, 246, \"l"..., 32768) = 32768
> >>> write(1, " \"35.3-5\", [ 35, 3, 5 ], 310, 46"..., 32768) = 16384
> >>> - --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=9643,
> >>> si_uid=1000} ---
> >>> write(1, "033[101X\", \"41.10-2\", \n [ 4"..., 16384) = -1 EPIPE
> >>> (Broken pipe)
> >>> - --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=9643,
> >>> si_uid=1000} ---
> >>> write(2, "\ngzip: ", 7) = 7
> >>> write(2, "stdout: Broken pipe\n", 20) = 20
> >>> rt_sigprocmask(SIG_BLOCK, [INT TERM XCPU], [], 8) = 0
> >>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> >>> lseek(0, 0, SEEK_CUR) = 32768
> >>> close(0) = 0
> >>> close(1) = 0
> >>> close(2) = 0
> >>> exit_group(1) = ?
> >>> +++ exited with 1 +++
> >>>
> >>> [[/bin/gunzip is in fact a shell script that wraps `gzip -d' ]]
> >>>
> >>> It looks like that it happens what is described in the following link:
> >>>
> >>> https://blog.nelhage.com/2010/02/a-very-subtle-bug/
> >>>
> >>> that is to say, python/sage manipulates SIGPIPE in such a way that any
> >>> gzip piping
> >>> becomes hazardous.
> >>
> >> Can you confirm that 'CloseStream(stream);' is the call that trigger the
> >> SIGPIPE ? In which case this can be worked around.
> >
> > Please find a patch that make sure the stream is empty before calling
> > CloseStream(stream).
>
> This patch does not fix the issue.
There should still be a difference in the strace. Did you observe it ?
> In other words, GAP exposes itself to this kind of bug because it compresses
> and
> decompresses thought pipes, what I would not consider as good behaviour.
This is the UNIX way to do this.
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
