On Sun, Oct 21, 2012 at 6:05 PM, C Anthony Risinger <[email protected]> wrote: > > [...] > > the only other issue thus far appears to be within the tracebacker > itself... i am consistently (but more-or-less at random points in > code) hitting a SIGSEGV when it's enabled, within 30 seconds when > loaded. > > [...] > > ... will keep investigating.
i found the problem, and it's def with tracebacker. i don't understand why it's happening exactly, but tuple()s created during duct -> list (shown in python code, is really C of course): plugins/python/tracebacker.c:84-96 >>> sys._current_frames().items() ...are not getting DECREF'ed properly. these tuples contain a thread_id and a PyFrame_Type... later on, the GC tries looping thru this tuple **expecting a length of 2, per ob_size** but OOPS! the PyFrame_Type has already been deallocated. i tried a couple things to fix (decref'ing iterators, next items, and avoiding a list altogether...) but i kept triggering a double-free(!?) (current_frames[_items]...) the docs say PyObject_GetIter() and PyIter_Next() return new refs that must be released -- this is not happening consistently in tracebacker -- eg. `threads_list_iter` and `stacktrace_iter` are released but `frames_iter` is not. i'm clearly missing something from lack of experience; Roberto you will probably know exactly the issue... i believe it lies with the handling of `_current_frame`. hopefully my probing will be of some use! thanks, -- C Anthony _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
