[ZODB-Dev] Error running test.py in zodb3.1b

[Guido van Rossum]

> At 23:35 2002-09-25 -0400, Tim Peters wrote:
> >It was a wild load (a read from a nonsense address).
> [snip]
> 
> Many thanks for your explanation Tim. I'm not
> sure I'm happier now, but at least I feel a
> little more enlightened. :)
> 
> >You're definitely getting the wild load if you're running ZODB.  Whether it
> >harms you or not is much harder to say -- a wild load can pick up anything.
> >It only blows up at once if you're lucky <wink>.
> 
> So not getting any crashes doesn't mean I'm safe?
> There could be subtle corruption of data? :(

Who knows.  Apparently that code *usually* finds a NULL, in which it
happens to do the right thing; but *sometimes* it finds garbage data.
Apparently the garbage data *usually* causes an immediate segfault.
But we don't know anything about the form of the garbage, and it could
very well point to executable code.  There's just no telling.

> > > Do I understand correctly that this function would
> > > be called if I for instance did "type(6)(3)"?
> >
> >No, there's no ExtensionClass involved in that.
> 
> I realize that "type(6)(3)" won't cause problems. I
> just wondered if I understood correctly that type_call()
> is the C function that is called when a type object is
> invoked as a function. I imagine it can be used in
> code that doesn't look like that, for instance in
> C, but that's a bit beyond what I fully grasp...

BTW, type(6)(3) is the same as int(3).

> At 10:07 2002-09-26 -0400, Guido van Rossum wrote:
> > > Where can I learn more about this bug? (Not tonight
> > > though. I hope I'll get some sleep despite these
> > > news...)
> >
> >There's nothing more to learn.  Just use the patch.
> 
> My software is used by a client who isn't able to
> compile C programs, and just wants to use a standard
> windows install. (Except for some Pythoneering in
> Solaris I've mainly used standard installs myself.)
> 
> If I rebuild python here, what do I need to replace
> at his location? The python.exe and/or some DLL?

typeobject.c is part of python.exe, so I think that's all you'd have
to replace.  But I don't know for sure, having never tried this.

> What about 3rd party extensions such as wxPython
> or mxDateTime? Am I right in believing that all
> thingies compiled for python 2.2.x will be able to
> interoperate?

Yes, we try to ensure binary compatibility between micro releases so
you won't have to get new DLLs for 3rd party projects as long as the
major and minor release numbers (e.g. 2.2) stay the same.