[Cython] [cython-users] Re: How to find out where an AttributeError is ignored

mark florisson markflorisson88 at gmail.com
Fri Jan 27 17:30:55 CET 2012


On 27 January 2012 16:22, mark florisson <markflorisson88 at gmail.com> wrote:
> On 27 January 2012 15:47, Simon King <simon.king at uni-jena.de> wrote:
>> Hi all,
>>
>> I am still *very* frustrated about the fact that Cython does not tell
>> where the error occurs. Since about one week, I am adding lots and
>> lots of lines into Sage that write a log into some file, so that I get
>> at least some idea where the error occurs. But still: Even these
>> extensive logs do not provide a hint on what exactly is happening.
>>
>> How can I patch Cython such that some more information on the location
>> of the error is printed? I unpacked Sage's Cython spkg, and did "grep -
>> R ignored .", but the code lines containing the word "ignored" did not
>> seem to be the lines that are responsible for printing the warning
>> message
>>   Exception AttributeError: 'PolynomialRing_field_with_category'
>> object has no attribute '_modulus' in  ignored
>>
>> Can you point me to the file in Sage's Cython spkg which is
>> responsible for printing the warning?
>>
>> Best regards,
>> Simon
>
> These messages are written by PyErr_WriteUnraisable, which is a
> CPython C API function that writes unraisable exceptions. There are
> typically two reasons for unraisable exceptions:
>
>    1) as Robert mentioned, a function that does not allow propagation
> of exceptions, e.g.
>
>        cdef int func():
>            raise Exception
>
>        Here there is no way to propagate the raised exception, so
> instead one should write something like
>
>            cdef int func() except -1: ...
>
>        Alternatively one may use 'except *' in case there is no error
> indicator and Cython should always check, or "except ? -1" which means
> "-1 may or may not indicate an error".
>
>    2) in deallocators or finalizers (e.g. __dealloc__ or __del__)
>
> For functions the right thing is to add an except clause, for
> finalizers and destructors one could use the traceback module, e.g.
>
>    try:
>        ...
>    except:
>        traceback.print_exc()
>
> If this all still doesn't help, try setting a (deferred) breakpoint on
> __Pyx_WriteUnraisable or PyErr_WriteUnraisable.

Actually, I don't see why the default is to write unraisable
exceptions. Instead Cython could detect that exceptions may propagate
and have callers do the check (i.e. make it implicitly "except *").
Was this not implemented because Cython only knows whether functions
may propagate exceptions at code generation time by looking at the
presence of an error label?
Maybe it could keep code insertion points around for every call to
such a potential function and if the function uses the error label
have the caller perform the check? Although I do forsee problems for
external such functions... maybe Cython could have it's own
threadstate regardless of the GIL which would indicate whether an
error has occurred? e.g. CyErr_Occurred()?


More information about the cython-devel mailing list