Flash Builder Profiler runs out of java heap space trying to expand paths to GCRoot - flash-builder

Using Flash Builder 4 on Mac OS X, trying to debug why it seems our Air app is leaking the objects declared in the MXML files, but if I try to expand the Instance in the Object Reference tab of the profiler, it runs for several minutes before throwing a java heap space error.
The heap is already set at -Xmx1024m, setting it to 2048m causes FB to not start at all.

It seems the trick is that you can have either the Allocation Stack or the Path to GCRoot.
Thank you Adobe for inventing the Heisenberg Uncertainty Profiler.

Related

VB Visual Studio 2017: Error Managed Debugging Assistant 'DisconnectedContext'

I got the "Managed Debugging Assistant 'DisconnectedContext' " error.
Managed Debugging Assistant 'DisconnectedContext'
Message=Managed Debugging Assistant 'DisconnectedContext' : 'Transition into COM context 0xfc94b0 for this RuntimeCallableWrapper failed with the following error: System call failed. (Exception from HRESULT: 0x80010100 (RPC_E_SYS_CALL_FAILED)). This is typically because the COM context 0xfc94b0 where this RuntimeCallableWrapper was created has been disconnected or it is busy doing something else. Releasing the interfaces from the current COM context (COM context 0xfc9568). This may cause corruption or data loss. To avoid this problem, please ensure that all COM contexts/apartments/threads stay alive and are available for context transition, until the application is completely done with the RuntimeCallableWrappers that represents COM components that live inside them.
Blockquote
The program is reading and analyzing about 200 large excel files, generating one output large excel file. So far I was using it on a smaller amount of files, so perhaps it has to do something with larger memory usage. On the other hand the machines I use have 16GB of RAM. While n run time it doesn't look like memory leak. I don't use pointers, or dynamic memory allocations - simply open files, read, write and close.
While I read I can disable the "'DisconnectedContext' " I prefer to understand how to locate the problem and fix it.
The problem occurs on two separated machines.
How can I debug it?
Where to start?
Thank you

Out of memory exception in executable but not debug mode (or in release mode run through VS)

I am running a program in VB.NET, with VS 2013, in 64-bit architecture, and have enabled allowverylargeobjects.
I have a list of objects of a class. The class has various properties that are data, kind of like
Class cMyClass
Property desc1 as String
Property desc2 as String
Property value as Double
End Class
I am populating this list via a read from SQL server. I can successfully put, in debug or release mode, 100 million objects of this class in the list, and operate on them just fine. At one point, though, I am populating the list with 150 million objects. When I run the program through Visual Studio in debug mode (or even in release mode, but through VS), I have no problems populating the list with 150 million objects. But when I use an executable (compiled from release mode), it throws an error at this point (the error box tells me it is in a particular subroutine where the only thing happening is the filling of this list) - "exceededSystem.OutOfMemoryException: Array dimensions exceeded supported range."
I get that it's bad practice to load so much stuff into memory, but I am already very far down this road and need to solve it just once. I can solve it, clearly, by running the program through VS, but would like to understand why this works for me in VS (in debug mode or release mode) but not when running the executable.
I'll add that I don't think it's a hardware problem. The program is using over 20gb memory when running, but it's running on a box with 128gb RAM.
Thank you.
Enable gcAllowVeryLargeObjects in your exe.config file (https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcallowverylargeobjects-element)
Even when this is active, you still have a limit on the number of elements:
4,294,967,295 in a multi-dimensional array
2,146,435,071 in a single dimensional array
2,147,483,591 for single byte arrays
Note that as stated in the comment from Tycobb, the gcAllowVeryLargeObjects works at object level, not at process level - so your process might use 20 gbs of RAM that are made up by the sum of many objects < 2 GB.

Xcode: Determine caller of function in xcode in debug

How can I determine where some function called in debug state? I'm in stuck with EXC_I386_GPFLT error hence I do not expect invocation such function with my test case.
You can try new Xcode 7 feature called Address Sanitizer.
In Xcode go to Product -> Scheme -> Edit Scheme, select Run, open Diagnostics tab and check Enable Address Sanitizer.
Then Product -> Clean project and run it again.
Objective-C and C code is susceptible to memory corruption issues such
as stack and heap buffer overruns and use-after-free issues. When
these memory violations occur, your app can crash unpredictably or
display odd behavior. Memory corruption issues are difficult to track
down because the crashes and odd behavior are often hard to reproduce,
and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled,
added instrumentation is built into the app to catch memory violations
immediately, enabling you to inspect the problem right at the place
where it occurs. Other diagnostic information is provided as well,
such as the relationship between the faulty address and a valid object
on the heap and allocation/deallocation information, which helps you
pinpoint and fix the problem quickly. The address sanitizer is
efficient—fast enough to be used regularly as well as with interactive
applications. It is supported in OS X, in the Simulator, and on iOS
devices.
New features in Xcode 7

How to get crash/hangs reports for applications, daemons and OSX programatically?

I know there is a way to get crashes and hangs for all applications. These files are placed in "/Users/user/Library/Logs/DiagnosticReports". So I could get version, time and name of the app.
But how to get daemon/process crashes and hangs? I need to know which exactly daemon was crashed/hanged and time when it happened.
Also is there is a way to get some system(OSX) crash with the same info?
Also would be great to get some resource failures/warnings: out of memory or out of disk space.
I need to get it programatically.
On Windows we can do this using NotifyChangeEventLog () API. All these info we can gather using such method. Also it notifies if something happened.
For the daemons crash/hang report see the "/Library/Logs/DiagnosticReports" directory. According to this document you can also find there kernel panic reports (i.e. system crash).
Don't know about NotifyChangeEventLog-like API, but in situations like "out of memory" there will be an exception, so you just need to catch it. See Error Handling Programming Guide for details. Also take a look at Exception Programming Topics
Edit: for the information about Crash Reporter take a look at Chapter 5 of Levin's book "Mac OS X and iOS Internals: To the Apple's Core"
in 10.9 the activity monitor offers you two tools when you have a hang but no crash hence no crash report:
spindump - memory dump like crash report and
sys digs which produces a bundle of files

Contents of a programs memory (Mac)

Is there a utility that will show me a program's current memory contents? Like a hex dump of the entire memory being used by the program? Thanks.
My utility, Bit Slicer, which runs on 10.6 or later can do this for regular applications.
1) Run the program and select a target process.
2) Go to Tools -> Dump All Memory... This will save all the current readable memory in a directory with a bunch of files each indicating a particular memory region and a file that merges everything as well. These files can then be viewed with a hex editor.
3) There's also the real-time memory viewer in the Memory menu for looking at a particular spot.
Dmalloc - Debug Malloc Library
This program came with OS 10.6 but it seems to have disappeared with OS 10.7 (which has many, many, many ... programming complications). Excluding 10.7 regrets, Dmalloc is wonderful way to examine every memory allocation.
Ah ha...
Mac OS 10.7 provides Menu-Product-Profile. I have not investigated fully used it, however, I recognize the Dmalloc icon within it.