By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,714 Members | 750 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,714 IT Pros & Developers. It's quick & easy.

hp 11.11 64 bit python 2.5 build gets error "import site failed"

P: n/a
I am on a hp 11.11 machine doing a 64 bit python 2.5 build. When I get
my python executable created and run it, I get the error:

"import site failed"
OverflowError: signed integer is greater than the maximum.
This is happening in the convertsimple() routine when it tries to
return a signed int:

ival = PyInt_AsLong(arg)

the ival is larger than what is defined in INT_MAX.

Why is this happening in a standard HP 64 bit build?
Any help on fixing this problem is greatly appreciated.

Brad

May 2 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"import site failed"
OverflowError: signed integer is greater than the maximum.
This is happening in the convertsimple() routine when it tries to
return a signed int:

ival = PyInt_AsLong(arg)

the ival is larger than what is defined in INT_MAX.

Why is this happening in a standard HP 64 bit build?
Can you provide a complete gdb/dbx backtrace?

Some function tries to convert a Python int into a C int,
using the "i" conversion character. Python int uses C long
for internal representation, and that particular C long
happens to be larger than INT_MAX. This is quite reasonable
to happen in principle, but shouldn't happen on interpreter
startup.

So the questions are:
- what are the callers of convertsimple here? (in particular,
where does the call to PyArg_ParseTuple come from?)
- what is the value of ival?
- where does that number come from?

The first two questions are best answered with a C debugger.
Depending on the answer, the third question may nor may not
need an answer.

Good luck,
Martin

P.S. If you are asking in the more abstract sense "why is that
happening to me?", the answer is "because you are using an
uncommon platform on which Python sees little or no testing".
To work around, try a 32-bit build, or switch to Solaris,
OS X, Debian Linux, or (heaven forbid) MS Windows :-)
May 2 '07 #2

P: n/a
On May 2, 5:09 pm, "Martin v. Lwis" <mar...@v.loewis.dewrote:
"import site failed"
OverflowError: signed integer is greater than the maximum.
This is happening in the convertsimple() routine when it tries to
return a signed int:
ival = PyInt_AsLong(arg)
the ival is larger than what is defined in INT_MAX.
Why is this happening in a standard HP 64 bit build?

Can you provide a complete gdb/dbx backtrace?

Some function tries to convert a Python int into a C int,
using the "i" conversion character. Python int uses C long
for internal representation, and that particular C long
happens to be larger than INT_MAX. This is quite reasonable
to happen in principle, but shouldn't happen on interpreter
startup.

So the questions are:
- what are the callers of convertsimple here? (in particular,
where does the call to PyArg_ParseTuple come from?)
- what is the value of ival?
- where does that number come from?

The first two questions are best answered with a C debugger.
Depending on the answer, the third question may nor may not
need an answer.

Good luck,
Martin

P.S. If you are asking in the more abstract sense "why is that
happening to me?", the answer is "because you are using an
uncommon platform on which Python sees little or no testing".
To work around, try a 32-bit build, or switch to Solaris,
OS X, Debian Linux, or (heaven forbid) MS Windows :-)

- what are the callers of convertsimple here? (in particular,
where does the call to PyArg_ParseTuple come from?)
since the debugger locks up when I run, here is a printf call stack of
where things are happening:

import site # precompiled from ...
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
vgetargskeywords: positional arg: 4
convertitem
- what is the value of ival?
ival: 4294967295
- where does that number come from?
It is coming from the call to PyInt_AsLong. In that function there is
a call to:
PyInt_AS_LONG((PyIntObject*)op)
which returns the value of ival.

I wish we could just skip this port, but it is required for our
product that we have HP 64 bit. This did not happen with python 2.3.1
or 2.0.

Thanks for the help.

Brad

May 3 '07 #3

P: n/a
bh**********@gmail.com schrieb:
I am on a hp 11.11 machine doing a 64 bit python 2.5 build. When I get
my python executable created and run it, I get the error:

