Crash: RT_WMTSTileMatrixSet_getWellKnownScaleSetId

191
6
09-12-2019 03:15 PM
JeffSiemens
New Contributor II

We're seeing this crash a lot in our crash reports. It happens immediately on startup of the application, and curiously this app does not even reference any WMTS layers.

Is this a known issue? Any way we can troubleshoot it further?

Stack traces
BACKGROUND THREAD 24 - CRASHED
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • ArcGIS-arm64
    RT_WMTSTileMatrixSet_getWellKnownScaleSetId
  • libdispatch.dylib
    _dispatch_client_callout
Tags (1)
0 Kudos
6 Replies
dotMorten_esri
Esri Frequent Contributor

Could you share some more information about this? What does you app do, what platform and device is it running, do you have a full output log etc?

0 Kudos
JeffSiemens
New Contributor II

Hi Morten,

Sorry I was a little light on details. 

We've seen it consistently on iOS and Android. The app is an offline data collection app, but the crash is occurring on startup (no editing being done), loading an online web map. The last line our lines indicates that we're about to load the map, and then the app crashes.

It's occurring about 30-40% of the time on startup, and it's not occurring on builds out of Visual Studio for some reason (only off our build server) which makes it a little more difficult to troubleshoot.

I'm just a little confused why it would doing anything to do with WMTS when we don't have any WMTS layers.

I will try to get some better diagnostics and see if I can provide you with more details.

Jeff

0 Kudos
dotMorten_esri
Esri Frequent Contributor

It's interesting you only see if on your build server. Are the Visual Studio versions significantly different? Are you building in release locally as well? It seems some sort of corruption is happening so it's calling into the wrong methods.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Could you share which specific version of Visual Studio you are using on the build server vs the builds you make locally? We might have a lead that this could be due to a mono bug recently introduced.

0 Kudos
JeffSiemens
New Contributor II

Hi Morten,

Sorry I should have followed up with you on this earlier. Your original question about whether or not the build server VS versions varied significantly got me thinking that this might indeed be the problem, since our versions did vary significantly. Unfortunately, I've now upgraded the servers, so I can't tell you exactly what they used to be, but it was 2017 on the build server (unknown exact version), and 2019 for development (15.2.x).

For the current ios build we're on 8.2.6 (2019), and for Android we're on on 16.2.5 (also 2019).

Upgrading these servers did actually address the ios crash, but not Android. And even for ios, while the crash did go away, we still were experiencing map initialization failures, which actually turned out to be caused by some fairly hacky stuff we were doing on startup. Effectively, in order to ascertain 'true' edit/delete/add-feature capabilities, we are basically doing a test add/edit/update and checking to see if the Runtime throws an exception, and then rolling back the edits. Rolling back edits it seems was causing the crash with WMTS, but there was also ocassionally the stack trace below, which seems a lot more related to what we were doing. I still have no idea why rolling back edits would cause the WMTS issue, but it seems to be gone now through a combination of upgrading the build server, and deferring our hack to test editing capabilities.

BACKGROUND THREAD 27 - CRASHED
  • ArcGIS-arm64
    Esri_runtimecore::Geodatabase::Table::revert_changes(Esri_runtimecore::Geodatabase::Difference_from, boost::optional<Esri_runtimecore::Common::Date_time>)
  • ArcGIS-arm64
    std::__1::__function::__func<auto Esri_runtimecore::Mapping::Service_feature_table::undo_local_edits(Esri_runtimecore::Mapping::Task_options const&)::$_36::operator()<Esri_runtimecore::Common::Weak_visitor_ptr<Esri_runtimecore::Mapping::Service_feature_table>, Esri_runtimecore::Mapping::Task_completion_source<void>, Esri_runtimecore::Mapping::Task_options>(Esri_runtimecore::Common::Weak_visitor_ptr<Esri_runtimecore::Mapping::Service_feature_table>&, Esri_runtimecore::Mapping::Task_completion_source<void>&, Esri_runtimecore::Mapping::Task_options&)::'lambda'(), std::__1::allocator<std::__1::allocator>, void ()>::operator()()
  • ArcGIS-arm64
    std::__1::__function::__func<Esri_runtimecore::Mapping::Task<void>::Task(std::__1::function<void ()>, Esri_runtimecore::Mapping::Task_options)::$_1, std::__1::allocator<Esri_runtimecore::Mapping::Task<void>::Task(std::__1::function<void ()>, Esri_runtimecore::Mapping::Task_options)::$_1>, boost::any ()>::operator()()
  • ArcGIS-arm64
    std::__1::__function::__func<Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0, std::__1::allocator<Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0>, boost::any ()>::operator()()
  • ArcGIS-arm64
    pplx::details::_PPLTaskHandle<boost::any, pplx::task<boost::any>::_InitialTaskHandle<boost::any, Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0, pplx::details::_TypeSelectorNoAsync>, pplx::details::_TaskProcHandle>::invoke() const
  • ArcGIS-arm64
    pplx::details::_TaskProcHandle::_RunChoreBridge(void*)
  • ArcGIS-arm64
    Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*)
  • ArcGIS-arm64
    Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*)
  • libdispatch.dylib
    _dispatch_client_callout

