[Patches] [Patch #101346] print warning if exception occurs in GC

[noreply@sourceforge.net]

Patch #101346 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: print warning if exception occurs in GC

Follow-Ups:

Date: 2000-Aug-29 12:29
By: jhylton

Comment:
This appears to fix #110915 on Linux.  It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations.

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

Date: 2000-Aug-29 13:34
By: jhylton

Comment:
Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations.

Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception.  It seems dangerous to ignore one completely, but it's not clear how to recover.

If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c

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

Date: 2000-Aug-30 06:40
By: marangoz

Comment:
Hm. The offending PyErr_Clear should definitely be removed.
Not sure that surrounding the collection process with err fetch/restore
is a good idea though. The collector could trigger __del__ methods
which in turn could set exceptions. The GC code itself should be
absolutely transparent w.r.t. exceptions and should propagate them
if they're raised elsewhere.

So, what needs to be done here is:
- remove PyErrClear
- use PySys_WriteStderr for debugging. The whole "output" stuff in
   gcmodule.c should be zapped, because it's a suboptimal and incomplete
   PySys_WriteStderr. The latter takes care to fetch/restore exceptions
   when printing the output.

PS: now that this is assigned to me, can I upload another patch over this
one for review?
-------------------------------------------------------

Date: 2000-Aug-30 12:48
By: gvanrossum

Comment:
We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't.
-------------------------------------------------------

Date: 2000-Aug-31 14:44
By: jhylton

Comment:
This is a paranoid safety measure.  The GC should not raise any exceptions, and we don't think it does.  But just in case, print a message to stderr if an exception does occur.  Then raise a fatal error.

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

Date: 2000-Aug-31 15:01
By: bwarsaw

Comment:
Summary:
- I'd call the factored out C function PyError_WriteUnraisable()

- not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors?

- if you keep this variable, maybe call it gcerror.

Other than that +1
-------------------------------------------------------

Date: 2000-Aug-31 17:28
By: jhylton

Comment:
About the static unhandled: Yes.  I'm worried because an unexpected exception has already occurred.  If another occurs while creating the Python string object, it will hide the first exception.

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

Date: 2000-Aug-31 17:56
By: jhylton

Comment:
Address Barry's comments

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

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

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