bogus OverflowError: python bug?

[Luke]

Hi,

I'm getting an OverflowError which doesn't make sense to me. Is this a
python bug?

Traceback (most recent call last):
File "/home/demoau/lib/py/omniORB/__init__.py", line 717, in static_is_a
for b in cls.__bases__:
OverflowError: long int too large to convert to int

cls=<class omniORB.PortableServer.Servant at 0x4073656c>
cls.__bases__=()

Surely that line of source code shouldn't be able to produce an OverflowError?

(BTW, I know that a traceback can sometimes print the wrong source line when
the .py file has been modified since importing the module into the python
process, but I was careful to avoid this problem).

Regards,
Luke.

[Martin v. Löwis]

Luke wrote:

I'm getting an OverflowError which doesn't make sense to me. Is this a
python bug?
I very much doubt this. More likely, it's an omniORB bug.
Surely that line of source code shouldn't be able to produce an
OverflowError?
It actually might. If the internal memory of the interpreter got
corrupted by a buggy extension module, any code may cause any exception.
(BTW, I know that a traceback can sometimes print the wrong source line
when
the .py file has been modified since importing the module into the python
process, but I was careful to avoid this problem).

There are other possible causes for bogus exceptions. A common one is
that Python set an exception at some point, but the extension module
forgot to forward the exception. Then, the next time Python checks
for exceptions, it sees that there still is an exception pending, and
raises it. That exception will make no sense that that point, of course.

Only a gdb session can tell what really happened.

Regards,
Martin

[Luke]

Martin v. Löwis wrote:

Surely that line of source code shouldn't be able to produce an
OverflowError?

It actually might. If the internal memory of the interpreter got
corrupted by a buggy extension module, any code may cause any exception.

Good point, though I would expect a memory corruption bug to cause less
predictable behaviour (I can repeat this problem regularly in a large
multithreaded program, and the bogus exception is always at this specific
line of python).

(BTW, I know that a traceback can sometimes print the wrong source
line when
the .py file has been modified since importing the module into the python
process, but I was careful to avoid this problem).

There are other possible causes for bogus exceptions. A common one is
that Python set an exception at some point, but the extension module
forgot to forward the exception. Then, the next time Python checks
for exceptions, it sees that there still is an exception pending, and
raises it. That exception will make no sense that that point, of course.

Oh yes of course, thanks... this sounds to be more consistent with the
repeatability of the bogus exception.
Only a gdb session can tell what really happened.

Ouch. I might try searching the omniORB extension module for a
forgot-to-forward-exception bug first.

Thanks for your help, Martin.

Luke.