'touching' certain parts of the street network seems to trigger crashes, when calling LocalRouteTask.solve.
I have attached the geodatabase I'm using for routing, to this post.
The data set was built by an ESRI partner, partially with your assistance earlier (msg 595156 - a problem caused by accidental clipping.)
The example trace is between these two points:
// Iceland, narrow-bad crash:
ER::Point pointA(-21.590907, 64.180326, EgisProj2::sr_wgs);
ER::Point pointB(-21.590828, 64.180222, EgisProj2::sr_wgs);
which were precisely chosen to demonstrate the issue. Those points are very close by each other, only because I narrowed them down to 'where the map broke' (the outset was an attempt to trace between points 6 km apart).
Here is a stack trace dump. though I have never been able to get any useful info from any stack traces when ArcGis crashes;
I presume because of the service-styled architecture (ie my call is presumably hidden in some asynchronous hand-off)
| 0 | QSortFilterProxyModel::mapToSource | Qt5Cored | 0x666a01f7 | ||
| 1 | EsriRuntimeQt::OnlineRouteTaskParameters::getImpl | EsriRuntimeQtd | 0x11c6ed2 | ||
| 2 | EsriRuntimeQt::SolveCondition::messagesForCondition | EsriRuntimeQtd | 0x11f846b | ||
| 3 | EsriRuntimeQt::SolveCondition::messagesForCondition | EsriRuntimeQtd | 0x11f693f | ||
| 4 | EsriRuntimeQt::SolveCondition::messagesForCondition | EsriRuntimeQtd | 0x11f63d3 | ||
| 5 | EsriRuntimeQt::SolveCondition::trUtf8 | EsriRuntimeQtd | 0x11b7b38 | ||
| 6 | EsriRuntimeQt::LocalRouteTask::isValid | EsriRuntimeQtd | 0x11c88e1 | ||
| 7 | EsriRuntimeQt::LocalRouteTask::isValid | EsriRuntimeQtd | 0x11c9669 | ||
| 8 | EsriRuntimeQt::LocalRouteTask::isValid | EsriRuntimeQtd | 0x11dab1c | ||
| 9 | EsriRuntimeQt::LocalRouteTask::isValid | EsriRuntimeQtd | 0x11daa4c | ||
| 10 | QSortFilterProxyModel::mapToSource | Qt5Cored | 0x6643c3f8 | ||
| 11 | QSortFilterProxyModel::mapToSource | Qt5Cored | 0x664433c5 | ||
| 12 | _callthreadstartex | threadex.c | 376 | 0xff63651 | |
| 13 | _threadstartex | threadex.c | 359 | 0xff63861 | |
| 14 | BaseThreadInitThunk | kernel32 | 0x7511338a | ||
| 15 | RtlInitializeExceptionChain | ntdll | 0x77739902 | ||
| 16 | RtlInitializeExceptionChain | ntdll | 0x777398d5 |
My original 6-km 'trigger' points (which caused me to hunt the points listed above), are instead:
// Iceland, bad crash:
ER::Point pointAz(-21.6944, 64.1672, EgisProj2::sr_wgs);
ER::Point pointBz(-21.5904, 64.1803, EgisProj2::sr_wgs);
(I cannot guarantee they cause the identical crash - it may be two similar crashes. But neither of them should crash, if you ask me).
BUT - I _can_ do plenty of other tracing on this LocalRouteTask geodatabase, that _doesn't_ crash. So it's just some parts that act broken.
Given that the crashes bring down our entire application, it's a bit difficult to diagnose, since I need to spend about a minute restarting everything, after each crash.
(This scenario is a follow-up on
LocalRouteTask geodatabase format, documentation/how?
https://community.esri.com/message/595156 )
By the way, the reason we are using offline/LocalRouteTask,
is because it's way faster than using the ESRI online router.
When I developed the application, I used the esri online-routing demo server - which runs very very fast.
When time came to deploy with clients, to our horror we learned that ESRI's production online routing runs much slower (ie gives us much slower responses.) I believe the current average times I see for online, per simple A->B (ie trace between two simple nearby points), is about > 2 seconds. This makes it hard to use for clients doing e.g. 70 street link traces, as that would cause the client to sit and wait for several minutes. By using LocalRouteTask, we can achieve the same performance I originally saw from the online test service.
I have used Lukas Danzinger's 'visualize street network' code from my earlier 595156 case,
and on the surface, the problematic area looks OK, if a bit weird (a small rectangle of roads.)
I would have loved to visualize the network as directional arrows, but the C++ Qt api 10.2.6 only includes the SimpleLineSymbol 😕
Apart from input/solution regarding why the street network algorithm will crash on this data built with ESRI tools,
it would also be helpful with any general hints or tips for how to diagnose and check for such problems ourselves.
Once these issues lead to crashes in production for our clients, our position becomes hard to defend :-/.
Thank you for any help /insight you can offer on this
Accepted Solutions
