Mark Dickinson <dicki...@gmail.com> added the comment:
Thanks for filing the report! Some questions:
If you configure with the --with-pydebug option, and also do whatever
else (if anything) is necessary to remove the -O2 flag from the
compilation steps, does the build failure still occur?
What's the minimal Python code required to cause the failure. Is it
enough to launch the interpreter and then just do 'import sys'?
Judging by the error message, it looks as though the OverflowError is
being set in the 'convertsimple' function in Python/getargs.c: the
relevant code looks something like:
case 'i': {/* signed int */
int *p = va_arg(*p_va, int *);
long ival;
if (float_argument_error(arg))
return converterr("integer<i>", arg, msgbuf, bufsize);
ival = PyInt_AsLong(arg);
if (ival == -1 && PyErr_Occurred())
return converterr("integer<i>", arg, msgbuf, bufsize);
else if (ival > INT_MAX) {
PyErr_SetString(PyExc_OverflowError,
"signed integer is greater than maximum");
return converterr("integer<i>", arg, msgbuf, bufsize);
}
But this code is part of Python's general argument parsing mechanism, so
is called from many many places; we really need some way of figuring out
where it's getting called from when the build fails. Still with a
--with-pydebug build, could you try using gdb (or an equivalent) to set
a breakpoint on the PyErr_SetString line in the (ival > INT_MAX) branch,
then do whatever is required to trigger the failure and report the
backtrace at that breakpoint?
----------
nosy: +mark.dickinson
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7296>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
