[Patches] [Patch #101170] Prevent old extensions from crashing

noreply@sourceforge.net noreply@sourceforge.net
Sun, 31 Dec 2000 16:25:55 -0800


Patch #101170 has been updated. 

Project: python
Category: Windows
Status: Rejected
Submitted by: chega
Assigned to : nobody
Summary: Prevent old extensions from crashing

Follow-Ups:

Date: 2000-Dec-31 16:25
By: tim_one

Comment:
Everyone agreed, so I Rejected it and unassigned it.
-------------------------------------------------------

Date: 2000-Dec-30 11:33
By: chega

Comment:
Agreed.
-------------------------------------------------------

Date: 2000-Dec-30 07:14
By: loewis

Comment:
I believe this patch is superceded with patch #101676, which is installed
as 2.7 of dynload_win.c; so I propose to reject this patch.
-------------------------------------------------------

Date: 2000-Aug-12 01:55
By: chega

Comment:
This patch will prevent old (1.5/1.6) extensions from crashing under Python
2.0

(Also changed pathbuf[260] to pathbuf[MAX_PATH])
-------------------------------------------------------

Date: 2000-Aug-15 15:26
By: tim_one

Comment:
Assigned to MarkH.  Please review or pass on to someone else.
-------------------------------------------------------

Date: 2000-Aug-15 16:26
By: mhammond

Comment:
I'm not sure this is worth adding.  Note that we already have code to
prevent a crash in place - however, rather than raising an exception it
simply calls Py_FatalError.

This patch is potentially better, except that:
* It will require regressing the patch made to modsupport.c (Rev 2.50) to
prevent the same problem; that code will prevent this code kicking in!

* It hard-codes the Python DLL names.  This makes long term maintenance a
PITA, and yet another file that needs to be updated when a version bumps.
Are there other alternatives?

* Once the module has been loaded, it may be too late to save the process
anyway.  I realize that the module init hasnt been called yet, but the
module has been loaded, and may be doing things in its DllMain() that will
destabilize the process.

The big killer is simply that this code will never be triggered, as the
check in modsupport.c will kick in first.

Setting to postponed until we can get a better handle on this.  A big
advantage is that this style of change is not dependent on _old_ versions
having the patch, only one actually running.  Hence we can revive this
patch at any time, and have it start working immediately.
-------------------------------------------------------

Date: 2000-Aug-15 16:49
By: tim_one

Comment:
I agree with Postponing it.  Thanks for the quick response!  Feel like
reviewing 7 controversial getopt patches now <wink>?
-------------------------------------------------------

Date: 2000-Aug-15 17:10
By: chega

Comment:
* The patch to modsupport.c will NOT save us in the case when someone loads
1.5 extension.  See Guido's checkin comment.
And I think that Python 1.6 will never be widely spread anyways, so in
99.9% cases it'll be 1.5 vs 2.0.

* I agree that the hard-coded dll-names are PITA, but only a small one :-).
 The version check #if will make sure that this list gets updated.  Also,
if we keep Guido's patch in modsupport.c the list won't need updating.

* I'd rather have an ImportError that PyFatalError()

* I find the argument about DllMain() screwing up the process somewhat
err... artificial ;-)))  I have never seen such a module.  Have you?

The only thing I am not sure about is whether there is any legitimate
reason to have python15 loaded.  AFAIR, python COM servers are alwaus
out-of-process, aren't they?  Can you think of something else?
If such reasons do exist, we may want to put another check before loading
the module and then bypass the post-check if python15 has been already
loaded.

-------------------------------------------------------

Date: 2000-Aug-21 05:38
By: mhammond

Comment:
Another alternative would be to create a Win32 event object, with name
"Python-%d" % pid, and have DllMain() attempt to acquire it.  This would
prevent the "old" Python subsystem starting at all, nipping it right in the
bud (and should return a clean ImportError back to the caller!)

Does this sound worthwhile?
-------------------------------------------------------

Date: 2000-Aug-21 05:43
By: mhammond

Comment:
Oops - I should have mentioned - Jack Jansen mailed me with the DllMain()
idea :-)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470