SystemError and truncated thread stats when starting yappi after some threads have started.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the attached multithread.py test (slightly modified from the 
distribution).
2.
3.

What is the expected output? What do you see instead?
Expect to see thread statistics for either a) just IOThread, or b) all three 
threads. Instead, I see:

SystemError: NULL object passed to Py_BuildValue

name           tid              fname                      ttot      scnt
WorkerThread   4368818176       ..ading.py.IOThread._note  0.014343  1

What version of the product are you using? On what operating system?
I have reproduced this with the latest source on OSX 10.8.4 and Windows 7 
64-bit, using python 2.7.4 and 2.7.5. On OSX I have tried building with the 
default values as well as with gcc (instead of clang).

Please provide any additional information below.
The only difference between the attached multithread.py and the multithread.py 
in the Mercurial repo is the position of yappi.start().

Original issue reported on code.google.com by sc...@cloudpic.com on 7 Aug 2013 at 4:17

Attachments:

• multithread.py

[GoogleCodeExporter]

Hi. This problem seems to occur when a thread exists, but has not actually done 
anything while yappi is running. I've dropped a kind of hacky fix for this 
issue into our checkout of the code -- patch file attached.

The hack: in _ctxenumstat, if ctx->last_pit doesn't exist, you currently fill 
in NULL values for last_func_name and last_mod_name. This makes 
PyObject_CallFunction unhappy, which makes _ctxenumstat return with an error, 
which tells the enumerator to bail. I just dropped in PyStr_FromString("None") 
in place of the NULL, which made everything work. We get output, albeit with 
odd "None.None" lines for the quiet threads.

That's not a very pretty fix, and someone more familiar with the code can 
probably suggest a better one. lmk if you'd like any more info from me.

Original comment by pet...@gmail.com on 20 Aug 2013 at 7:33

Attachments:

• thread_fix.patch

[GoogleCodeExporter]

Hi. This is a valid fix. Not a hacky one, the situation can happen from time to 
time and we need to handle the timeframe that you have mentioned. So thanks. 
Will include asap.

Original comment by sum...@gmail.com on 27 Aug 2013 at 8:24

[GoogleCodeExporter]

changed the fix a bit and pushed the changes. 

Original comment by sum...@gmail.com on 27 Aug 2013 at 10:41

[GoogleCodeExporter]

Original comment by sum...@gmail.com on 15 Sep 2013 at 8:51

• Changed state: Fixed