Spurious issue in CPython 2.7.5

[thomas povtal.org]

Hi!

Thanks. Replies in-line
> Den 24. maj 2016 klokken 19:12 skrev Steven D'Aprano <steve at pearwood.info>:
> 
> On Tue, 24 May 2016 08:22 pm, thomas povtal.org wrote:
> 
> > Hi,
> > 
> > Please excuse me if this is not the right place, but I have some issues
> > with CPython on a NUMA machine.
> 
> Do you mean a Non-Uniform Memory Access machine? 
> 
> Can you be more specific about the actual machine and OS used?

It's Ubuntu 12.04 LTS. It appears as a NUMA machine with two nodes. However, I
later learned that it's (probably?) not a real NUMA but just Ubuntu's way of
representing two socktets for CPUs. I'm not very skilled in such low-level
matters, unfortunately.
> > 1: I get "RuntimeWarning: tp_compare didn't return -1 or -2 for
> > exception". It's a line like:
> > 
> > "if Foo = False:" where Foo is a global variable (global Foo).
> 
> What is the type and value of Foo?

global Foo = False
> > Now, I've searched somewhat on google for indications on when this
> > warning can be seen. However, I haven't really been able to understand
> > why and even if it's significant or not. (At face value I'm nervous the
> > Python runtime environment is corrupted for that process).
> 
> At face value, that RuntimeWarning seems to indicate a bug in the
> interpreter.

Ok. I was fearing this.
> > 2: In my process later on I get: "OverflowError: long too big to
> > convert".
> 
> Can you copy and paste the actual traceback rather than retyping it from
> memory? I think you're missing something, namely what the long is being
> converted to. The rest of the traceback will help too.

2016-05-24_08:15:40.84187 File "checkrc.pxd", line 14, in
zmq.core.checkrc._check_rc (zmq/core/socket.c:5932)
2016-05-24_08:15:40.84187 OverflowError: long too big to convert

I agree it looks like cut off, but it isn't...
> > This happens in different places and seems to always relate to 
> > obtaining a length of something (dict or list created by list
> > comprehension). Fx
> > 
> > "for i in xrange(0, len_of_stuff, max_section_size):"
> > 
> > en_of_stuff is always less than the max long (around 600).
> 
> What do you mean, "the max long"? Longs do not have a max value. The only
> limit is the amount of memory you have.
> 
> What about max_section_size? How big is that?

30
> > We're using gevent and I'm suspecting some "threading" could cause
> > this, as I'm able to replicate it locally with the same data.
> 
> Typo: you said later that you are *not* able to replicate it.
> 
> You're using a global variable with threaded code? You're a brave (or
> foolhardy) man...

Yeah, I didn't write the code originally, but that's not an excuse. The
greenlets involved doesn't appear to be mulithreaded in this case, though. Even
if it was, could that miss with the interpreter to give these sporious messages?
> -- 
> Steven
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list