Select to view content in your preferred language

Local Server ServiceFeatureTable crashes when you close immediately.

152
2
Jump to solution
4 weeks ago
RenzSui
Emerging Contributor

Hello, I have this problem when I close an app immediately after the ServiceFeatureTable is loaded, arcgis maps runtime crashes and it seems that the problem is dangling pointer to a task that's causing the crash.

Here's the code that I placed using the LocalServerServices sample as base code.

 

 

 

        private async void StartServiceButtonClicked(object sender, RoutedEventArgs e)
        {
            try
            {
                // Start the selected service
                await _selectedService.StartAsync();

                if(_selectedService is LocalFeatureService lfs)
                {
                    var uri = _selectedService.Url;
                    var serviceFeatureTable = new ServiceFeatureTable(new Uri(_selectedService.Url.ToString() + "/0"));
                    await serviceFeatureTable.LoadAsync();
                    if(serviceFeatureTable.LoadStatus == Esri.ArcGISRuntime.LoadStatus.Loaded)
                    {
                        Trace.WriteLine("Sft Status Loaded");
                    }
                }

                // Update the UI
                UpdateServiceControlUi();
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message, "Failed to start service");
            }
        }

 

 

 

 

To replicate, simply run the app, start local server, start the feature service. Wait for it to print "Feature service started", close the app. The crash doesn't happen if I wait long enough (say, around 15 seconds after).

Can anyone point me to the right direction as to how to handle serviceFeatureTables on local server without crashing it?

Here's a screenshot of the crash.

LocalServerCrash.png

 

0 Kudos
1 Solution

Accepted Solutions
JesseCloutier
Esri Community Manager

Hi @RenzSui, we appreciate you sharing a potential bug with the broader Esri Community; however, Esri does not actively track software defects posted here. The official channel for investigating and validating bugs is Esri Technical Support. All customers experiencing a potential software bug should leverage technical support to report and investigate the issue.

By reporting bugs through technical support, Esri can better track the scope and impact of the issue across all our customers and better prioritize it with our product teams. Our teams can also investigate the issue more thoroughly to see if there is a solution, workaround, or patch to get you back up and running as soon as possible.

As a reminder, Esri Community is primarily a self-service support platform where Esri users can ask or answer each other’s questions, share feature requests, and collaborate to solve problems with GIS.

*Note that this is a scripted message prompted when posts allude to a potential product bug.

Jesse Cloutier
Community Manager, Engagement & Content

View solution in original post

0 Kudos
2 Replies
RenzSui
Emerging Contributor

Here are further details investigated by me and my colleague:

It seems that forcing a Gc.Collect call manages to mitigate the crash. However, having the Gc.Collect call is not ideal as it is considered a hack in this case.

Here's the stack trace of the crash with the symbols loaded:

RenzSui_1-1733227113387.png

1. When the ServiceFeatureTable is created, internally it's creating a client reference

2. If you wait some time, that client reference has its finalizer called when normal gc happens.

3. If you close the application quickly then the Gc calls the finalizer during shutdown and it's when it's trying to make a call to a zero memory location which gives the access violation that you're seeing.

This seems to be a bug in Arcgis maps runtime with local server unless there's something that we're missing.

 

0 Kudos
JesseCloutier
Esri Community Manager

Hi @RenzSui, we appreciate you sharing a potential bug with the broader Esri Community; however, Esri does not actively track software defects posted here. The official channel for investigating and validating bugs is Esri Technical Support. All customers experiencing a potential software bug should leverage technical support to report and investigate the issue.

By reporting bugs through technical support, Esri can better track the scope and impact of the issue across all our customers and better prioritize it with our product teams. Our teams can also investigate the issue more thoroughly to see if there is a solution, workaround, or patch to get you back up and running as soon as possible.

As a reminder, Esri Community is primarily a self-service support platform where Esri users can ask or answer each other’s questions, share feature requests, and collaborate to solve problems with GIS.

*Note that this is a scripted message prompted when posts allude to a potential product bug.

Jesse Cloutier
Community Manager, Engagement & Content
0 Kudos