nathans wrote:
> [...]
> $ /tmp/bad.py
> PMAPI exception as requested
> bad.py: Generic error, already reported above ['@', '(disk.dev.read)']
>
> So, when you crack open the pmErr exception there, the position information
> returned from pmRegisterDerived is available as an exception parameter, as
> indicated by the [ @, <string> ] list message above.
>
> Real problem arises when we subsequently call pmDerivedErrStr() - this is
> using thread-local-storage for the error message (in libpcp).
(The bad.py never calls pmDerivedErrStr though.)
> However, from trawling the internets, it seems python may be
> switching the threads underneath us ...
An "strace -f" would indicate definitely whether that was happening.
And over here on fedora22, python2 or python3, there's no sign of any
thread-clones, only /sbin/ldconfig fork/exec's.
What's actually going on here, as confirmed by a debugger step-through
of pmRegisterDerived is that PM_TPD(derive_errmsg) simply never gets
set, because derive.c:parse() falls through to the default: case.
There are several other exits from that function that don't set
derive_errmsg.
> https://docs.python.org/2/c-api/init.html
> "In order to emulate concurrency of execution, the interpreter regularly
> tries to switch threads"
>
> ... which would explain the "None" message Markos test program reports,
> on calling self.context.pmDerivedErrStr(), if we are now running on some
> other thread.
You may have misinterpreted that sentence. That applies -if- the
python program was itself multithreaded (using the "threading"
module), and maybe then only if this needed to be emulated by python
VM-level time-slicing (if there is no pthreads on the platform).
- FChE
|