slpmodule_new() doesn't initialize extra members added by type_new() about stackless HOT 9 CLOSED

Original comment by Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur):

Resolved as a side effect of removing flextype.

from stackless.

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):

This wasn't my problem, or something I've ever reproduced, but merely created under my name due to the porting over of issues.

If the size of the object is now consistent with the mainline Python object, then we should just close this.

from stackless.

Original comment by Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur):

This problem is likely to have gone away now. Richard, can you verify?

from stackless.

Original comment by Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur):

Prerequisite issue #47 has been closed.

from stackless.

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):

See previous comment.

from stackless.

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):

Will put on hold pending issue #47 being resolved.

from stackless.

Original comment by Anonymous:

This is clearly a fix, and a very small one.
Due to the complexity of creating this bug, I think it is of less priority.
But with confirmation that this change does not create other problems,
I leave this to your reasoning.

But what I really consider an improvement would remove the problem completely:
The whole problem comes from Flextype, which made a lot of sense in the
early days when Python was not at all optimized.

I think flextype should go away, and we should no longer have a module with
methods. That can be done with other approaches on the Python level.

So in the (hopefully not so) long term, please consider how much it would take to
get rid of flextype and the extra slpmodule type. If you can do that for the next
release, I would appreciate very much.

Less code, less complication, same functionality, more simplicity

from stackless.

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):

I think we need to do releases in a timely fashion, but that we also need to ensure all outstanding bug fixes are applied. Including this one.

However, note that the reporter clearly states that in order to reproduce this without his custom allocator, you need to manually corrupt the memory. I was going to say that CCP used Stackless for years and never encountered this problem, but I don't think that's a valid claim. What I can say is that I've used the Stackless interpreter personally for over a decade and this has never been an issue for me. Is this a real problem? Is there a better fix?

from stackless.

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):

I wonder if we should include this patch in 2.7.6-slp?

from stackless.