Reportbug crash in gcc-3.4
Hi,
I kind of found the problem. It seems to me that GCC is generating
incorrect code for function string_contains in file
Objects/stringobject.c. This function is used by the "in" operator (in
reportbug it's particularly triggered by the "'qa.debian.org' in
maintainer" check).
I don't know whom to contact and it might have been fixed in the
GCC-4.0-0pre5.0.0.1.gcc4 package that was recently uploaded to the
gcc-3.4 archive, but I don't have enough HD space to install all
Python's dependencies and try it myself. Anyway, I'll drop my findings
here, I hope they're useful to somebody (I hope you don't mind a bit of
asm):
This is the function (taken from source package python2.3-2.3.5-1, error
checking removed for clarity):
// [JK] The following three lines are ok
size = PyString_GET_SIZE(el); // [JK] 13
rhs = PyString_AS_STRING(el); // [JK] 'qa.debian.org'
lhs = PyString_AS_STRING(a); // [JK] 'Chris Lawrence <lawrencc@debian.org>'
// [JK] Not relevant for this particular case.
/* optimize for a single character */
if (size == 1)
return memchr(lhs, *rhs, PyString_GET_SIZE(a)) != NULL;
// [JK] the following line works.
end = lhs + (PyString_GET_SIZE(a) - size);
0x000000000043e8cc <PyString_Size+1596>: mov 0x10(%rbp),%eax
// [JK] $eax = PyString_GET_SIZE(a)
// [JK] $edx = size
0x000000000043e8cf <PyString_Size+1599>: sub %edx,%eax
0x000000000043e8d1 <PyString_Size+1601>: cltq
// [JK] $r10 = lhs
0x000000000043e8d3 <PyString_Size+1603>: lea (%r10,%rax,1),%r11
<PyString_Size+1664>
// [JK] $r11 = end
while (lhs <= end) {
0x000000000043e8d7 <PyString_Size+1607>: cmp %r11,%r10
0x000000000043e8da <PyString_Size+1610>: jbe 0x43e910
<PyString_Size+1664>
// [JK] I split the memcmp == 0 check for clarity
char *p = lhs++;
0x000000000043e910 <PyString_Size+1664>: cld
0x000000000043e911 <PyString_Size+1665>: lea 0x25(%rbp),%r8
// [JK] $r8 = lhs + 1 ('hris Lawrence <lawrencc@debian.org>')
0x000000000043e915 <PyString_Size+1669>: movslq %edx,%r9
// [JK] $r9 = size (13)
0x000000000043e918 <PyString_Size+1672>: xor %r10d,%r10d
// [JK] $r10 = 0. The problem seems to be in this line, as this breaks
the memcmp below. $r10 should be assigned lhs here; the memcmp (and
following iterations of the loop, not shown) would work as expected.
0x000000000043e91b <PyString_Size+1675>: jmp 0x43e926
<PyString_Size+1686>
int res = memcmp(p, rhs, size);
// [JK] size == 0?
0x000000000043e926 <PyString_Size+1686>: cmp %r9,%r9
0x000000000043e929 <PyString_Size+1689>: mov %r10,%rsi
// [JK] $rsi = $r10, but $r10 = 0!
0x000000000043e92c <PyString_Size+1692>: mov %r12,%rdi
// [JK] $rdi = rhs ('qa.debian.org')
0x000000000043e92f <PyString_Size+1695>: mov %r9,%rcx
// [JK] loop counter = size (13)
0x000000000043e932 <PyString_Size+1698>: repz cmpsb
%es:(%rdi),%ds:(%rsi)
// [JK] BOOM! $rsi == 0, therefore this causes a segmentation fault.
if (res == 0)
return 1;
}
Javier Kohen wrote:
I would, but reportbug segfaults on me. I had this problem early in
December but it went away again around December 14 after a libc
update. I'm using the gcc-3.4 archive. Is anyone else seeing
segfaults with reportbug?
Yes. It seems to be a problem of python2.3 and gcc-4.0. I do not have
a fix for this yet.
I have this problem, too, what would it take to recompile python2.3
locally with the appropriate gcc so I can fix it?
Here's a backtrace in case we're not talking about the same bug:
#0 0x000000000043e7b2 in PyString_Size ()
#1 0x000000000047435e in PyEval_GetFuncName ()
#2 0x0000000000475f58 in PyEval_EvalCodeEx ()
#3 0x0000000000474056 in PyEval_GetFuncName ()
#4 0x0000000000475f58 in PyEval_EvalCodeEx ()
#5 0x0000000000476092 in PyEval_EvalCode ()
#6 0x000000000049aad6 in PyRun_FileExFlags ()
#7 0x000000000049ad9e in PyRun_SimpleFileExFlags ()
#8 0x000000000040feb1 in Py_Main ()
[..]
Greetings,
--
Javier Kohen <jkohen@users.sourceforge.net>
ICQ: blashyrkh #2361802
Jabber: jkohen@jabber.org
Reply to: