Il giorno 22/ott/2012, alle ore 12:20, C Anthony Risinger <[email protected]> ha scritto:
> 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, > > I am trying to address that, can you report the uWSGI config you are using ? Thanks -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
