Valgrind hasn't worked for me on macOS since 10.11 or 10.10, can't recall.
>From my observations, there are no interested and / or qualified people to fix >the mac port, and it's an ever moving target because of kernel changes with >each released version. I've submitted a patch and it took around six months to get it merged. Bug issues seem to be triaged, and the occasional external contributor comes in with fixes, but from my point of view, it has not been enough to get it to a workable state. Depending on what I'm trying to do, I resort to using 1) malloc debug https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html 2) Instruments 3) Address sanitizer 4) dtrace Instruments has a "Leaks" profile, which provides statistics for on allocations, stack traces, etc. You might want to give it a try. ________________________________ From: Interest <interest-bounces+alexandru.croitor=qt...@qt-project.org> on behalf of Elvis Stansvik <elvst...@gmail.com> Sent: Monday, October 22, 2018 6:26:17 PM To: Nuno Santos Cc: interest@qt-project.org Interest Subject: Re: [Interest] How to inspect a Qt Application memory usage? Den mån 22 okt. 2018 kl 18:04 skrev Nuno Santos <nunosan...@imaginando.pt>: > > Elvis, > > I have just tried that it resulted in this. I’m not familiar with valgrind > output. Does this look good to you? > > > --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option > --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 > times) > --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 > times) > --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 > times) > QML debugging is enabled. Only use this in a safe environment. > ==45024== > ==45024== Process terminating with default action of signal 11 (SIGSEGV) > ==45024== Access not within mapped region at address 0x18 > ==45024== at 0x1077D6E3A: _pthread_wqthread (in > /usr/lib/system/libsystem_pthread.dylib) > ==45024== by 0x1077D6BE8: start_wqthread (in > /usr/lib/system/libsystem_pthread.dylib) > ==45024== If you believe this happened as a result of a stack > ==45024== overflow in your program's main thread (unlikely but > ==45024== possible), you can try to increase the size of the > ==45024== main thread stack using the --main-stacksize= flag. > ==45024== The main thread stack size used in this run was 8388608. > --45024:0:schedule VG_(sema_down): read returned -4 > ==45024== > [1] 45024 segmentation fault valgrind --tool=massif XPTO.app Hm, I'm not too familiar with valgrind output, but that looks like the application crashed due to an access violation. Perhaps you should run it in a memory error checker first to make pinpoint the violation? Valgrind has one called memcheck (--tool=memcheck). Elvis > > Thx! > > Nuno > > On 22 Oct 2018, at 16:54, Elvis Stansvik <elvst...@gmail.com> wrote: > > I used valgrind with valgrind --tool=massif myApp to track down a memory > issue just today actually, and it worked out great, but I don't know if it > works on macOS (this was on Linux). I used massif-visualizer for > visualization. > > I've been meaning to check out heaptrack but haven't gotten around to it. > > Elvis > > Den mån 22 okt. 2018 16:50Nuno Santos <nunosan...@imaginando.pt> skrev: >> >> Hi, >> >> What tool(s) do you people suggest in order to investigate where is the >> memory being spent on a Qt application? >> >> Thanks! >> >> Nuno >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest > > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
