Valgrind, under Ubuntu 18.04lts goes and dies in fire (dumps core to /dev/null) when I try find where and why my K/N (kotlin/Native) cmdline app leaks mem (due companion object toRegex() 's, but not sure...). Any idea how to proceed when a robust tool goes and dies?
In most cases pure Native programs without interop or atomic references shall not leak. Good approach is to create minimal reproducer and report to JetBrains using issue tracker. As Valgrind shall not crash as well, report to Valgrind devs may help as well.
Related
Good day!
I'm playing around one C project. It is located on FreeBSD machine (it looks like Raspberry PI2, not sure)
The problem is I want to run project in Valgrind to find memory leakage. When I try to install Valgrind through ports, I get next error:
root#raspberry-2-55:/usr/ports/devel/valgrind # make
===> valgrind-3.10.1.20160113,1 is only for i386 amd64, while you are running
armv6.
*** Error code 1
Stop.
make: stopped in /usr/ports/devel/valgrind
Please help to run valgrind on this platform.
The combination ARM6/FreeBSD is not supported.
Valgrind fully supports FreeBSD i386 and amd64. You can find information on the ports here FreeBSD stable port and here FreeBSD development port.
At a guess, Valgrind support for ARM won't be implemented until and if ARM becomes a Tier 1 platform or until someone steps forward to do the porting.
See also the Valgrind team's statement on porting:
Maintaining each port takes a lot of effort, more so than for most other programs. Valgrind is fragile due to the low-level nature of what it does. Also, each platform port has CPU-specific code, OS-specific code and platform-specific code, and testing all the combinations is difficult.
Update:
On FreeBSD you can use the very powerful dtrace tool for performance monitoring and debugging. It does have a steep learning curve, though.
My favorite debugging tool is still placing printf() in strategic locations. Say you suspect your program crashes in a large block of code. Place a printf in the middle, recompile and re-run. If you see the output, the error came after the printf. If you don't it was before the printf. You have now halved the size of the block containing the error. Now add another printf in the middle of the remaining suspicious code and repeat. This technique is called bisection. You can also use it to monitor the value of a variable.
I would suggest to wrap the debugging printf in a macro ([1], [2]), so you can leave them in the code but you can disable them for a release build.
I need to be able analyzing Performance/memory issues which occurs on customer site for a OSX production application written with Objective-C.
As for now I found:
OSXPmem – it’s main drawback is that I need to dump all memory space to in to a single file(it’s not possible for me to transfer ~4GB or more from customer site - I can zip it but the bigger problem is that it not support 10.10 Yosemite.
Valgrind – Does not support 10.10 Yosemite.
Is there a good tool out there ? (such as WinDBG for windows)
BTW at development I use Instruments but in this case it does not help.
thanks for the help
Apparently valgrind will build, install, and work on osx 10.10 from the head of the development branch in the source repository, e.g. as per yosemite-and-valgrind and http://kalapun.com/posts/checking-c-code-with-valgrind-on-yosemite/
However depending on how the application works you may have more luck with the leaks command-line tool or the full-fledged Instruments tool, from Xcode. I haven't upgraded to 10.10 yet to try it there, but it should obviously still work in the latest Xcode for 10.10. leaks attaches to the running process, so is better for long-running processes that you can't shut down (cleanly), or for capturing usage metrics during specific operations.
I am working on valgrind and want to debug a program while valgrind runs over it.
But i don't want to use the in built vgdb, instead i want to use a custom gdb server.
Is there a way to plugin this custom gdbserver in the existing valgrind code.
thanks
Only by patching valgrind. The valgrind gdbserver implementation is compiled in.
I'm embedding mono in C++ application, and I'm linking it via dll library, which is then loaded into application via LoadLibrary.
When the application starts and the dll runtime linking happens, the mono runtime seems to fail to initialize itself with "Too many root sets" message. I'm unsure when and how the runtime itself is initialized (I thought it happens on mono_jit_init, but the error pops up before any call to any of the mono functions. It occurs exactly at LoadLibrary should I try load it manually instead of relying on mono.lib import library).
I succesfuly embedded it in standalone application, so I assume it is something specific to the way my dll is loaded by the application, but I don't know what exactly.
Any clues?
This may be a limitation of the way the Boehm GC works in windows: it hooks to the operating system at LoadLibrary time to get notifications of the created threads and loaded libraries (this is why you get the issue at LoadLibrary() time and not on mono_jit_init()).
Or it may be that you have really many threads and libraries loaded by the time the GC is initialized. If you link the app to mono directly, does the problem go away? If yes, that should be your current workaround.
In the future (or if building mono from git) you may be able to use the SGen GC which shouldn't suffer from this problem.
I have a problem which I have been struggling with for a while.
I have a Cocoa library which acts as a wrapper for a C++ library. C++ library is tested using a set of BOOST unit tests. The tests run normally under both debug and release modes.
In order to test the Cocoa wrapper I am using otest. Here is the strange part, the tests run normally in debug mode but fail in release mode. To make sure its not something in the code I've taken the tests content and compiled them as a separate Cocoa app which uses the wrapper code. This runs normally both under release and debug.
When otest fails I get a stack trace which makes little sense and ends with dyld_misaligned_stack_error.
Another strange thing that I've noticed is that when starting otest from a command line rather than from XCode if I point DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to the Debug version of C++ library the tests pass. I have confirmed though that all my test code is being compiled with Release flags.
Any help would be greatly appreciated!
Thank you
Try adding flag "-mstackrealign" in C flags in the release version.
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a
4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility.
See GCC's man page for reference.