I'm using XCode to develop a C command line utility and I'm attempting to using XCode's profiling capabilities to track program allocations and possibly memory leaks. I can attach an allocation tracker utility just fine to the program itself and it works, the problem is I cannot interact with the program from this point and it's just stuck in its initialized and waiting state (the program is definitely running in the background somewhere I just cannot get to it). I've tried tweaking various settings to no avail, any ideas would be greatly appreciated, thanks.
If you launch Instruments outside of Xcode, you should be able to use the pull-down list above 'Target' and 'Attach to Process' to profile any already-running program. So one option — given that the way you describe your program makes it sound interactive — is to launch your utility in a terminal then to attach Instruments to it.
E.g. vi isn't symbolicated but running Instruments against it has just revealed that when in insert mode, it spends about 14% of its time in write and 4.5% in strcmp (albeit that with something like vi the processing is so minuscule that there's bound to be sampling error in there).
Related
I'm running a headless aarch64 based embedded linux system. on this system there is a main program running which is a compiled bit o C code. However I would like to be able to monitor this program while it continues doing its thing.
During my education I worked with the XCP-protocol to monitor systems and adjust them on the fly. But that is hands on, I would like to automate it with python or javascript so I can handle the data for other purposes.
So in short, there's a compiled bit of C-code running on a Linux system and I want to be able to see the value of its variables with something like javascript or python.
I did some testing with GDB but that seems to pause the execution of the program which can't happen, maybe only for a quick bit when its starting but not after.
I've found this previous post:
How can you debug a process using gdb without pausing it?
However when i type continue after setting all of the related settings that I could find, it doesnt let me look up the value of a variable anymore using a command like p .
I am working on VxWorks target board. I want to make sure that my application or driver does not have any memory leak.
Is there any specific way so that I can check memory leak at run time
or without running the application?
You need MemScope provided by Wind River which is compatible with vxworks also refer http://borkhuis.home.xs4all.nl/vxworks/vxw_pt6.html#6.2
Although it is inaccurate you can use the memShow command on the VxWorks shell.
To check for memory leaks do a "base line" after your application has started. Then run your tests or stimulate your application or simply let it run for a few hours. After that check the outputs of memShow again. If the values have changed "dramatically" you have a problem.
Notes:
This is very basic and just helps you to know that you actually have a memory leak. It does not show you which thread, or function...
Remeber that this function shows the total available memory (not only to your application). So some changes are normal due to VxWorks operating...
I was wondering if there is any way of compiling a program (my own program, or an open source program), with which I can follow the flow of that program when I execute it. Ideally, I would like to output the specific methods which the program goes through when it executes. Each time it calls a specific method, I would like to output that it has done so, which I would like to save to a file for later analysis.
For example, I am trying to better understand the flow within KVM (an open source hypervisor) but there are obviously many lines of code, and would be impossible for me to know where the code goes unless I dedicated possibly weeks to finding out.
The code I am looking at is written mostly in C, but also uses other languages. Any ideas please?
KVM is a subsystem of Linux kernel, so you should use ftrace (http://lwn.net/Articles/322666/) for tracing kernel-space code.
I'm trying to debug a simple cross-platform commandline program (a C parser, itself written in C) and running into something strange.
On Windows, when I run it on a small dataset (the source code of glib) it completes successfully, and when I run it on a large dataset (the source code of the Linux kernel) it exits with an out of memory error. I'm not sure whether the latter is a bug in my code or just a consequence of not just having optimized the memory consumption yet, so I've been trying to run it on Linux so I can get some feedback from valgrind.
On Linux (Ubuntu 11.04 x64 in VirtualBox), when I run my program on a small dataset it completes successfully, and when I run it on a large dataset Linux locks up hard enough I have to reset the entire virtual box (mouse pointer still moves but other than that it's completely unresponsive; Windows task manager says the virtual box is using one hundred percent of a CPU core but not allocating memory).
I wouldn't have expected a bug in my code to crash Linux unless I was writing something like a device driver, and when I try simple test cases that allocate too much memory, go into an infinite loop or both, Linux can handle them just fine. What kind of bug should I be looking for, or what am I missing?
On Linux (Ubuntu 11.04 x64 in VirtualBox)
Probably you haven't reserved enough memory to your virtual machine.
This is most likely an infinite loop (easily done in a parser), which could easily take up 100% cpu or 100% ram.
Attach a debugger!
e.g. gdb
http://www.gnu.org/s/gdb/
gdb comes with gcc on Ubuntu etc...
Here's a how-to: http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
EDIT: just saw you already tried gdb. So, try running strace on it, it might give you a hint.
Further to that, try adding log messages to see how far the program gets (primitive, but it'll work eventually!)
HI, i am recently in a project in linux written in C.
This app has several processes and they share a block of shared memory...When the app run for about several hrs, a process collapsed without any footprints so it's very diffficult to know what the problem was or where i can start to review the codes....
well, it could be memory overflown or pointer malused...but i dunno exactly...
Do you have any tools or any methods to detect the problems...
It will very appreciated if it get resolved. thanx for your advice...
Before you start the program, enable core dumps:
ulimit -c unlimited
(and make sure the working directory of the process is writeable by the process)
After the process crashes, it should leave behind a core file, which you can then examine with gdb:
gdb /some/bin/executable core
Alternatively, you can run the process under gdb when you start it - gdb will wake up when the process crashes.
You could also run gdb in gdb-many-windows if you are running emacs. which give you better debugging options that lets you examine things like the stack, etc. This is much like Visual Studio IDE.
Here is a useful link
http://emacs-fu.blogspot.com/2009/02/fancy-debugging-with-gdb.html
Valgrind is where you need to go next. Chances are that you have a memory misuse problem which is benign -- until it isn't. Run the programs under valgrind and see what it says.
I agree with bmargulies -- Valgrind is absolutely the best tool out there to automatically detect incorrect memory usage. Almost all Linux distributions should have it, so just emerge valgrind or apt-get install valgrind or whatever your distro uses.
However, Valgrind is hardly the least cryptic thing in existence, and it usually only helps you tell where the program eventually ended up accessing memory incorrectly -- if you stored an incorrect array index in a variable and then accessed it later, then you will still have to figure that out. Especially when paired with a powerful debugger like GDB, however (the backtrace or bt command is your friend), Valgrind is an incredibly useful tool.
Just remember to compile with the -g flag (if you are using GCC, at least), or Valgrind and GDB will not be able to tell you where in the source the memory abuse occurred.