The cjkcodecs code does not initialize the ob_type 
pointer for the 3 type objects it defines.

The following code will illustrate a segmentation fault:

>>> import _codecs_cn
>>> c = _codecs_cn.getcodec('gb2312')
>>> type(c)
Segmentation fault (core dumped)

I have attached a patch which should solve the problem.

Logged In: YES 
user_id=33168

Thanks!

Checked in as:
 * Misc/NEWS 1.1374
 * Modules/cjkcodecs/multibytecodec.c 1.4

This needs to be backported.  Anthony is the branch still
frozen?  Feel free to backport this.

I tried to create a test, but it didn't crash.  If someone
can write a test that crashes when running under
regrtest.py, that would be great.

Logged In: YES 
user_id=29957

Yes, branch is still frozen. I'll check this in once 2.4.2c1
is out (before 2.4.2 final). I can't get a test case to fail
(rather than just segfault). 

Logged In: YES 
user_id=33168

I figured Anthony is busy enough. I checked this in since he
said he would.  My bad if you didn't want it in 2.4.2.

Checked in as:
 * Misc/NEWS 1.1193.2.107
 * Modules/cjkcodecs/multibytecodec.c 1.3.2.1

Logged In: YES 
user_id=33168

Eric, I have a question about your patch.  Is there any
reason you didn't change PyObject_HEAD_INIT(NULL) to
PyObject_HEAD_INIT(&PyType_Type) rather than do the
assignment in init?

Thanks.

Logged In: YES 
user_id=393416

Good question.  I'm following the convention that the majority 
of the Python modules follow.  There are 74 instances where 
it uses NULL and only 19 where it is immediately defined 
(with zipimport and xxsubtype doing some weird 
DEFERRED_ADDRESS macro).  In section 10.3 in the API 
docs it recommends doing this for dynamically loading 
modules (in windows).  I wasn't sure if anyone compiles the 
module as a shared module, so I figured it would be safer to 
do it this way.

Logged In: YES 
user_id=33168

Ok, thanks.  I remembered something about Windows here, but
wasn't sure.  I looked at some module that it did it the
other way.  I'm not going to change what's been checked in.