Select to view content in your preferred language

Insert feature causes Out of memory exception

7366
28
03-13-2013 07:42 AM
AlexeySubbotin
Occasional Contributor
Hi!
I'm developing the 3D modeling GIS software. For 3D city models i use generated from vector data building models and 3d files (Google Earth and SketchUp) with geographic coordinates within. I import such files' geometries with IImport3DFile and store them in multipatch featureclass in file geodatabase.
At last I recieved an exception "Out of memory" during IFeatureCursor.InsertFeature. Have to say that there was no such a problem before (with other files). Error appears constantly after processing definite number of files. Geometries i load from them are correct, i processing their footprints and if i don't save them to my featureclass i process them all with no exceptions. After the exception appears program can't work properly at all until restart (looks like ArcObjects crash).
How you could understand i use insert cursor with featurebuffer. Tried edit sessions, load mode for featureclass, direct write with WriteFeature and so on... No differences. May anybody help me? Any suggestions?
Sorry for my English )
0 Kudos
28 Replies
JasonPike
Frequent Contributor
Hi, Jason. I created the project.
Despite the common logic of the test project and the source, the test project produces another exception, but it occurs at the same operator (insert a feature to the feature class).
Depending on the type of call (in the current thread or in new one) it can be the RCP_E_SERVERFAULT exception wit error code -2147417851 or the external object's exception with error code -2147467259. Also the project is based on .NET Framework 3.5 (as it should be for ArcObjects 10). Couldn't to base it on .NET Framework 4.0, and honestly don't realy understand how it happened with my source project. Maybe the difference of exceptions raised by the projects explaned by different framework they are based on. After all the exception remains and it raises constantly.

Link to archive http://dl.dropbox.com/u/91176632/Test.zip


Ok. I have downloaded your project and the ZipForge dependency.

Here are some of my findings:

1) The reason you were getting the COM Exception was most likely because the projects targeted "Any CPU" instead of "x86". I changed it to "x86" and the exception went away.

2) The reason you could not compile against .NET 4.0 is because the "Embed Interop Types" property was set to true on the ESRI assembly references. If you change "Embed Interop Types" to false for all the ESRI references in the project, it will build against .NET 4.0.

After I got all that sorted out, I stepped through the solution and it succeeded. I succeeded against .NET 3.5 and .NET 4.0. I did notice some places we could improve the COM interop in the code, but we'll look at that later.

Please try the changes I suggest above and see if the test project succeeds for you.
0 Kudos
AlexeySubbotin
Occasional Contributor
Ok. I have downloaded your project and the ZipForge dependency.

Here are some of my findings:

1) The reason you were getting the COM Exception was most likely because the projects targeted "Any CPU" instead of "x86". I changed it to "x86" and the exception went away.

2) The reason you could not compile against .NET 4.0 is because the "Embed Interop Types" property was set to true on the ESRI assembly references. If you change "Embed Interop Types" to false for all the ESRI references in the project, it will build against .NET 4.0.

After I got all that sorted out, I stepped through the solution and it succeeded. I succeeded against .NET 3.5 and .NET 4.0. I did notice some places we could improve the COM interop in the code, but we'll look at that later.

Please try the changes I suggest above and see if the test project succeeds for you.


Ok, i have tried your suggestions.
Target platform was set to "x86" just when my primary source solution was started. I think, it was lost when i "extracted" the test project from it.
At last i even made the configuration for x86 platform in the solution properties. It doesn't help.
Compiled the test project against .NET 3.5 and 4.0. The result is one-exception.
Tried to build and execute the project on another PC with the same result.
At first run application, maybe, didn't checkout 3DAnalyst license and completed with no errors. Of course it didn't import the test model, even didn't open it (IImport3DFile.CreateFromFile failed). I revealed it while debugging with step into along the code. I revealed also that the application was initialized with an Engine Product Code.
So i made some changes to initialize it with an ArcView Product Code (as 3DAnalyst not authorized with Engine). It prevented  the application from the "import 3d model" exception but as expected the "insert feature" exception was thrown.
Also while testing my primary and test projects i noticed that almost any model with it's size more than 5 MB (i mean kmz models, skp was not tested for "the size restrictions" yet) can't be processed correctly.
0 Kudos
JasonPike
Frequent Contributor
Ok, i have tried your suggestions.
Target platform was set to "x86" just when my primary source solution was started. I think, it was lost when i "extracted" the test project from it.
At last i even made the configuration for x86 platform in the solution properties. It doesn't help.
Compiled the test project against .NET 3.5 and 4.0. The result is one-exception.
Tried to build and execute the project on another PC with the same result.
At first run application, maybe, didn't checkout 3DAnalyst license and completed with no errors. Of course it didn't import the test model, even didn't open it (IImport3DFile.CreateFromFile failed). I revealed it while debugging with step into along the code. I revealed also that the application was initialized with an Engine Product Code.
So i made some changes to initialize it with an ArcView Product Code (as 3DAnalyst not authorized with Engine). It prevented  the application from the "import 3d model" exception but as expected the "insert feature" exception was thrown.
Also while testing my primary and test projects i noticed that almost any model with it's size more than 5 MB (i mean kmz models, skp was not tested for "the size restrictions" yet) can't be processed correctly.


