[issue21251] Standard library trace module crashes with exception

[Irit Katriel]

Irit Katriel  added the comment:

Martin, please create a new issue if this is still a problem in Python 3.

--
resolution:  -> out of date
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21251] Standard library trace module crashes with exception

[Irit Katriel]

Irit Katriel  added the comment:

pyblock supports python 3 now. Are you seeing the problem pm 3.8+?Otherwise 
this issue can be closed since python 2 past EOL.

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21251] Standard library trace module crashes with exception

[Martin Kolman]

Martin Kolman added the comment:

@ 1.: Reproducer attached to the comment - just build the C code and run 
trace_test.py It is maybe not as minimal as it could be but I'm afraid the 
context of what the module is doing would be lost if it was cut down too 
aggressively.

@ 2.: I'm afraid this is not applicable in this case - pyblock just flat out 
does not support Python 3 and I haven't been able to find out even any 
third-party Python 3 port of it. I even tried to force run the current code 
with Python 3, just in case, but it just tracebacks during import due to Python 
3 incompatible code, even before even importing the C extensions.

--
Added file: http://bugs.python.org/file35009/pyblock.tar.xz

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21251] Standard library trace module crashes with exception

[Terry J. Reedy]

Terry J. Reedy added the comment:

Third party compiled C crashers are nasty. Two suggestions:
1. Reduce the failing example to the minimum needed to fail. If you bypass all 
the python code in maps.py and device.py and just 'import dmraid', do you still 
get a crash at that point.
2. What happens if you run a minimal crasher with 3.4 or .5? I don't know if 
all the 3.x work on trace was backported.

--
nosy: +belopolsky, ncoghlan, terry.reedy
stage:  - needs patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21251] Standard library trace module crashes with exception

[Martin Kolman]

New submission from Martin Kolman:

We are currently working on adding tracing support to Anaconda, the Fedora/Red 
Hat Enterprise Linux installer and we have encountered some pretty strange 
behavior of the trace module. Anaconda (or to be concrete the Blivet storage 
library used by Anaconda) uses the pyblock module, but just importing it 
crashes the trace module with a strange exception.

It can be reproduced like this:
0. install pyblock (on Fedora is is provided by the python-pyblock package)

1. write some python code that imports the block module provided by pyblock

echo import block  pyblock_trace.py

2. try to trace the code

python -m trace -t pyblock_trace.py

The trace module starts tracing but after a few seconds it crashes with the 
following traceback:


Traceback (most recent call last):
  File /usr/lib64/python2.7/runpy.py, line 162, in _run_module_as_main
__main__, fname, loader, pkg_name)
  File /usr/lib64/python2.7/runpy.py, line 72, in _run_code
exec code in run_globals
  File /usr/lib64/python2.7/trace.py, line 830, in module
main()
  File /usr/lib64/python2.7/trace.py, line 818, in main
t.runctx(code, globs, globs)
  File /usr/lib64/python2.7/trace.py, line 513, in runctx
exec cmd in globals, locals
  File pyblock_trace.py, line 1, in module
import block
  File /usr/lib64/python2.7/site-packages/block/__init__.py, line 47, in 
module
import dmraid
  File string, line 1, in module
  File /usr/lib64/python2.7/trace.py, line 609, in globaltrace_lt
filename = frame.f_globals.get('__file__', None)
AttributeError: 'module' object has no attribute 'get'


The dmraid module is written in C and we have looked though its source[1] code 
but have found nothing extraordinary. Most importantly there is no code 
touching the globals, but it still fails.

When looking what actually is in frame.f_globals we found that in all 
successful calls it has the globals dictionary but for the dmraid module it for 
some reason contains the module instance instead. Module instance is not a 
dictionary, so it doesn't have the get method and this leads to the exception 
above.

This is not the only C module we use, but this is the only one that triggers 
the crash in trace.


Additional information
Python version: 2.7.5
architecture: X86_64
OS: Fedora 20


[1] https://git.fedorahosted.org/cgit/pyblock.git/tree/dmraid.c

--
components: Library (Lib)
files: trace.log
messages: 216459
nosy: mkolman
priority: normal
severity: normal
status: open
title: Standard library trace module crashes with exception
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34908/trace.log

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com