picar / pyrrd

Automatically exported from code.google.com/p/pyrrd
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

TypeError: execv() arg 2 must contain only strings #17

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. create instance of Graph
2. correctly extend it with defs, cdefs, etc
3. call .write()

What is the expected output? What do you see instead?
Expected: png file
Instead of expected:
File "my_rrd_graph.py", line 189, in rrd_graph
   g.write()
 File "build/bdist.linux-i686/egg/pyrrd/graph.py", line 804, in write
   rrdbackend.graph(*data)
 File "build/bdist.linux-i686/egg/pyrrd/external.py", line 288, in graph
   _cmd('graph', parameters)
 File "build/bdist.linux-i686/egg/pyrrd/external.py", line 17, in _cmd
   p = Popen([args], shell=True, stdin=PIPE, stdout=PIPE, 
close_fds=close_fds)
 File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
   errread, errwrite)
 File "/usr/lib/python2.5/subprocess.py", line 1149, in _execute_child
   raise child_exception

TypeError: execv() arg 2 must contain only strings

What version of the product are you using? On what operating system?
Stable Debian Etch, python2.5, latest pyrrd.

Please provide any additional information below.
This happened after regular aptitude safe-upgrade of stable Debian (only 
secure patches).

Original issue reported on code.google.com by alexande...@gmail.com on 3 Nov 2009 at 12:08

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Are you able to test from a bzr or svn checkout? If so, can you try this 
against the
latest trunk? The reason I ask is that I can't reproduce this problem.

If that's not possible for you, I will update this ticket when I've released 
the next
version of PyRRD, so that you can download it from PyPI.

Thanks!

Original comment by duncan.m...@gmail.com on 19 Dec 2009 at 9:44

GoogleCodeExporter commented 9 years ago
The problem was deeper and apache/mod_wsgi related. With nginx+flup, 
nginx+tornado, 
nginx+fastcgi everything works perfectly and only with apache+mod_wsgi sample 
code 
raises that exception. I think we can close this issue.

Original comment by alexande...@gmail.com on 23 Dec 2009 at 10:14

GoogleCodeExporter commented 9 years ago
Great! I  appreciate you taking the time to update the ticket -- thanks!

Original comment by duncan.m...@gmail.com on 23 Dec 2009 at 10:28