I see. The suggestions I made were to get the test project running on your machine. I think that is an important first step.

I should mention that I'm using ArcGIS 10.1 for Desktop on a Windows 7 64-bit machine with 8GB of RAM. Please provide this information for your machine. I had made the following changes to the license checkout code:

if (licenseInit.InitializeApplication(new esriLicenseProductCode[] { esriLicenseProductCode.esriLicenseProductCodeStandard,
new esriLicenseExtensionCode[] { esriLicenseExtensionCode.esriLicenseExtensionCode3DAnalyst }))


Also, I stepped through the code and made sure that no exceptions were occurring and that the field was populated when I reached the InsertFeature call.

If you get exceptions or build errors, please post them--they will help me determine what is going on on your machine.

What build error do you get when you target 4.0?

What are the details of the exception you are getting?

Thanks!
Jason
0 Kudos
AlexeySubbotin
Occasional Contributor
I see. The suggestions I made were to get the test project running on your machine. I think that is an important first step.

I should mention that I'm using ArcGIS 10.1 for Desktop on a Windows 7 64-bit machine with 8GB of RAM. Please provide this information for your machine. I had made the following changes to the license checkout code:

if (licenseInit.InitializeApplication(new esriLicenseProductCode[] { esriLicenseProductCode.esriLicenseProductCodeStandard,
new esriLicenseExtensionCode[] { esriLicenseExtensionCode.esriLicenseExtensionCode3DAnalyst }))


Also, I stepped through the code and made sure that no exceptions were occurring and that the field was populated when I reached the InsertFeature call.

If you get exceptions or build errors, please post them--they will help me determine what is going on on your machine.

What build error do you get when you target 4.0?

What are the details of the exception you are getting?

Thanks!
Jason


I'm using ArcGIS 10 for Desktop SP5 (ArcView with authorized 3DAnalyst) on a Windows 7 64-bit machine with 16GB of RAM. Also ArcGIS Engine Runtime and ArcGIS Engine Developer Kit are installed (3DAnalyst also authorized).

I don't get any build errors at all. The exceptions i getting vary depending on the way of calling the Import3DFiles procedure and the .NET Framework version.

For the project compiled against .NET 4.0:

If i call it in the separate thread and do not debug it (breakpoint is on the catch block), i get the System.Runtime.InteropServices.COMException:

System.Runtime.InteropServices.COMException: Server fault (maybe wrong translation as don't have English in system, sorry) (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
Error code: -2147417851
Source: ESRI.ArcGIS.Geodatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


If i debug it (breakpoint is on the InsertFeature line of code), i get System.OutOfMemoryException:

System.OutOfMemoryException: Out of memory [GeoReferencedObjects3D]
HResult: -2147024882
Sorce: ESRI GeoDatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


If i call the tool procedure in the current thread, i get System.Runtime.InteropServices.SEHException:

System.Runtime.InteropServices.SEHException: External component threw an exception (maybe wrong translate, sorry)
ErrorCode: -2147467259
Source: ESRI.ArcGIS.GeoDatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


For the project compiled against .NET 3.5, i always get the System.Runtime.InteropServices.COMException (Server fault (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFULT))) all times.

Attach the screen shots of debug information windows.
0 Kudos
JasonPike
Frequent Contributor
I'm using ArcGIS 10 for Desktop SP5 (ArcView with authorized 3DAnalyst) on a Windows 7 64-bit machine with 16GB of RAM. Also ArcGIS Engine Runtime and ArcGIS Engine Developer Kit are installed (3DAnalyst also authorized).

I don't get any build errors at all. The exceptions i getting vary depending on the way of calling the Import3DFiles procedure and the .NET Framework version.

For the project compiled against .NET 4.0:

If i call it in the separate thread and do not debug it (breakpoint is on the catch block), i get the System.Runtime.InteropServices.COMException:

System.Runtime.InteropServices.COMException: Server fault (maybe wrong translation as don't have English in system, sorry) (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
Error code: -2147417851
Source: ESRI.ArcGIS.Geodatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


If i debug it (breakpoint is on the InsertFeature line of code), i get System.OutOfMemoryException:

System.OutOfMemoryException: Out of memory [GeoReferencedObjects3D]
HResult: -2147024882
Sorce: ESRI GeoDatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


If i call the tool procedure in the current thread, i get System.Runtime.InteropServices.SEHException:

System.Runtime.InteropServices.SEHException: External component threw an exception (maybe wrong translate, sorry)
ErrorCode: -2147467259
Source: ESRI.ArcGIS.GeoDatabase
Target Site: System.Object InsertFeature(ESRI.ArcGIS.Geodatabase.IFeatureBuffer)
...
Module: esriGeoDatabase.dll


For the project compiled against .NET 3.5, i always get the System.Runtime.InteropServices.COMException (Server fault (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFULT))) all times.

Attach the screen shots of debug information windows.


Well, I did find some memory leaks. Looks like ESRI uses the open source project Little CMS and either doesn't release something returned from one of its calls, or Little CMS has a memory leak. While 3MB of leaked memory isn't small, I doubt it is your problem. I still can't reproduce the error on my machine, possibly because it doesn't happen in 10.1. So, what we can try next is using UMDH to see what is in memory when your program crashes. I'll post instructions in a different post. Also, it is possible that there is plenty of memory available, but due to improper pinning of GCHandles, the .NET allocator is unable to compact the GCHeap and therefore runs out of available memory. We'd need to use WinDbg, SOS, and SOSEX to find that, so will start with the easy stuff first.

+ 2896592 ( 2896592 -      0)     83 allocs BackTrace87C2B4C
+      83 (     83 -      0) BackTrace87C2B4C allocations

 ntdll!RtlAllocateHeap+00000274
 LCMS117LIB!cmsCreateMultiprofileTransform+000005A3
0 Kudos
JasonPike
Frequent Contributor
Well, I did find some memory leaks. Looks like ESRI uses the open source project Little CMS and either doesn't release something returned from one of its calls, or Little CMS has a memory leak. While 3MB of leaked memory isn't small, I doubt it is your problem. I still can't reproduce the error on my machine, possibly because it doesn't happen in 10.1. So, what we can try next is using UMDH to see what is in memory when your program crashes. I'll post instructions in a different post. Also, it is possible that there is plenty of memory available, but due to improper pinning of GCHandles, the .NET allocator is unable to compact the GCHeap and therefore runs out of available memory. We'd need to use WinDbg, SOS, and SOSEX to find that, so will start with the easy stuff first.

+ 2896592 ( 2896592 -      0)     83 allocs BackTrace87C2B4C
+      83 (     83 -      0) BackTrace87C2B4C allocations

 ntdll!RtlAllocateHeap+00000274
 LCMS117LIB!cmsCreateMultiprofileTransform+000005A3


It is also possible that this transform is created once and kept around for the lifetime of the process--it may not be a leak. I think it still warrants asking about.
0 Kudos
JasonPike
Frequent Contributor
INSTALLING THE NECESSARY TOOLS:

1. Download Debugging Tools for Windows. You will likely have to download the entire Windows SDK, but you can browse the ISO for the dbg_x86.msi and just install it. Make sure and install the x86 version regardless of your machine's architecture.
http://msdn.microsoft.com/en-us/wind.../gg463009.aspx

2. Add a User Environment Variable called _NT_SYMBOL_PATH and set its value to this:
cache*C:\dev\symbols;SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\dev\symbols*http://downloads2.esri.com/Support/symbols/

This will allow you to resolve the debugging symbols you need.

3. Add a System Environment variable called OANOCACHE and set its value to 1. The disables Ole Automation caching, which is necessary to get accurate information about which calls allocated memory.

4. [OPTIONAL] Add the Debugging Tools for Windows path to you User Environment Variables (C:\Program Files (x86)\Debugging Tools for Windows (x86)\ for x64 machines, C:\Program Files\Debugging Tools for Windows (x86)\ for x86 machines)

USING UMDH TO ANALYZE PROBLEM:

5. Use gflags to turn stack tracing on:
gflags -i <name of executable, e.g. Test.exe> +ust
If you are running a standalone application that uses ArcObjects, replace arcmap.exe with the name of your executable.

6. Start your application.

7. Mark memory before executing the code you suspect is leaking memory by running UMDH:
umdh -pn:arcmap.exe -f:mark1.txt

NOTE: In some cases, the process runs start to finish with no stops for user input. In this case, you might want to add Console.ReadKey() (and a message to let you know it is waiting) around the area you suspect is leaking memory so you can take snapshots.

8. Execute the code that you suspect is leaking memory and the code that you think should release memory.

9. Mark memory again after step 8 is complete:
umdh -pn:arcmap.exe -f:mark2.txt

NOTE: Try taking a snapshot at the point the out-of-memory exception occurs.

10. Create a diff file for the two marks:
umdh -d mark1.txt mark2.txt -f:results.txt

TIP: The -d switch just outputs in decimal format rather than hexadecimal and makes it easier to read.

11. Open the text file to find something like the following:

<Lots of information about the symbol files that were loaded?
...
<Stacks for allocated memory in order from highest consumption to lowest consumption>

+ 1520000 ( 1520000 - 0) 10000 allocs BackTrace106BF720
+ 10000 ( 10000 - 0) BackTrace106BF720 allocations

ntdll!RtlAllocateHeap+00000274
MSVCR90!malloc+00000079
MSVCR90!operator new+0000001F
Geometry!ESRI::Point::Clone+0000000D
EngineGraphics!GraphicTracker::AddWithOptions+0000004D
EngineGraphics!GraphicTracker::Add+00000051
mscorwks!CLRToCOMWorker+0000019A
<no module>!???+00000000 : 3CA70A

+ 1520000 ( 1520000 - 0) 10000 allocs BackTraceB522378
+ 10000 ( 10000 - 0) BackTraceB522378 allocations

ntdll!RtlAllocateHeap+00000274
MSVCR90!malloc+00000079
MSVCR90!operator new+0000001F
Geometry!ESRI::Point::Clone+0000000D
EngineGraphics!GraphicTracker::GetGT+00000087
EngineGraphics!GraphicTracker::AddReplaceGeometryToDraw+00000102
EngineGraphics!GraphicTracker::AddWithOptions+0000019A
EngineGraphics!GraphicTracker::Add+00000051
mscorwks!CLRToCOMWorker+0000019A
<no module>!???+00000000 : 3CA70A


CLEANUP AFTER YOU'RE DONE ANALYZING:

Do the following to make sure you machine performance is optimal when you aren't debugging:

12. Use the following to turn off stack tracing when you are finished.
gflags -i arcmap.exe -ust

13. Set OANOCACHE to 0.
0 Kudos
AlexeySubbotin
Occasional Contributor
INSTALLING THE NECESSARY TOOLS:

1. Download Debugging Tools for Windows. You will likely have to download the entire Windows SDK, but you can browse the ISO for the dbg_x86.msi and just install it. Make sure and install the x86 version regardless of your machine's architecture.
http://msdn.microsoft.com/en-us/wind.../gg463009.aspx

2. Add a User Environment Variable called _NT_SYMBOL_PATH and set its value to this:
cache*C:\dev\symbols;SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\dev\symbols*http://downloads2.esri.com/Support/symbols/

This will allow you to resolve the debugging symbols you need.

3. Add a System Environment variable called OANOCACHE and set its value to 1. The disables Ole Automation caching, which is necessary to get accurate information about which calls allocated memory.

4. [OPTIONAL] Add the Debugging Tools for Windows path to you User Environment Variables (C:\Program Files (x86)\Debugging Tools for Windows (x86)\ for x64 machines, C:\Program Files\Debugging Tools for Windows (x86)\ for x86 machines)

USING UMDH TO ANALYZE PROBLEM:

5. Use gflags to turn stack tracing on:
gflags -i <name of executable, e.g. Test.exe> +ust
If you are running a standalone application that uses ArcObjects, replace arcmap.exe with the name of your executable.

6. Start your application.

7. Mark memory before executing the code you suspect is leaking memory by running UMDH:
umdh -pn:arcmap.exe -f:mark1.txt

NOTE: In some cases, the process runs start to finish with no stops for user input. In this case, you might want to add Console.ReadKey() (and a message to let you know it is waiting) around the area you suspect is leaking memory so you can take snapshots.

8. Execute the code that you suspect is leaking memory and the code that you think should release memory.

9. Mark memory again after step 8 is complete:
umdh -pn:arcmap.exe -f:mark2.txt

NOTE: Try taking a snapshot at the point the out-of-memory exception occurs.

10. Create a diff file for the two marks:
umdh -d mark1.txt mark2.txt -f:results.txt

TIP: The -d switch just outputs in decimal format rather than hexadecimal and makes it easier to read.

11. Open the text file to find something like the following:

<Lots of information about the symbol files that were loaded?
...
<Stacks for allocated memory in order from highest consumption to lowest consumption>

+ 1520000 ( 1520000 - 0) 10000 allocs BackTrace106BF720
+ 10000 ( 10000 - 0) BackTrace106BF720 allocations

ntdll!RtlAllocateHeap+00000274
MSVCR90!malloc+00000079
MSVCR90!operator new+0000001F
Geometry!ESRI::Point::Clone+0000000D
EngineGraphics!GraphicTracker::AddWithOptions+0000004D
EngineGraphics!GraphicTracker::Add+00000051
mscorwks!CLRToCOMWorker+0000019A
<no module>!???+00000000 : 3CA70A

+ 1520000 ( 1520000 - 0) 10000 allocs BackTraceB522378
+ 10000 ( 10000 - 0) BackTraceB522378 allocations

ntdll!RtlAllocateHeap+00000274
MSVCR90!malloc+00000079
MSVCR90!operator new+0000001F
Geometry!ESRI::Point::Clone+0000000D
EngineGraphics!GraphicTracker::GetGT+00000087
EngineGraphics!GraphicTracker::AddReplaceGeometryToDraw+00000102
EngineGraphics!GraphicTracker::AddWithOptions+0000019A
EngineGraphics!GraphicTracker::Add+00000051
mscorwks!CLRToCOMWorker+0000019A
<no module>!???+00000000 : 3CA70A


CLEANUP AFTER YOU'RE DONE ANALYZING:

Do the following to make sure you machine performance is optimal when you aren't debugging:

12. Use the following to turn off stack tracing when you are finished.
gflags -i arcmap.exe -ust

13. Set OANOCACHE to 0.


So, i have followed your instructions and received the results. I'm not good in such debugging, so can't to evaluate it enough.
I think you mean something about this when was talking about leaks (just one example):

+ 249397232 ( 249397232 -      0)      1 allocs BackTraceF3D0738
+       1 (      1 -      0) BackTraceF3D0738 allocations

 ntdll!RtlUlonglongByteSwap+00000B52
 MSVCR90!malloc+00000079
 FileGDB!DllRegisterServer+000053E8
 FileGDB!DllCanUnloadNow+0001C5DA
 FileGDB!???+00000000 : 69BC62F5
 FileGDB!???+00000000 : 69BC694A
 RPCRT4!NdrServerInitialize+00000240
 RPCRT4!NdrStubCall2+00000256
 ole32!WdtpInterfacePointer_UserUnmarshal+0000256F
 OLEAUT32!CreateErrorInfo+00000268
 ole32!WdtpInterfacePointer_UserUnmarshal+000025FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002B59
 ole32!CoTaskMemFree+00001B02
 ole32!CoTaskMemFree+000019F7
 ole32!DcomChannelSetHResult+000008FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002A56
 ole32!WdtpInterfacePointer_UserUnmarshal+000028CA
 ole32!WdtpInterfacePointer_UserUnmarshal+00002F86
 ole32!DcomChannelSetHResult+0000075C
 ole32!DcomChannelSetHResult+0000071B
 USER32!gapfnScSendMessage+00000332
 USER32!GetThreadDesktop+000000D7
 USER32!CharPrevW+00000138
 USER32!DispatchMessageW+0000000F
 ole32!CoWaitForMultipleHandles+00004311
 ole32!CoWaitForMultipleHandles+000023C1
 ole32!CoWaitForMultipleHandles+00004332
 ole32!CoGetTreatAsClass+00002619
 ole32!CoGetTreatAsClass+0000314B
 KERNEL32!BaseThreadInitThunk+00000012
 ntdll!RtlInitializeExceptionChain+00000063
 ntdll!RtlInitializeExceptionChain+00000036

+ 249397232 ( 249397232 -      0)      1 allocs BackTraceF3D084C
+       1 (      1 -      0) BackTraceF3D084C allocations

 ntdll!RtlUlonglongByteSwap+00000B52
 MSVCR90!malloc+00000079
 FileGDB!DllCanUnloadNow+0000BB14
 FileGDB!DllCanUnloadNow+0001C6F4
 FileGDB!???+00000000 : 69BC62F5
 FileGDB!???+00000000 : 69BC694A
 RPCRT4!NdrServerInitialize+00000240
 RPCRT4!NdrStubCall2+00000256
 ole32!WdtpInterfacePointer_UserUnmarshal+0000256F
 OLEAUT32!CreateErrorInfo+00000268
 ole32!WdtpInterfacePointer_UserUnmarshal+000025FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002B59
 ole32!CoTaskMemFree+00001B02
 ole32!CoTaskMemFree+000019F7
 ole32!DcomChannelSetHResult+000008FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002A56
 ole32!WdtpInterfacePointer_UserUnmarshal+000028CA
 ole32!WdtpInterfacePointer_UserUnmarshal+00002F86
 ole32!DcomChannelSetHResult+0000075C
 ole32!DcomChannelSetHResult+0000071B
 USER32!gapfnScSendMessage+00000332
 USER32!GetThreadDesktop+000000D7
 USER32!CharPrevW+00000138
 USER32!DispatchMessageW+0000000F
 ole32!CoWaitForMultipleHandles+00004311
 ole32!CoWaitForMultipleHandles+000023C1
 ole32!CoWaitForMultipleHandles+00004332
 ole32!CoGetTreatAsClass+00002619
 ole32!CoGetTreatAsClass+0000314B
 KERNEL32!BaseThreadInitThunk+00000012
 ntdll!RtlInitializeExceptionChain+00000063
 ntdll!RtlInitializeExceptionChain+00000036


The total result is
Total increase == 498797272 requested +   -496 overhead = 498796776


Memory was marked just before the call of the InsertFeature code line and after it in the catch code block. I used MessageBox to signal about the mark moments.

I debugged the application in different situations as the different exceptions was get, i.e. compilied against the 3.5 and 4.0 .NET Frameworks and the procedure call in current and concurrent thread. All the times memory usage was increased.

I uploaded the zip with the debug results.

http://dl.dropbox.com/u/91176632/DebugInfo.zip

They also contains lines with <no module> and the "?" signs, that is not good for me, i think.

<no module>!???+00000000 : F13103B
...
MSCTF!???+00000000 : 75931826
...
and so on


I should also note that today i tried to execute the application code from the Add-In for the ArcGlobe app and it succeeded. It makes me to think that the ESRI applications are initialized in a special way or i don't make all the necessary initialization steps in my standalone application to make it work properly. Unfortunately the ArcObjects Help does not contain any information about this.
0 Kudos
JasonPike
Frequent Contributor
So, i have followed your instructions and received the results. I'm not good in such debugging, so can't to evaluate it enough. 
I think you mean something about this when was talking about leaks (just one example): 

+ 249397232 ( 249397232 -      0)      1 allocs BackTraceF3D0738
+       1 (      1 -      0) BackTraceF3D0738 allocations

 ntdll!RtlUlonglongByteSwap+00000B52
 MSVCR90!malloc+00000079
 FileGDB!DllRegisterServer+000053E8
 FileGDB!DllCanUnloadNow+0001C5DA
 FileGDB!???+00000000 : 69BC62F5
 FileGDB!???+00000000 : 69BC694A
 RPCRT4!NdrServerInitialize+00000240
 RPCRT4!NdrStubCall2+00000256
 ole32!WdtpInterfacePointer_UserUnmarshal+0000256F
 OLEAUT32!CreateErrorInfo+00000268
 ole32!WdtpInterfacePointer_UserUnmarshal+000025FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002B59
 ole32!CoTaskMemFree+00001B02
 ole32!CoTaskMemFree+000019F7
 ole32!DcomChannelSetHResult+000008FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002A56
 ole32!WdtpInterfacePointer_UserUnmarshal+000028CA
 ole32!WdtpInterfacePointer_UserUnmarshal+00002F86
 ole32!DcomChannelSetHResult+0000075C
 ole32!DcomChannelSetHResult+0000071B
 USER32!gapfnScSendMessage+00000332
 USER32!GetThreadDesktop+000000D7
 USER32!CharPrevW+00000138
 USER32!DispatchMessageW+0000000F
 ole32!CoWaitForMultipleHandles+00004311
 ole32!CoWaitForMultipleHandles+000023C1
 ole32!CoWaitForMultipleHandles+00004332
 ole32!CoGetTreatAsClass+00002619
 ole32!CoGetTreatAsClass+0000314B
 KERNEL32!BaseThreadInitThunk+00000012
 ntdll!RtlInitializeExceptionChain+00000063
 ntdll!RtlInitializeExceptionChain+00000036

+ 249397232 ( 249397232 -      0)      1 allocs BackTraceF3D084C
+       1 (      1 -      0) BackTraceF3D084C allocations

 ntdll!RtlUlonglongByteSwap+00000B52
 MSVCR90!malloc+00000079
 FileGDB!DllCanUnloadNow+0000BB14
 FileGDB!DllCanUnloadNow+0001C6F4
 FileGDB!???+00000000 : 69BC62F5
 FileGDB!???+00000000 : 69BC694A
 RPCRT4!NdrServerInitialize+00000240
 RPCRT4!NdrStubCall2+00000256
 ole32!WdtpInterfacePointer_UserUnmarshal+0000256F
 OLEAUT32!CreateErrorInfo+00000268
 ole32!WdtpInterfacePointer_UserUnmarshal+000025FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002B59
 ole32!CoTaskMemFree+00001B02
 ole32!CoTaskMemFree+000019F7
 ole32!DcomChannelSetHResult+000008FF
 ole32!WdtpInterfacePointer_UserUnmarshal+00002A56
 ole32!WdtpInterfacePointer_UserUnmarshal+000028CA
 ole32!WdtpInterfacePointer_UserUnmarshal+00002F86
 ole32!DcomChannelSetHResult+0000075C
 ole32!DcomChannelSetHResult+0000071B
 USER32!gapfnScSendMessage+00000332
 USER32!GetThreadDesktop+000000D7
 USER32!CharPrevW+00000138
 USER32!DispatchMessageW+0000000F
 ole32!CoWaitForMultipleHandles+00004311
 ole32!CoWaitForMultipleHandles+000023C1
 ole32!CoWaitForMultipleHandles+00004332
 ole32!CoGetTreatAsClass+00002619
 ole32!CoGetTreatAsClass+0000314B
 KERNEL32!BaseThreadInitThunk+00000012
 ntdll!RtlInitializeExceptionChain+00000063
 ntdll!RtlInitializeExceptionChain+00000036


The total result is 
Total increase == 498797272 requested +   -496 overhead = 498796776


Memory was marked just before the call of the InsertFeature code line and after it in the catch code block. I used MessageBox to signal about the mark moments. 

I debugged the application in different situations as the different exceptions was get, i.e. compilied against the 3.5 and 4.0 .NET Frameworks and the procedure call in current and concurrent thread. All the times memory usage was increased. 

I uploaded the zip with the debug results.  

http://dl.dropbox.com/u/91176632/DebugInfo.zip

They also contains lines with <no module> and the "?" signs, that is not good for me, i think. 

<no module>!???+00000000 : F13103B
...
MSCTF!???+00000000 : 75931826
...
and so on


I should also note that today i tried to execute the application code from the Add-In for the ArcGlobe app and it succeeded. It makes me to think that the ESRI applications are initialized in a special way or i don't make all the necessary initialization steps in my standalone application to make it work properly. Unfortunately the ArcObjects Help does not contain any information about this.


Great job! 250MB a pop will get you to an out-of-memory exception very quickly!

The ???? mean that the symbols were unable to be resolved. You can double check to make sure _NT_SYMBOL_PATH is set correctly in your environment variables. It is possible you are behind a firewall that isn't allowing you to access the symbol servers, too. In any case, I was able see some important things without the symbol resolution.

Looking at the code and considering what you've posted (I haven't downloaded your zip from DropBox yet), I think there are two places we can release COM objects and reclaim large chunks of memory. The stacks you posted seem to indicate the majority of the memory is allocated when a GDB is opened, so we need to do one of two things: 1) Release the GDB when we're done with it, 2) reuse the GDB rather than reopening each time.

