nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SceneView Crashes When Maps and Graphics Come Into View

RobBever

I'm having an issue where, when I have several .tpk files loaded into layers (maybe 10 or 12, ~8 gigs) and maybe 50-100 graphics of various kinds in 3D, I get a crash from the runtime.

I've noticed that this doesn't happen when I don't have any graphics, but if there are graphics and several TPK layers, when I switch to that view, I get a crash. Oddly it sometimes seem to happen more easily when more zoomed-in, I'm not sure why.

This is a problem because the error comes up from C++ in an asynchronous way and thus I don't know of a way to catch it, it just kills my application every time. The error is:

Esri.ArcGISRuntime.ArcGISRuntimeException: 'Internal error exception. Buffer_loader_cache::map_buffer ERROR, cannot create staging resource!: c:\daily_r\rtc\runtimecore\c_api\src\mapping\map_view\geo_view.cpp (209) : error : Exception caught in RT_GeoView_pulse'

This isn't related to available RAM, I have plenty. One thing that seems to trigger it relatively easily is a wide view -- let's say all my maps and data are in Florida. If my 3D map starts very zoomed-out over Africa, then I drag the map around so that the TPKs and Graphics come into view at the same time, it'll crash and give me this error. I'm assuming it has something to do with allocating Graphics and map data at the same time.

I can cause this error consistently, but it doesn't seem to happen if there are lots of TPKs, but not very many or no Graphics. That makes me wonder if it has to do with allocating storage for both kinds of things simultaneously.

My application starts with a 2D map, with the 3D SceneView control loaded in memory but not attached to the current visual tree (it's in a Prism region). When I switch from 2D to 3D (using Prism navigation to swap out the 2D control for the 3D control), then navigate to where my data is, I'll frequently get the above crash. So it may have something to do with how WPF is trying to manage the SceneView's resources as it gets removed and re-added to the visual tree, as well.

Right now the only mitigation I have for this problem is to, by convention, limit the number of TPK files I have loaded at any given time, since with a small number of TPKs I don't see this issue. It's difficult to tell end users they can't load too many map files, though, so some kind of way to solve this problem would be appreciated.

Najděte více příspěvků označených jako

Accepted answers

MichaelBranscomb

It's possible that as an x86 app it is simply running out of memory: x86 is limited to 2GB but practically you typically see issues at approx 1.2GB.

Building as x64 would allow the app to use more memory.

You should still monitor the memory usage, because we'd want to know if the memory continues to increase to an excessively high level (that could indicate a bug somewhere).

Cheers

Mike

All comments

RobBever

Took some doing, but I built as x64. Thus far, it appears that the issue doesn't happen in an x64 build. I was previously able to trigger it very consistently by simply swapping between 2D and 3D views rapidly, and even that no longer seems to cause a problem.

My theory would be that, although the application didn't run out of memory, somewhere in the ESRI C++ libraries, due to the various graphics and TPK tiles, the code did some kind of calculation or allocation which overflowed the size limit, due to having 7.7ish gigs of TPK data alongside the various Graphics objects. This calculation error then caused some manner of uncaught exception, which flowed up into WPF and made the application crash.

Regardless, going to x64 appears to have solved this issue. Thanks for that suggestion, I appreciate your help.

RobBever

Retested, it was ~600MB of RAM usage before it crashed. A decent portion of that would be in my code though.

Good point about the RAM cap, I'll see how hard it would be to build my code as x64. It will definitely take some effort but I definitely want to get this crash eliminated.

RobBever

I thought about that, but when I watched the RAM usage it wasn't excessively high before it crashed (I think it was 200-300MB). Also, if it doesn't crash right away, everything loads fine and runs well.

My thought was maybe it was trying to prepare memory behind the scenes, and since there was a lot of potential data it hit the cap. But it didn't appear to actually request that memory from the OS.

What's strange is that I tried doing just the large TPKs alone and I wasn't able to get it to crash then, and it was more stable even with a lot of Graphics objects if there were only a couple of TPKs. It seemed to have something to do with having lots of large TPKs loaded and also a bunch of Graphics coming into view at the same time.

MichaelBranscomb

It's possible that as an x86 app it is simply running out of memory: x86 is limited to 2GB but practically you typically see issues at approx 1.2GB.

Building as x64 would allow the app to use more memory.

You should still monitor the memory usage, because we'd want to know if the memory continues to increase to an excessively high level (that could indicate a bug somewhere).

Cheers

Mike

RobBever

Overall it's built for x86, although some of the DLLs are Any.

Is there any advantage to going to x64? I could probably do that if it runs better or prevents crashes.

MichaelBranscomb

Hi,

Is your application compiled as x86, x64, AnyCPU, or AnyCPU + Prefer 32-bit?

Regards

Mike

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.