"import site failed"
OverflowError: signed integer is greater than the maximum.
Are you sure about the error message? That error is never produced
in Python. Instead, it may print an OverflowError with

signed integer is greater than maximum

(i.e. no period, no "the").

Regards,
Martin
May 3 '07 #4

P: n/a
>>"import site failed"
>>OverflowError: signed integer is greater than the maximum.
>- what is the value of ival?
ival: 4294967295
I see. This is 0xFFFFFFFF, which would be -1 if it were of type
int. So perhaps some value got cast incorrectly at some point,
breaking subsequent computations
>
>- where does that number come from?

It is coming from the call to PyInt_AsLong. In that function there is
a call to:
PyInt_AS_LONG((PyIntObject*)op)
which returns the value of ival.
That was not my question, really. I wanted to know where the object
whose AsLong value was taken came from. And before you say "it's
in the arg parameter" of convertsimple() - sure it is. However, how
did it get there? It's in an argument tuple - and where came
that from?

IOW, you really need to know who the caller of convertsimple is,
and what line of Python code precisely was triggering that call.

Regards,
Martin
May 3 '07 #5

P: n/a
On May 3, 2:54 pm, "Martin v. Lwis" <mar...@v.loewis.dewrote:
>"import site failed"
OverflowError: signed integer is greater than the maximum.
- what is the value of ival?
ival: 4294967295

I see. This is 0xFFFFFFFF, which would be -1 if it were of type
int. So perhaps some value got cast incorrectly at some point,
breaking subsequent computations
- where does that number come from?
It is coming from the call to PyInt_AsLong. In that function there is
a call to:
PyInt_AS_LONG((PyIntObject*)op)
which returns the value of ival.

That was not my question, really. I wanted to know where the object
whose AsLong value was taken came from. And before you say "it's
in the arg parameter" of convertsimple() - sure it is. However, how
did it get there? It's in an argument tuple - and where came
that from?
Looking at the call stack OP posted, -1 is coming as forth parameter
of
__import__, I *guess* at the first import in site.py or at implicit
"import site". I think it'd be helpful if OP also tried if it works:
python -S -c -v "print -1, type(-1), id(0), id(-1)"
-- Leo

May 4 '07 #6

P: n/a
On May 4, 1:17 am, Leo Kislov <Leo.Kis...@gmail.comwrote:
On May 3, 2:54 pm, "Martin v. Lwis" <mar...@v.loewis.dewrote:
>>"import site failed"
>>OverflowError: signed integer is greater than the maximum.
>- what is the value of ival?
ival: 4294967295
I see. This is 0xFFFFFFFF, which would be -1 if it were of type
int. So perhaps some value got cast incorrectly at some point,
breaking subsequent computations
>- where does that number come from?
It is coming from the call to PyInt_AsLong. In that function there is
a call to:
PyInt_AS_LONG((PyIntObject*)op)
which returns the value of ival.
That was not my question, really. I wanted to know where the object
whose AsLong value was taken came from. And before you say "it's
in the arg parameter" of convertsimple() - sure it is. However, how
did it get there? It's in an argument tuple - and where came
that from?

Looking at the call stack OP posted, -1 is coming as forth parameter
of
__import__, I *guess* at the first import in site.py or at implicit
"import site". I think it'd be helpful if OP also tried if it works:
python -S -c -v "print -1, type(-1), id(0), id(-1)"

-- Leo
Here is the output, along with my printf statements that show the call
stack:

builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
BRAD 20
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
convertitem
convertitem
convertitem
convertitem
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
vgetargskeywords: positional arg: 4
convertitem
ival: 4294967295
builtin___import__
PyArg_ParseTupleAndKeywords
vgetargskeywords: positional arg: 0
convertitem
vgetargskeywords: positional arg: 1
convertitem
vgetargskeywords: positional arg: 2
convertitem
vgetargskeywords: positional arg: 3
convertitem
vgetargskeywords: positional arg: 4
convertitem
ival: 4294967295
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'v' is not defined

May 4 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.