[Debian-science-sagemath] Bug#844789: iS: issue related to compressed manual.six

Thu Nov 24 16:43:16 UTC 2016

-----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.

> 
> However, it woud be much safer to fix the issue from the python side
> following the suggestion in the blogpost above, because there might be
> other place in GAP where gzip can receive a SIGPIPE.

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. 
An easy way to overcome this exposure is to use zlib, which for the least, can replace
the piping approach; even if zlib contains also much more potential.
On the other hand, Sage is a software umbrella of a myriad of software suites written
in a multitude of languages and by a large variety of people: the non-exposure approach
is certainly the more rational one.

Thanks,
Jerome

> 
> Cheers,
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calculus@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-----BEGIN PGP SIGNATURE-----

iQQcBAEBCgAGBQJYNxijAAoJED+SGaZ/NsaLsDEf/1/x9/AY4MlQHVCDqcib4i+J
XnwMVplIeWWTEHmUx51xh2KvSsd3K7zWlj4LKOHDN1tVahX1KtETHCNcom76TxCn
i12G+V1odd1cg/yQ8GahmatoWZubaGEkx8L/NCg5tv4DRaAHZhZOCsj5+TClOqNX
EOnYvHAX98ZSkU2uweCL/JRxzxVPHuFvQuB/ZfU0lG++DuwvqdPqtRo4zRZsq5op
OF6y1LSVRdZL7dL7zi9ZuySdT5qT5in1Uic/w3NaUpNYwkrht2tJE7vssTT682BL
NBjcfZpbIEmAMgbM6nDXQVlYeTZfZs6OL/ixQiuIYzfq2XnA3wdW4hAPujXSWtQf
7SNoqJAM/78KtMO0+ARq4/3Rr+xt5Iys/epISer7C5aA6eTkygVXaacxylWA0cck
y4nUmL7GLY07PvPoqVLHOZy0txm2+ad8Enru59nK/rcsRsayv734zilWBUb2XJKm
TEjsrdvuFB9f5DP6CIHwC8Im6mXDZ53/4F53Fq0glTRZkMJ8jbVCGeI4Y7voK0M5
neJpZSddFc4+o0SQPPmQ9VbBfw71twbHNi0XxvK+NTuiCVde5l3dLBWC2JDZYzDb
d/4xlbnI45/qVxxQSeIWuT9lvJNadA72GiUa8chTBWA995m8i/jtIj9RF5yuGDuD
Db3f8N8CzOTqKLmVGvFak5v5wB24E8GNwtXDrtZ8i4yFHvkVBNUwAk3DskVhK+I2
vBFtEr6xn/utT293k/2GtN36FnC/sLgGVNfPIqrWTpDZeF5KAYboU3E7bEVGi3Yq
rCveIw1NZ9bYa4ZSVwp2UhMOaWuyB9w1vyo5ZrMrC8gQSSDIrsUIKWIVEbEsjM2T
Six31gOA4BGyslsT3s/6bC6g1VnZVd0jMCLQEEhEo830qHMvNwPSdpdOMf6PVsed
MS/3AmFsAWaVBnkbYsywXhXEJaH8Eh0R/c7LxaJXdU9Xvc0PTEdRmrKsj33sbK9U
J9cQH6ZQVP6bHyIBfsk4kZctBgOLPjHQgtWiM2HKqSWEKT/OwJ39F9Jsc15KhBXp
f6iXupj7Je6v9tSxoZCa80TecvWEepK6/TxU0btSPj3iGBwPzqHHp9UD9cIinRQx
Pz6WHfneJSphff4rffmo+XNIwr0bZFfNoADXcGvIqFJGmFqSlWHL9YZAynIWpriw
bOEz5KdnzgX92ctoxEQqfici+4ImReBaNImbHDJQnxA2lL/SFk7rIhljgfiDep+k
Idjr2+u4d0M++5CsNUTA7rra/k+ciAbMbfiuQdSwL1mLRwJErHD13b11JmLTLlRY
6ySLcd0jXXRTxJWpnlwyQy5vbddf4Wlc/QZyamG58VyMzVx+JmGW8AxjBLB+CNw=
=Kgjw
-----END PGP SIGNATURE-----