Hi Devs,
I have run into a nasty bug while merging the bi-directional astar and dijkstra algorithms.
Currently most of the code is getting merged into a single shared object. I can run tests after I merge code. the trsp code hangs the backend (requires a kill -9 to stop the process) if it is linked with the bi-directional stuff. I'm not even running the bidirectional code as the trsp is the first test.
I get no warnings or errors when I compile or link or install but running the trsp query hangs everything.
Rebuilt with the bi-directional code and everything is fine.
The test process creates a new database and installs the extensions, loads the data, runs the queries. So it is a clean start each time.
I have no idea how to debug this? as it appears to be a linker issue, or collision of symbols or globals or some such.
Any ideas or thoughts on this?
I can try to create a new shared library for the bi-directional code, but it seems like this issue should be tracked down and fixed if possible.
-Steve
On 5/3/2013 8:50 PM, Stephen Woodbridge wrote:
Hi Devs,
I have run into a nasty bug while merging the bi-directional astar and
dijkstra algorithms.
Currently most of the code is getting merged into a single shared
object. I can run tests after I merge code. the trsp code hangs the
backend (requires a kill -9 to stop the process) if it is linked with
the bi-directional stuff. I'm not even running the bidirectional code as
the trsp is the first test.
I get no warnings or errors when I compile or link or install but
running the trsp query hangs everything.
Rebuilt with the bi-directional code and everything is fine.
The test process creates a new database and installs the extensions,
loads the data, runs the queries. So it is a clean start each time.
I have no idea how to debug this? as it appears to be a linker issue, or
collision of symbols or globals or some such.
Any ideas or thoughts on this?
I can try to create a new shared library for the bi-directional code,
but it seems like this issue should be tracked down and fixed if possible.
As a followup to this issue, putting the bi-directional code in its own library avoids the back-end hang. I don't like not knowing what the problem is because it will come back an bite us later, but at least this provides another data point and a potential work-a-round to the problem.
Does this jog anyone's memory around similar issues you have encountered?
-Steve