| msg145763 - (view) |
Author: Andreas Stührk (Trundle) * |
Date: 2011-10-17 22:14 |
| It's not possible (by intention) to instantiate a new instance of sys.flags. This is achieved by setting the "tp_new" slot to NULL (in `_PySys_Init()`), after `PyType_Ready()` is called, which means that a slot wrapper is added to the type dict for the "tp_new" slot (because the slot != NULL at that time). The problem is now that if one calls `sys.flags.__new__` directly, a null pointer dereference occurs in `tp_new_wrapper()`. Attached is a patch that fixes the crash and adds a test. |
|
|
| msg147089 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2011-11-05 15:59 |
| I’m not sure it is useful to fix this bug. |
|
|
| msg147092 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2011-11-05 16:02 |
| Why not? |
|
|
| msg147100 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-11-05 16:48 |
| Because the class of sys.flags is an implementation detail. Most people won’t try to instantiate it, IMO. |
|
|
| msg147103 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2011-11-05 17:10 |
| That's probably true, but IMHO it's not a valid reason to keep the buggy behavior. |
|
|
| msg147106 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2011-11-05 20:14 |
| Why would we want to prevent users from creating new instances of FlagsType? |
|
|
| msg147490 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-11-12 14:38 |
| You are right. Even if it’s an undocumented internal type, there is no reason not to fix it. There are plenty of similar crash fixes committed in the repo. |
|
|
| msg147563 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-13 17:39 |
| Thanks for the patch. You should add the same tests for sys.version_info and sys.getwindowsversion. |
|
|
| msg217338 - (view) |
Author: Jessica McKellar (jesstess) *  |
Date: 2014-04-28 03:36 |
| Thanks for reporting this and providing a patch, Trundle. The Python 3 patch didn't apply cleanly anymore, so I regenerated it and added tests for sys.version_info and sys.getwindowsversion. * The patch passes `make patchcheck` * The full test suite passes with this patch. * Testing manually, without this patch each of the following segfaults, and with the patch they raise errors instead: import sys; sys.flags.__new__(type(sys.flags)) import sys; sys.version_info.__new__(type(sys.version_info)) import sys; sys.getwindowsversion().__new__(type(sys.getwindowsversion())) One important caveat is that while I confirmed the sys.getwindowsversion segfault on Windows, I don't have Visual Studio set up so I couldn't build and test the new test for sys.getwindowsversion (I ran the full test suite on OSX, where this test is skipped). |
|
|
| msg217359 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-04-28 11:02 |
| Thanks for the patch, Jessica. It seems to work under Windows here. |
|
|
| msg217360 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2014-04-28 11:08 |
| New changeset 7052fdd90a11 by Antoine Pitrou in branch '3.4': Issue #13204: Calling sys.flags.__new__ would crash the interpreter, now it raises a TypeError. http://hg.python.org/cpython/rev/7052fdd90a11 New changeset a14012352f65 by Antoine Pitrou in branch 'default': Issue #13204: Calling sys.flags.__new__ would crash the interpreter, now it raises a TypeError. http://hg.python.org/cpython/rev/a14012352f65 |
|
|
| msg217362 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-04-28 11:09 |
| I've committed the patch to 3.4 and 3.5. I'm closing the issue, I don't think fixing 2.7 is important at this point. |
|
|