Allocation profiling with mingw32 / gcc 4.5

[unilynx]

I've downloaded the newest evaluation version of AQTime, and am trying to use the allocation profiler with a mingw32-gcc compiled application (ie, under windows, but not cygwin).



I have specified -g and -gstabs as an argument to gcc. If I use the Performance profiler, I see my classes appearing in the
profile data. So apparently, it can read enough debug information there.



The application is run and I see allocations appearing in the monitor, but when pressing Get Results Now, "Classes Data" and "Objects" are empty. I think it may be confused about finding the debugging symbols. Is this combination supposed to work with AQTime? Any suggestions?

[AlexeyKolosov]

Hello Arnold,

Please disable the "View Project Classes Only" and "Filter Objects by Stack" options on the Profiler toolbar and check whether AQtime reports allocation results. Please see the "Allocation Profiler Options" article for more information about the options.

[unilynx]

Thanks, that worked, now I'm starting to get some data.



Unfortunately, I'm stuck with a bunch 'native memory' items now, and there are no callstacks. I guess that's what "If you select an unmanaged object in the Report panel, the Call Graph
and Call Tree panels will display only the selected object, without any
links to other objects." in the documentation meant.



My case is debugging a server application that seems to leak memory (specifically when using ODBC) so I hoped to be able to pinpoint any leaks of the allocations of my objects that relate to ODBC  handles. Am I correct in understanding that there's no way to do memory profiling with call statckson new-d objects, no matter what compiler, unless my objects are derived a specific object (such as TObject) ? 

[AlexeyKolosov]

Hello Arnold,

No. It looks like you faced a known problem caused by the fact that AQtime does not read line information from a GCC 4.x application's debug information. Please contact us via our Contact Support form to get a fix for the problem.