-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OverflowError: signed integer is greater than maximum on mips64 #51545
Comments
While trying to get Python 2.6 working on OpenBSD/sgi (64-bit port) OverflowError: signed integer is greater than maximum I ran the command that triggered this by hand with -v added: (sgi Python-2.6.3 40)$ export PATH; PATH="`pwd`:$PATH"; export
PYTHONPATH; PYTHONPATH="`pwd`/Lib"; export DYLD_FRAMEWORK_PATH;
DYLD_FRAMEWORK_PATH="`pwd`"; export EXE; EXE=""; cd
./Lib/plat-openbsd4; ./regen
python$EXE -v ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py
import site # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc
'import site' failed; traceback:
Traceback (most recent call last):
File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py", line 61,
in <module>
import sys
OverflowError: signed integer is greater than maximum
import encodings # directory
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.py
import encodings # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
Python 2.6.3 (r263:75183, Nov 6 2009, 09:50:33)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py
import re # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc
Traceback (most recent call last):
File "../../Tools/scripts/h2py.py", line 24, in <module>
import sys, re, getopt, os
File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py", line 104,
in <module>
import sys
OverflowError: signed integer is greater than maximum
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 3 unfreed ints
# cleanup floats
(sgi plat-openbsd4 41)$ There have been several patches applied: Please find attached the build log and the configure log. |
And the build log on OpenBSD/sgi. |
Thanks for filing the report! Some questions: If you configure with the --with-pydebug option, and also do whatever What's the minimal Python code required to cause the failure. Is it Judging by the error message, it looks as though the OverflowError is 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 |
After properly compiling with -O0, it actually gets a lot further in the PYTHONPATH=/usr/obj/ports/Python-2.6.3/fake-sgi/usr/local/lib/python2.6 Attached is the full build log with the backtrace of that core file. |
Hmm. I don't understand that backtrace at all. It seems to say that Is it possible that the configure script is somehow ending up with the |
this little test program:
#include <unistd.h>
int main(int argc, char*argv[])
{
printf("short = %d\n", sizeof(short));
printf("int = %d\n", sizeof(int));
printf("float = %d\n", sizeof(float));
printf("long = %d\n", sizeof(long));
printf("double = %d\n", sizeof(double));
printf("long long = %d\n", sizeof(long long));
printf("double long = %d\n", sizeof(double long));
return 0;
}
gives the following values on mips64:
short = 2
int = 4
float = 4
long = 8
double = 8
long long = 8
double long = 16 is there any other thing I should check? |
Sorry, I'm running out of ideas. The traceback is truly baffling. I'm not sure why you're configuring with --with-fpectl. Does removing Maybe you could also try copying _PyHash_Double into a small test program, |
Removing --with-fpectl makes no difference. I'll try the _PyHash_Double-thing later this weekend. |
This problem has been diagnosed as a problem in the mips64 port of OpenBSD. mips64 systems need to emulate some floating point instructions in software, depending on the cpu type. In this case we hit an instruction for which the emulation was incomplete. The floating point exception actually signals this. Work is being done to fix this. |
Many thanks for the update. I'll close this as not a Python bug, then. |
FYI, the issue has been fixed now in the mips64 port of OpenBSD by "replacing the previous/old floating point completion code with a C interface to the MI softfloat code, implementing all MIPS IV specified floating point |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: