cpython/Lib/test/crashers
Ezio Melotti 24b07bcba3 #11515: fix several typos. Patch by Piotr Kasprzyk. 2011-03-15 18:55:01 +02:00
..
README Merged revisions 87050,87101,87146,87156,87172,87175,87371,87378,87522-87524,87526,87530-87535 via svnmerge from 2011-02-25 10:50:32 +00:00
bogus_code_obj.py Document the crashers that will not go away soon as "won't fix", 2006-07-25 18:38:39 +00:00
borrowed_ref_1.py A couple of examples about how to attack the fact that _PyType_Lookup() 2006-07-06 07:58:18 +00:00
borrowed_ref_2.py A couple of examples about how to attack the fact that _PyType_Lookup() 2006-07-06 07:58:18 +00:00
compiler_recursion.py Ivan on IRC in #twisted reported this crasher. 2009-02-06 11:46:26 +00:00
gc_has_finalizer.py An example that shows that _PyInstance_Lookup() does not fulfill 2010-09-03 09:26:14 +00:00
gc_inspection.py Document why is and is not a good way to fix the gc_inspection crasher. 2006-07-25 18:09:57 +00:00
infinite_loop_re.py Add a "crasher" taken from the sgml bug report referenced in the comment 2006-09-11 04:32:57 +00:00
loosing_mro_ref.py Sounds obvious, but I didn't even realize that you can put non-string 2008-06-12 09:50:58 +00:00
mutation_inside_cyclegc.py A new crasher. 2008-04-25 09:35:18 +00:00
nasty_eq_vs_dict.py add a very old crasher from the 2.1 -> 2.2 round of dictionary fixes. 2006-04-18 13:52:32 +00:00
recursion_limit_too_high.py #11515: fix several typos. Patch by Piotr Kasprzyk. 2011-03-15 18:55:01 +02:00
recursive_call.py Document the crashers that will not go away soon as "won't fix", 2006-07-25 18:38:39 +00:00

README

This directory only contains tests for outstanding bugs that cause the
interpreter to segfault.  Ideally this directory should always be empty, but
sometimes it may not be easy to fix the underlying cause and the bug is deemed
too obscure to invest the effort.

Each test should fail when run from the command line:

	./python Lib/test/crashers/weakref_in_del.py

Put as much info into a docstring or comments to help determine the cause of the
failure, as well as a bugs.python.org issue number if it exists.  Particularly
note if the cause is system or environment dependent and what the variables are.

Once the crash is fixed, the test case should be moved into an appropriate test
(even if it was originally from the test suite).  This ensures the regression
doesn't happen again.  And if it does, it should be easier to track down.