[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2018-05-08 Thread Xavier de Gaye
Xavier de Gaye added the comment: Closing as a duplicate of issue 33446 which has a wider scope and a PR. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker ___

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-31 Thread Ned Batchelder
Changes by Ned Batchelder : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-31 Thread Xavier de Gaye
Xavier de Gaye added the comment: This patch breaks extension modules (for example Ned Batchelder's coverage.py) that use PyEval_SetTrace to set the trace function. -- ___ Python tracker ___

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-10 Thread Jesús Cea Avión
Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-09 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- nosy: +georg.brandl versions: +Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python-bugs-list maili

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-09 Thread Xavier de Gaye
Xavier de Gaye added the comment: Tracing/profiling is disabled when tstate->tracing is true or tstate->use_tracing is false. The proposed patch fixes the problem by reducing the scope where this condition is true. As a consequence call_trace, profile_trampoline, trace_trampoline and call_trampo

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor

2012-12-09 Thread Xavier de Gaye
New submission from Xavier de Gaye: The following debugging session, run with python on the default branch, shows that pdb does not stop in __del__ when it is invoked. The reason is: - The destructor is not called when processing the 'c = 1' statement because foo frame.f_locals owns a ref