I want to try #1 first, but I've seen situations where it was impossible to get ArcCatalog to release a connection even when all the references where released.

There are two places that you have references to a GDB:

1) You open a GDB in the Import3DFiles method here:

IWorkspace datasetWorkspace = wsf.OpenFromFile(GDBFilename, 0);


Solution Part 1: Make sure to call Marshal.ReleaseComObject on "datasetWorkspace" at the end of the method

2) You assign it to the property of another COM object later in the Import3DFiles method:

IFieldChecker fieldChecker = new FieldCheckerClass();
IEnumFieldError enumFieldError = null;
IFields validatedFields = null;
fieldChecker.ValidateWorkspace = datasetWorkspace;
fieldChecker.Validate(fcFields, out enumFieldError, out validatedFields);


Solution Part 2: Make sure to call Marshal.ReleaseComObject on "fieldChecker " after the fieldChecker.Validate call.

Try these things and let me know if it reduces the amount of memory being consumed. Use UMDH as you did before and see if some of those stacks go away (you will need to make you second capture after the release statements; hopefully you won't hit the catch block again.) If this doesn't solve the problem, I have some other ideas.

Btw, are you using testFileGDB.gdb in your tests, or a different gdb? How about in the actual command? It looks like you might have a much larger GDB than the one you included in your test code.
0 Kudos
JasonPike
Frequent Contributor
I don't know if this will help you or not, but I went ahead and broke your code up into smaller pieces and added some releases.

Also, the forum made me split it into two posts...

        private static IGeometry get_MultiPatchFootprint(IMultiPatch multiPatch)
        {
            IPoint centroid = null;
            IVector3D xVector = null;
            IVector3D zVector = null;
            ITransform2D transformer3D = null;

            try
            {
                centroid = ((IArea)multiPatch).Centroid;
                centroid.Z = 0;

                xVector = new Vector3DClass();
                xVector.SetComponents(10, 0, 0);

                zVector = new Vector3DClass();
                zVector.SetComponents(0, 0, 10);

                transformer3D = (ITransform2D)((ITransform3D)multiPatch).ProjectToPlane(centroid, xVector, zVector);
                transformer3D.Move(centroid.X, centroid.Y);
            }
            finally
            {
                if (zVector != null)
                    Marshal.ReleaseComObject(zVector);

                if (xVector != null)
                    Marshal.ReleaseComObject(xVector);

                if (centroid != null)
                    Marshal.ReleaseComObject(centroid);
            }

            return (IGeometry)transformer3D;
        }

        public static void Import3DFiles(object data)
        {
            ISpatialReference datasetSpatialReference = null;
            ISpatialReference geoSpatialReference = null;
            IFeatureClass objectiveFeatureClass = null;
            IFeatureBuffer featureBuffer = null;
            IFeatureCursor featureCursor = null;

            try
            {
                GetSpatialReferences(out datasetSpatialReference, out geoSpatialReference);

                Array dataArray = (Array)data;
                string GDBFilename = dataArray.GetValue(0).ToString();
                string Dataset = dataArray.GetValue(1).ToString();

                objectiveFeatureClass = GetFeatureClass(GDBFilename, Dataset, datasetSpatialReference);
                ISchemaLock schemaLock = (ISchemaLock)objectiveFeatureClass;
                IFeatureClassLoad featureClassLoad = (IFeatureClassLoad)objectiveFeatureClass;

                schemaLock.ChangeSchemaLock(esriSchemaLock.esriExclusiveSchemaLock);
                featureClassLoad.LoadOnlyMode = true;

                featureBuffer = objectiveFeatureClass.CreateFeatureBuffer();
                featureCursor = objectiveFeatureClass.Insert(true);

                List<GeoReferencedModel> Files = dataArray.GetValue(2) as List<GeoReferencedModel>;
                foreach (GeoReferencedModel geoReferencedModel in Files)
                {
                    InsertModel(geoSpatialReference, datasetSpatialReference, featureBuffer, featureCursor, geoReferencedModel);
                }

                featureCursor.Flush();

                featureClassLoad.LoadOnlyMode = false;
                schemaLock.ChangeSchemaLock(esriSchemaLock.esriSharedSchemaLock);
            }
            finally
            {
                if (featureCursor != null)
                    Marshal.ReleaseComObject(featureCursor);

                if (featureBuffer != null)
                    Marshal.ReleaseComObject(featureBuffer);

                if (objectiveFeatureClass != null)
                    Marshal.ReleaseComObject(objectiveFeatureClass);

                if (datasetSpatialReference != null)
                    Marshal.ReleaseComObject(datasetSpatialReference);

                if (geoSpatialReference != null)
                    Marshal.ReleaseComObject(geoSpatialReference);
            }

        }

        private static void GetSpatialReferences(out ISpatialReference spatialReference, out ISpatialReference geoSR)
        {
            ISpatialReferenceFactory3 srFactory = null;
            IVerticalDatum verticalDatum = null;
            ILinearUnit unit = null;
            IVerticalCoordinateSystemEdit vcsEdit = null;

            try
            {
                srFactory = new SpatialReferenceEnvironmentClass();
                IProjectedCoordinateSystem pcs = srFactory.CreateProjectedCoordinateSystem(32639);

                spatialReference = (ISpatialReference)pcs;
                ISpatialReferenceResolution srResolution = (ISpatialReferenceResolution)spatialReference;
                srResolution.ConstructFromHorizon();
                srResolution.SetDefaultMResolution();
                srResolution.SetDefaultXYResolution();
                srResolution.SetDefaultZResolution();

                ISpatialReferenceTolerance srTolerance = (ISpatialReferenceTolerance)spatialReference;
                srTolerance.SetDefaultMTolerance();
                srTolerance.SetDefaultXYTolerance();
                srTolerance.SetDefaultZTolerance();

                verticalDatum = srFactory.CreateVerticalDatum((int)esriSRVerticalDatumType.esriSRVertDatum_SeaLevel);
                IHVDatum hvDatum = verticalDatum as IHVDatum;
                unit = srFactory.CreateUnit((int)esriSRUnitType.esriSRUnit_Meter) as ILinearUnit;
                vcsEdit = (IVerticalCoordinateSystemEdit)new VerticalCoordinateSystemClass();
                int positive = 1;
                double shift = 0;
                vcsEdit.DefineEx("", "", "", "", "", hvDatum, unit, ref shift, ref positive);
                ((ISpatialReference3)spatialReference).VerticalCoordinateSystem = (IVerticalCoordinateSystem)vcsEdit;
                ISpatialReferenceResolution sprefResolution = (ISpatialReferenceResolution)spatialReference;
                sprefResolution.SetDefaultZResolution();
                srTolerance = (ISpatialReferenceTolerance)spatialReference;
                srTolerance.SetDefaultZTolerance();
                spatialReference.Changed();

                IGeographicCoordinateSystem gcs = srFactory.CreateGeographicCoordinateSystem(4326);
                geoSR = (ISpatialReference)gcs;
                srResolution = (ISpatialReferenceResolution)geoSR;
                srResolution.ConstructFromHorizon();
                srResolution.SetDefaultMResolution();
                srResolution.SetDefaultXYResolution();
                srResolution.SetDefaultZResolution();
                srTolerance = (ISpatialReferenceTolerance)geoSR;
                srTolerance.SetDefaultMTolerance();
                srTolerance.SetDefaultXYTolerance();
                srTolerance.SetDefaultZTolerance();
            }
            finally
            {
                if (vcsEdit != null)
                    Marshal.ReleaseComObject(vcsEdit);

                if (unit != null)
                    Marshal.ReleaseComObject(unit);

                if (verticalDatum != null)
                    Marshal.ReleaseComObject(verticalDatum);

                if( srFactory != null )
                    Marshal.ReleaseComObject(srFactory);
            }
        }

        private static void InsertModel(ISpatialReference geoSR, ISpatialReference DatasetSpatialReference, IFeatureBuffer featureBuffer, IFeatureCursor featureCursor, GeoReferencedModel geoReferencedModel)
        {
            IGeometry multiPatch = null;
            IPoint placement = null;
            IGeometry footprint = null;

            try
            {
                //reading lat,long and other values values from files with own SketchUpReader (for *.skp) and ZipForge, XDocument (for *.kmz)
                //do not use any ArcObjects
                placement = geoReferencedModel.get_Placement();
                placement.SpatialReference = geoSR;
                ((IZAware)placement).ZAware = true;
                placement.Project(DatasetSpatialReference);

                //get Z value from IFunctionalSurface (relief raster)
                placement.Z = 0; //just for test

                if (!placement.Z.Equals(double.NaN))
                {
                    multiPatch = geoReferencedModel.get_MultiPatch(placement, DatasetSpatialReference);

                    if (multiPatch != null)
                    {
                        //here i compute a footprint of multipatch and store it in another featureclass 
                        footprint = get_MultiPatchFootprint((IMultiPatch)multiPatch);
                        featureBuffer.Shape = multiPatch;
                        featureCursor.InsertFeature(featureBuffer);
                    }
                }
            }
            finally
            {
                if (footprint != null)
                    Marshal.ReleaseComObject(footprint);

                if (multiPatch != null)
                    Marshal.ReleaseComObject(multiPatch);

                if (placement != null)
                    Marshal.ReleaseComObject(placement);
            }
        }
0 Kudos