i have to find out a memory leak issue on windows ce 4.0/5.0 device. Is there any tool which shows me the all the processes info, like memory, handle count... So that i can identify the culprit process.
If there are any memory leak detection tools for CE 4.0/5.0?
Thanks
http://www.vttoth.com/LPK/taskmanager.html
This is kind of old, but might still work.
The best tool, by a very long margin, for this is Entrek's CodeSnitch.
Have a look at this article. Provided that the Toolhelp32 library is available in your device, you could easily write code that enumerates processes and memory.
acbTaskMan works like a charm for me. The free version does not show per-process information, but paid version is not too expensive.
How about PocketPC Process Explorer - it's free and offers several cool features.
This one is free and works like a charm: ITaskMgr
Related
now i am dealing with the device driver coding. As the part of development, need to explore with the workqueues and work_struct.
i got only few reference for this.
html">http://www.hackchina.com/en/r/119579/jiq.c_html
The above link shows a c code jiq.c . From this not getting much idea about how the calls are flowing inside the driver code. I want to get a good idea about workqueues and work_struct .
Can anyone suggest some documents ?.
thanks in advance.
Here are a few I could get hold of -
You can start of here.
This is about the workqueue interface in Kernel 2.6 by Robert Love
This one from IBM Developer Works explains tasklets in addition to work queues and has sample examples!
I have a new Ubuntu Linux Server 64bit 10.04 LTS.
A default install of Mysql with replication turned on appears to be leaking memory.
However, we've tried going back to an earlier version and memory is still leaking but I can't tell where.
What tools/techniques can I use to pinpoint where memory is leaking so that I can rectify the problem?
Valgrind, http://valgrind.org/, can be very useful in these situations. It runs on unmodified executables but it does help tremendously if you can install the debugging symbols. Be sure to use the --show-reachable=yes flag as the leaked memory may still be reachable in some way but just not the way you want it. Also --trace-children in case of a fork. You'll likely have to track down in the start-up script where the executable is called and then add something like the following:
valgrind --show-reachable=yes --trace-children=yes --log-file=/path/to/log SQL-cmdline sqlargs
The man page has lots of other potentially useful options.
Have you tried the MySQL mailing list? Something like this would certainly be of interest to them if you can reproduce it in a straightforward manner.
You can use Valgrind as ninjalj suggests, but I doubt you'll get that close to anything useful. Even if you see a real leak (and they will be hard enough to validate), tracking down the root cause through the C call stacks will likely be very annoying (for example if the leak is triggered by a particular SQL pattern or stored procedure, you'll be looking at the call stack from the resultant optimized query, and not the original calls, which are likely in a different language).
Normally you might have no recourse, and have to resort to tracking it down through callstacks and iterative testing, but you have the source code to MySQL (including the source for the exact default package install), so you can use more advanced tools like MemoryScape (or at least build with symbols in order to provide Valgrind more food for thought).
Try using valgrind.
A very good and powerful tool, which is installed/available for most distributions is Valgrind.
It has a plethora of different options and is pretty much (as far as I've seen) the default profiler under linux systems.
I've used two profiling tools (VTune on windows and dbx (within sunstudio) on Solaris) which can profile program without rebuild them, and during profiling, the program just run at the same speed as normal. Both of these 2 features saved me a lot of time.
Now I want to know if there is some free tools available on Linux platform can do the same thing. I think I need profiling tools based on sampling. VTune is good but expensive ... I've heard of gprof and valgrind. But seems gprof need instrument the program (so we have to rebuild the program) and valgrind will slow down the program execution quite a lot. (from valgrind's introduction, Cachegrind runs programs about 20--100x slower than normal, and Callgrind which I need to profiling is based on Cachegrind)
For profiling, I just need to figure out the execution time of function calls so I can find out where the performance degradation happens. Actually I don't need many low level profiling information as Cachegrind provided...
oprofile is pretty good, but it can be difficult to set up. It also doesn't require you to rebuild your program.
Agreeing with Paul, I think Zoom is probably the best Linux profiler you can pay for.
However, for real results, I rely on this simple method, that I've been using since before profilers were invented.
Performance Counters for Linux is a new tool usable on kernels 2.6.31 and later; it's less intrusive (to both the program and the system as a whole) than valgrind or OProfile.
A nicer option than oprofile is Zoom. It's similar to Shark on Mac OS X, if you have ever used that. It's commercial ($199) but you can get a free trial from www.rotateright.com.
Shark on Mac OS X is a great tool for profiling an application on a running system. Is there any similar tools for Linux?
OProfile looks like it could be, anyone used it?
Extending another answer, I use the 'callgrind' option of valgrind (http://valgrind.org). Then install kcachegrind from KDE for a nice GUI interface.
As a dummy's tutorial, do:
1) Compile your application with debugging information. It's a good idea to try profiling with optimization both on and off, with optimization off you will get more information, but it may be less accurate (in particular tiny functions will seem to take up more time than they deserve.
2) Run with:
valgrind --tool=callgrind <name of your app> <your app's options>
This should produce a file called 'callgrind.something', which you can load into kcachegrind.
You can also look at:
valgrind --tool=cachegrind <name of your app> <your app's options>
Which will give you information about how your app is interacting with your CPU's cache.
Note that while valgrind and shark seem like similar apps, they work very differently. When you run an app in valgrind it will run many times slower than normal (often over 40 times slower), but the results you get are much more accurate than shark's. I tend to use both, so I can get as much information as possible!
You can probably try Valgrind (http://valgrind.org/). They have both runtime and compile time profiling tools.
A bit late to answer this one, but the closest answer is Zoom. Some of the Shark team worked on it.
OProfile is a tool that does sampling-based profiling of both your application and the system calls it makes. This allows for seeing detailed information about where it's spending time. It doesn't have a GUI, but there are several front-ends that will let you process the information from the runs.
I've used it extensively, both for desktop applications and for embedded systems. It takes a little effort to interpret the results, but the callgraph output is really useful here.
Here's a link to Windows documentation.
Basically I would like to get similar data, but on Linux. If not all is possible, then at least some parts.
If you enable CONFIG\_TASK\_IO\_ACCOUNTING, you will have the information available in /proc/<pid>/io. This is available since kernel 2.6.20, but not normally enabled by default (However, in Ubuntu 8.04 it seems like it is enabled).
You can read about the various data items in Documentation/filesystems/proc.txt in the kernel source tree. Especially section 2.14 should be of interest.
Have a look at /proc/PID/io - it's the current I/O accounting information of the process with PID.
Look at the pseudo-files under /proc/<PID>/. Maybe you can find what you need there.
Look at man 5 proc, or failing that the kernel documentation. However, I don't see much that looks promising. Sorry.
Perhaps you want getrusage()? Not all fields are maintained under linux however. Perhaps enabling the CONFIG_TASK_IO_ACCOUNTING will cause them to be maintained?