Hi all, I'm trying to verify that I'm looking at bugs in graph_tool, and not my own user error. A little background: I'm using graph_tool to search over graphs that have been generated by graph_tool.generation.geometric_graph(). The graph represents an occupancy grid that some simulated robots are traversing. The robots do not know apriori which vertices are occupied, so they have to update their own internal maps of the world as they try to move. They do this by updating an internal edge filter (one for each robot) which filters out untraversable edges. In this way, I have one graph, and multiple edge filters, which works fairly well when I'm trying to use either graph_tool.search.dijkstra_search() or graph_tool.search.astar_search() functions to decide where to go next (I swap filters more or less non-stop). To test out how well this works, I'm randomly generating graphs and occupied vertices, and then running my code on those randomly generated graphs. Sometimes I'll end up with 50-60 tests successfully completed, and sometimes it'll die on the first test. I have no idea when or how it will die, and when I've set up code to draw the graph immediately prior to calling either dijkstra or astar, the graphs don't look particularly strange, nor do they have anything in common with one another. It just dies with a "RuntimeError: maximum recursion depth exceeded" exception as shown below. I'm also getting the divide by zero errors that cairo is complaining about, but I'm less worried about those as they are just part of my debugging display code. In the worst case, I can find a way of displaying everything using some other method. Build info:
uname -a Linux forge 3.2.0-40-generic #64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux python Python 2.7.3 (default, Aug 1 2012, 05:14:39) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
numpy.__version__ '1.6.1' graph_tool.__version__ '2.2.23 (commit 66e8c6a6, Wed Mar 20 14:51:22 2013 +0100)'
Note that I built it with OpenMP enabled. If someone can tell me how to enable more debugging output, I can do that and send the output somewhere. Thanks, Cem Karan The complete stack trace: ckaran@forge:~/fuerte_workspace/gridWorldSimulator/src$ nosetests --nocapture --nologcapture -x Random_walk_robot_test.py:Random_walk_robot_test.test_call ..../usr/lib/python2.7/dist-packages/graph_tool/draw/cairo_draw.py:957: RuntimeWarning: divide by zero encountered in double_scalars zoom_y = (geometry[1] - sum(y_delta)) / (y_range[1] - y_range[0]) ......................../usr/lib/python2.7/dist-packages/graph_tool/draw/cairo_draw.py:956: RuntimeWarning: divide by zero encountered in double_scalars zoom_x = (geometry[0] - sum(x_delta)) / (x_range[1] - x_range[0]) .E ====================================================================== ERROR: Random_walk_robot_test.Random_walk_robot_test.test_call(8, 9) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/ckaran/fuerte_workspace/gridWorldSimulator/src/Random_walk_robot_test.py", line 122, in _test_call_helper if not random_walk_bot(): File "/home/ckaran/fuerte_workspace/gridWorldSimulator/src/Random_walk_robot.py", line 71, in __call__ result = self._nearest_unexplored_vertex() File "/home/ckaran/fuerte_workspace/gridWorldSimulator/src/ABC_Robot.py", line 254, in _nearest_unexplored_vertex (dist_map, pred_map) = self._dijkstra_search(self._current_vertex, self._edge_might_be_traversable_property) File "/home/ckaran/fuerte_workspace/gridWorldSimulator/src/ABC_Robot.py", line 237, in _dijkstra_search self._world_map.world_graph.edge_properties[Globals.EDGE_WEIGHT]) File "/usr/lib/python2.7/dist-packages/graph_tool/decorators.pyc", line 2, in dijkstra_search �`\Qc@`s�dZddlmZmZmZdZdZdZddddl Z ddl File "/usr/lib/python2.7/dist-packages/graph_tool/search/__init__.py", line 133, in wrap ret = func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/graph_tool/search/__init__.py", line 865, in dijkstra_search compare, combine, zero, infinity) File "/usr/lib/python2.7/dist-packages/graph_tool/search/__init__.py", line 105, in wrap ret = func(*args, **kwargs) << About 500 lines of repetition of the above 2 lines>> File "/usr/lib/python2.7/dist-packages/graph_tool/search/__init__.py", line 105, in wrap ret = func(*args, **kwargs) RuntimeError: maximum recursion depth exceeded
On 04/11/2013 03:00 AM, CFK wrote:
To test out how well this works, I'm randomly generating graphs and occupied vertices, and then running my code on those randomly generated graphs. Sometimes I'll end up with 50-60 tests successfully completed, and sometimes it'll die on the first test. I have no idea when or how it will die, and when I've set up code to draw the graph immediately prior to calling either dijkstra or astar, the graphs don't look particularly strange, nor do they have anything in common with one another. It just dies with a "RuntimeError: maximum recursion depth exceeded" exception as shown below.
Looks very strange. Could you please provide a minimal self-contained example which triggers the problem?
I'm also getting the divide by zero errors that cairo is complaining about, but I'm less worried about those as they are just part of my debugging display code. In the worst case, I can find a way of displaying everything using some other method.
See if the vertex positions values are strange. Again, a minimal example would allow me to understand the source of the problem. Cheers, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
I'll pull together the code from the tests I'm doing, but it will take me a couple of days to get the appropriate releases through work. What would be the best way for me to get it to you? Just email you a tarball of it all? Thanks, Cem Karan On Apr 11, 2013, at 10:54 AM, Tiago de Paula Peixoto wrote:
On 04/11/2013 03:00 AM, CFK wrote:
To test out how well this works, I'm randomly generating graphs and occupied vertices, and then running my code on those randomly generated graphs. Sometimes I'll end up with 50-60 tests successfully completed, and sometimes it'll die on the first test. I have no idea when or how it will die, and when I've set up code to draw the graph immediately prior to calling either dijkstra or astar, the graphs don't look particularly strange, nor do they have anything in common with one another. It just dies with a "RuntimeError: maximum recursion depth exceeded" exception as shown below.
Looks very strange. Could you please provide a minimal self-contained example which triggers the problem?
I'm also getting the divide by zero errors that cairo is complaining about, but I'm less worried about those as they are just part of my debugging display code. In the worst case, I can find a way of displaying everything using some other method.
See if the vertex positions values are strange. Again, a minimal example would allow me to understand the source of the problem.
Cheers, Tiago
-- Tiago de Paula Peixoto <tiago@skewed.de>
_______________________________________________ graph-tool mailing list graph-tool@skewed.de http://lists.skewed.de/mailman/listinfo/graph-tool
On 04/12/2013 11:48 AM, Cem Karan wrote:
I'll pull together the code from the tests I'm doing, but it will take me a couple of days to get the appropriate releases through work. What would be the best way for me to get it to you? Just email you a tarball of it all?
Would it not be possible to isolate one single graph and the operation on it which triggers the problem in a single small script? Cheers, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
On Apr 12, 2013, at 9:52 AM, Tiago de Paula Peixoto wrote:
On 04/12/2013 11:48 AM, Cem Karan wrote:
I'll pull together the code from the tests I'm doing, but it will take me a couple of days to get the appropriate releases through work. What would be the best way for me to get it to you? Just email you a tarball of it all?
Would it not be possible to isolate one single graph and the operation on it which triggers the problem in a single small script?
I haven't tried that, but if my latest tests fail, then I'll try to isolate it as you suggest. If I can't find a particular graph that fails (or a set of them), I'll send you the code instead. The issue may resolve itself though; I'm in the process of installing the latest version of boost to see if that'll solve the problem. I'll know more by Sunday. Thanks, Cem Karan
participants (3)
-
Cem Karan -
CFK
-
Tiago de Paula Peixoto