[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Reportbug crash in gcc-3.4


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
// [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 ()


Javier Kohen <jkohen@users.sourceforge.net>
ICQ: blashyrkh #2361802
Jabber: jkohen@jabber.org

Reply to: