[Debian-science-sagemath] Bug#844789: Bug#844789: iS: issue related to compressed manual.six
Jerome BENOIT
calculus at rezozer.net
Thu Nov 24 17:45:36 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello for your reply,
On 24/11/16 17:02, Bill Allombert wrote:
> 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 ?
I observe a minor difference: for one of the two Broken pipe event (EPIPE), the raise seems to be postponed:
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=29824, 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=29824, si_uid=1000} ---
write(2, "\ngzip: ", 7)
write(2, "stdout: Broken pipe\n", 20) = 20
instead of
write(1, "#SIXFORMAT GapDocGAP\nHELPBOOKIN"..., 32768) = 32768
write(1, ".4-1\", [ 20, 4, 1 ], 98, 246, \"l"..., 32768) = -1 EPIPE (Broken pipe)
- --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=29620, si_uid=1000} ---
write(2, "\ngzip: ", 7) = 7
write(2, "stdout: Broken pipe\n", 20) = 20
>
>> 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.
More exactly, this is one of the UNIX ways to do this.
Using zlib is an other way, and a safer way.
zlib is also a lazy way to do so because the zlib
library is designed to manage compressed files as uncompressed file
(of course here we are not dealing with high level zlib functons).
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-----
iQQcBAEBCgAGBQJYNydAAAoJED+SGaZ/NsaLyEEf/1Ld/z63fmQkyako0URW89LH
LJgp1mEB2ufs/SPydBDjc+6Jo4Hi1jlSVZiHYJdkRE6TjtxloTm0jTuq3HOgwlEn
4l1o4gimeBMSXyOPazEnwVi+qBExdjS0CnnMEIaddjabRpVhgHmk54tRgQBVhp87
jHjozS0rO+oPk4pr/W2dymFDw6gIY9SqL+effVwipI3sjdzGm3SPnIA28/gqSVY9
TGWbknDNXqlmjToNkEkgpybYbv1a926SNhclMm0AWFII1IXxXgaESbYYN6FVq7yC
nF/yxxPyqmmCOp3WjwMW/iniSeSmxRExCtl6peVcjTsYeqEdfwBhvxvukSsOlaHf
H7ClryavfDy/bDrIEwKw/R9e0coU1ovBvwX6x34N5MqwffXDRmsrqE7jQrvWVY2W
GZOOj8+dHSjjVXRXTGtFpySOJBseqG1DzXughtCI6V3llHYn0jbE4wXs7AppGflP
rCSbmQl1qO8WxaOz5iCR2gk9PcgIuweCes3i5YzYjEUx5Pk/lYnNCWux0WjxxF6T
g5+u99Hb9+t2BMAoG8IBSXn0u04U8c2NaGcZUpa9LcxW4xKwTuBw4fgaWFAOSi1W
JpSnooFdUT/MdHgM/fU+qwAvuK+5zsk7UU5ge8mJqAo/vqZ+qZpxqYYRgpbu/zZ0
DA/BKFYRWhV1ZyHzlgfPHdF163/EVHy/YAGwUL0PzcdNJwSz1rnjCM/cd2mZ7KwL
MrUSdbwONEnSnIR4HqBzFsbnb1JFV02Jo2qawq2TidRz98QeCoOUG2Ftu8OYg2tl
vk1FgvWwpCV+paiDNSoUVZzUWtQW1A4m7+BZyhPISECXQ2m8zKso2zmoA1hOfPaC
X5E1dHxVAn2/X2kNiVeoyQsbjMdDWjrIDJM000hIpSuPymTgELsOsAnp3EkgydRC
RsUEnxgHqxeGOfT1IoTlvztMXhijAIjVfYI2Wv22W/65mBBS5ZPGkjIUHWkKboYC
H+Jhu/aVT4rDX0JyBse41x/tn9kHYaCTS6PEnemR5/CF7mk8rygSPHA4liZ8HmBV
SUfiIBcQMdKp+b20dxBAz0wiNdbhp03kqykoNahesr+X1h0q92wqTAkmufMxD00o
vf4f7ORUaPIKOaNW76dJ6u2jzcGvZ0x6A8a0eXxkMMhWBp1C3Zwidqyxhww68rPT
/GJECFI9CDcyt6vsu4kMmcneH7h0LZfw1rJUqRyNWtDLDY/Qp4KWqxOekuj2aQ/i
P9Mfib5ix6jyaAkWGfyVbBlsxwwgr6XUR7OqS9L7/UTxHKXq2TZoIPQ0zCo0U8aC
rM+7GQMB7X5Y3TGbJEnj2pS6QvgoMwzcgt9cH3O3WchKI+6KEQRnz+rrPu9pUUw=
=xodG
-----END PGP SIGNATURE-----
More information about the Debian-science-sagemath
mailing list