If you're wondering why we're doing this hack to check edit capabilities, it's because we don't have a good way from the ArcGIS Runtime to check whether or not the user has permissions to update/delete/add. The CanUpdate, CanAdd, CanDelete properties on a FeatureTable don't take licensing and anonymous access into account (see bug ENH-000124520), and LayerInfo OwnershipBasedAccessControl is not populated in all cases (case #02370084 with Esri support).

For full reference, here is our code to truly check if the user has for example update permission:

If there was a nice little method we could call in the Runtime, that would save us from having to do all this hacky work!


public override async Task<bool> UserCanUpdate()
{
var license = ArcGISRuntimeEnvironment.GetLicense();
if (license.LicenseLevel == LicenseLevel.Lite && Capabilities.SupportsUpdate)
{
// If we have a Lite-level license, the previous check is not enough to ensure that we are reporting correct values,
// we have to assert that anonymous adding and editing are also allowed for this layer (e.g. it must be a publicly shared
// layer with editing enabled)
if (_supportsAnonymousUpdate == null)
{
_supportsAnonymousUpdate = Layer.FeatureTable.CanUpdateAnonymously();
}

bool supportsAnonymousUpdate = await _supportsAnonymousUpdate;
return supportsAnonymousUpdate;
}

return Capabilities.SupportsUpdate;
}


internal static async Task<bool> CanUpdateAnonymously(this FeatureTable table)
{
bool canEdit = false;
if (table is ServiceFeatureTable sft &&
sft.LayerInfo.OwnershipBasedAccessControl != null &&
sft.LayerInfo.OwnershipBasedAccessControl.AllowOthersToUpdate)
{
// If the layer has Ownership-Based Access Control (OBAC) configured AND users other than the creator are able to edit the
// feature, we can skip manually testing the update operation and instead can rely on this property.
canEdit = sft.LayerInfo.OwnershipBasedAccessControl.AllowAnonymousToUpdate;
}
else
{
try
{
// If we are using a Lite level license and the layer does not support OBAC, the best we can do is attempt an "empty" update
// and catch the error if it fails. (the CanUpdate() method does not return accurate results in this case).
var testFeature = await table.QuerySingleFeatureAsync();
if (testFeature == null)
{
// If there are no features, we'll have to add a dummy one for testing (which we will remove after).
testFeature = table.CreateFeature();
await table.AddFeatureAsync(testFeature);
}

if (testFeature is ArcGISFeature arcgisFeature && arcgisFeature.LoadStatus != Esri.ArcGISRuntime.LoadStatus.Loaded)
{
// Need to load the feature before calling the update.
await arcgisFeature.LoadAsync();
}

// Test update.
await table.UpdateFeatureAsync(testFeature);
canEdit = true;
}
catch
{
// The update failed, so we know for sure that we both cannot update nor delete (since delete is never a
// standalone permission).
canEdit = false;
}
finally
{
// Ensure we clear out any edits we made.
try
{
await table.ClearLocalEditsAsync();
}
catch (Exception) { }
}
}

return canEdit;
}

 

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I'm assuming the Android issue you're seeing is a different callstack.

I actually happened to reproduce the WMTS issue today, both with VS16.3 and VS4Mac 8.3. It only happens with a very specific app and at about the same ratio you're seeing, and since I recently updated VS2019, I'm wondering if that is related. Up until today, your case was the only one, but we now have two PCs that reproduces it.

Sorry I don't have much to go on yet wrt resolving it, but it appears the symbol table for native calls is getting messed up (the specific method happens to be the last method if you sort them all by name, so I think that's more random and doesn't really have anything to do with WMTS).

On the up-side it appears to be project specific, so there's probably some still-to-be-discovered project setting that causes this.

0 Kudos