This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients jasper, mark.dickinson
Date 2009-11-10.10:02:17
SpamBayes Score 1.34402e-07
Marked as misclassified No
Message-id <>
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) {
				"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?
Date User Action Args
2009-11-10 10:02:21mark.dickinsonsetrecipients: + mark.dickinson, jasper
2009-11-10 10:02:20mark.dickinsonsetmessageid: <>
2009-11-10 10:02:19mark.dickinsonlinkissue7296 messages
2009-11-10 10:02:18mark.dickinsoncreate