On Mon, Oct 22, 2012 at 10:53 AM, Roberto De Ioris <[email protected]> wrote:
>
> Il giorno 22/ott/2012, alle ore 12:20, C Anthony Risinger <[email protected]>
> ha scritto:
>>
>> [...]
>>
>> 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!
>
> I am trying to address that, can you report the uWSGI config you are using ?
only using args while i test/experiment:
# uwsgi --loop dumb --dumbloop-code=queue_worker.py
--dumbloop-function=main --enable-threads --venv "${VIRTUAL_ENV}"
--py-tracebacker=./trace
...`queue_worker.py:Worker` is simply a subclass of (AMQP):
http://kombu.readthedocs.org/en/latest/reference/kombu.mixins.html#kombu.mixins.ConsumerMixin
... basically a shell for implementing a worker, and main() is little more than:
def main(core_id):
Worker().run()
once uWSGI is running, i start up socat:
# watch -n0.5 socat UNIX-CLIENT:trace1,retry=5 STDOUT
... and if the queue is loaded, i can hit the SIGSEGV within 1-20
seconds or less.
i can't really post the queue_worker.py file (and it would be mostly
irrelevant anyway) but i'll try to quick make a simple repro case,
preferably one that doesn't use the dumbloop (though i don't think
it's related; the code is stable so long as noone is *listening* to
the tracebacker)
thanks,
--
C Anthony
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
