I am trying to obtain the memory working set value for a given PID in my C++ application running on LINUX. In Windows I can get this info using GetProcessWorkingSetSize function. Is there anything like this function I can call in LINUX?
The only sensible solution that comes to mind is accessing the relevant information via the /proc filesystem. It seems weird that a process would have to read out its own information from /proc, though, but I don't know about any other system calls that might make this easier.
The information you're probably most interested in is located in /proc/[pid]/statm, which includes :
total program size,
resident set size,
shared pages,
text (code) size,
library (unused in Linux 2.6),
data and stack size,
dirty pages (unused in Linux 2.6).
Keep in mind that all those measurements are given in the number of pages.
Related
In Linux, I need to get the details(viz. service exit code,status,type,etc) of all the driver modules and I tried reading /proc/modules. But it gives only name, size and use count. I read that modinfo retrieves info from lib/modules/,but all modules doesn't have all info in it. From where can I get these details reliably. I am coding in C++.
Kernel modules are handled by struct module. You may write a module to get that information from in-kernel (and provide it in another /proc file) or use a debugger to read raw kernel memory from /proc/kcore .
But, the information Linux keeps per-module doesn't fit your needs:
service exit code is not saved by kernel but immediately returned to init_module() caller as error number (i.e. modprobe or insmod tools)
status -- there is no such thing. Closest is state, but it transitional and only used during loading
type -- Linux doesn't distinguish module types
Generally speaking, you cannot get that details from Linux. The most useful information is already provided in /proc/modules.
What are the best methods to reduce a core dump's size?
My problem is that I have very little space dedicated to the purpose on my Linux Mint. I have around 200 MB which is far not enough for my program to generate a decent dump. I have tried configuring the coredump filter, but only the anonymous private mappings dump made any significant change in the size, but it also made my dump unreadable. I also tried to limit the size with ulimit, but the only result was that dump was truncated every single time.
My question is that what is the best way to control the core dump's size?
Is there any way to keep only maybe the top 10-15 frames of a dump? Also what is the use of setting the size limit with ulimit, if it only generates useless core files?
Consider using Breakpad: https://code.google.com/p/google-breakpad/
https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad :
Breakpad is a library and tool suite that allows you to distribute an
application to users with compiler-provided debugging information
removed, record crashes in compact "minidump" files, send them back to
your server, and produce C and C++ stack traces from these minidumps.
Breakpad can also write minidumps on request for programs that have
not crashed.
It appears that there are several related answers here on StackOverflow:
Minimal core dump (stack trace + current frame only)
This link suggests setting up a signal handler for SIGSEGV and dumping core in your own way.
and
Linux core dumps are too large!
This link suggests using setrlimit to limit the size of the dump.
I need to read information, code, flags, address, etc from a memory.dmp file generated from a windows BSOD through C++. The basic idea is that status info can be requested from a remote site and one of the requested pieces of information is some basic info from the last BSOD that occured on the machine thus I need to open the kernel/memory dump file through C++ (Im using MSVC 2005).
Start here, then realize using scripted commands in WinDBG is much easier.
Note: you only need WinDBG on the analysis machine, not the crashing one. You retrieve the minidump and analyse it externally. The only difficulty you will have is getting the right symbols - for Windows, Microsoft makes them available via their symbol servers, but applications that caused the crash may not supply the right symbols you need. IF they are you own applications causing the crash, get a symbol server and use it.
I would configure Windows to create small kernel memory dumps which will include the parameter of the bugcheck you are after.
On XP it was 64KB on my Win8.1 x64 it is 256KB. These files compress well. You should be able to get away with a zip file of 10-60KB size depending on the bitness of the OS. If bandwidth is of of utmost importance to you, you can use 7z which compresses about 50% better than the plain zip algo at the expense of much longer compression times (5-6 longer) but for such small files the CPU time difference should be irrelevant.
If you do not want your users to configure dump reporting you need to set the DWORD
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
to 3 for a small kernel dump programatically.
For an explanation of the values see http://technet.microsoft.com/en-us/library/cc976050.aspx
0 Debugging information is not written to a file.
1 Complete crash dump is written to a file.
2 Kernel memory dump is written to a file.
3 Small memory dump is written to a file.
You will then get by default a small kernel dump in %SystemRoot%\MEMORY.DMP.
I have an application (didn't write it) that is producing APPCRASH dumps in C:\Windows\SysWOW64. The application while dumping is crippled, but operating at bare minimum capacity to not lose data. The issue is that these dumps are so large that the system is spending most of it's time writing these and the application is falling far behind in processing and will start losing data soon.
The plan is to either entirely disable it, or mount it to a RAM drive and purge them as soon as they hit the RAM drive.
Now I've looked into using this key:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx
But all it does is generate a second dump now instead of redirect the original.
The dump is named:
dump-2013_03_31-15_23_55_772.dmp
This is generally the realm of developers on Windows (with stuff like C/C++) so I'd like to hit them up, don't think ServerFault could get me any answers on this.
Additionally: It's not cycling dump files (they'll fill the 20GBs left on the hard drive), so I'm not sure if this is Windows behavior or custom code in the app (if it is... ick!).
To write a DumpFile, an app has to call the function "MiniDumpWriteDump" so this is not a behavior of the system or something you can control, it is application driven. If it dumps on crashes, it uses "SetUnhandledExceptionFilter" to set its own handling routine, before(!) the OS takes over. Unfortunately I didn't found a way to overwrite this handler from an other process, so the only hope left is, that there is a register entry for the app switching the behavior or change the path (as my applications have it for exactly the reason you describe).
I want to write a program like system monitor.
I want to have a list of programs with their process ID and usage of CPU and RAM.
I know Linux writes this information in the /proc folder but somebody told me that I can use some functions to get it too. For example a program that will return a list like:
name PID RAM
sh 3904 72KIB
And I want to code in C++.
Why don't you look at the source code for top, which displays these and many more process statistics?
Here is the busybox version, which is comparatively short and simple. It gets the information by reading the proc filesystem, that logic is here.