Problem with Popen arguments passed as map
See original GitHub issueGreetings!
I am having an issue when using the package sorl.thumbnail
on a Django project. That package produces thumbnails from images using system installed programs (called engines.)
When sorl.thumbnail
makes a Popen
call here:
The arguments that are received in your patched Popen
are not being interpreted correctly. This is the suspect of the problem:
Arguments are handled in such a way that the original popen
crashes when trying to access args[0]
, as the args
parameter is interpreted (or actually becomes) an empty list.
In my opinion, the problem arises because in sorl.thumbnail
the arguments to Popen
are passed to a map
function first, so that a map
object is what gets passed as arguments. I am not sure what’s the effect of a map
object being received in your *a
of the patched Popen
.
Here’s the relevant part of the traceback I am getting:
File "/mnt/d/Proyectos/ginseng/.venv/lib/python3.6/site-packages/sorl/thumbnail/base.py", line 131, in get_thumbnail
thumbnail)
File "/mnt/d/Proyectos/ginseng/.venv/lib/python3.6/site-packages/sorl/thumbnail/base.py", line 164, in _create_thumbnail
default.engine.write(image, options, thumbnail)
File "/mnt/d/Proyectos/ginseng/.venv/lib/python3.6/site-packages/sorl/thumbnail/engines/convert_engine.py", line 57, in write
p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
File "/mnt/d/Proyectos/ginseng/.venv/lib/python3.6/site-packages/sentry_sdk/integrations/stdlib.py", line 165, in sentry_patched_popen_init
return old_popen_init(self, *a, **kw)
File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.6/subprocess.py", line 1248, in _execute_child
executable = args[0]
IndexError: list index out of range
If I remove the Sentry integration altogether from the Django project, sorl.thumbnail
is able to effectively call Popen
with the “mapped” arguments, and everything works.
Thanks in advance!
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (3 by maintainers)
Top GitHub Comments
@WilliamMayor to be clear we will fix the SDK to not change the real-world behavior of subprocess, so if your end goal here is to get a newer version of the SDK working again, just wait for a release. I am just saying that those upstream libraries are also broken in the sense that they use the stdlib in an undocumented way and are unlikely to work on PyPy, and I would apprechiate it if somebody went to those projects and made their maintainers aware. There seem to be multiple of them.
I experienced this with Django’s collectstatic command running pysassc. I had to downgrade to version 0.9.5 (the last working version I’d used) to get my Heroku deploys to start working again.