We have an application software running on Suse linux. What I want is that whenever there is a crash/fault in the software, a backtrace is generated with call stack information for the current thread(which faults).
We are currently using "backtrace()" and "backtrace_symbols_fd()" to try to get the trace but there is not much useful information. It does not give function names, line no. and filename.
Therefore, I starting looking for alternate options to use and found "libunwind". Wrote a small function to get backtrace and it does print function name with other register values(ip,sp). But still I can not get the filename and linenumbers. Is there a way I can programmatically do that ? What happens if I strip my binary file? Can I still get the filename/lineno info ?
Related
I want to know how does the DIG (Domain Information Groper) command really works when it comes to code and implementation. I mean when we enter a DIG command, which part of the code in FreeBSD or BIND hits first.
Currently, I see that when I hit the DIG command, I see the control going to a file client.c. Inside this file, following function is called:
static void
client_request(isc_task_t *task, isc_event_t *event);
But how does the control reach to this place is still a big mystery for me even after digging a lot into 'named' part of the BIND code.
Further, I see this function being called from two places within this file. I tried to put logs into such places to know if control reaches to this place through those paths, but unfortunately that doesn't happen. It seems "Client_request()" function is somehow being called from outside somewhere that I am not able to figure out.
Is there anybody here who can help me out to resolve this mystery for me ?
Thanks.
Not only for bind but to any other command, within FreeBSD you could use ktrace, it is very verbose but could help you to get a quick overview of how the program is behaving.
For example, in latest FreeBSD's you have drill command instead of dig so if you would like to know what is happening behind scenes when you run the command, you could give a try to:
# ktrace drill freebsd.org
Then to disable tracing:
# ktrace -C
Once tracing is enabled on a process, trace data will be logged until
either the process exits or the trace point is cleared. A traced process
can generate enormous amounts of log data quickly; It is strongly
suggested that users memorize how to disable tracing before attempting to
trace a process.
After running ktrace drill freebsd.org a file ktrace.out should be created the one you could read with kdump, for example:
# kdump -f ktrace.out | less
That will hopefully "reveal the mystery", in your case, just replace drill with dig and then use something like:
# ktrace dig freebsd.org
Thanks to FreeBSD Ports system you can compile your own BIND with debugging enabled. To do so run
cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1
Then you can run it inside debugger (lldb /usr/local/bin/dig), break on the line you are interested in and then look at backtrace to figure out how the control reached there.
I am using a command in the proc file system which is the following
echo 0 > /proc/sys/net/ipv4/ip_forward
Note: I don't want to know the basic of the command written above, I want what all happens when it goes inside the kernel. As, I want to implement one of the /proc file.
Now if I want to trace the code right from when the 0 is echoed in the file-system then how to go about it. I mean if I want to trace what happens when I do this.
I want to see where in the kernel code this 0 is accepted and in which value does it get stored inorder to make the changes. Please, can somebody tell what all happens when you call this command. I want in detail explain. I don't want the description of the command.
Any related article on how it changes the kernel parameters is also fine.
I have read this but, not explained there. http://www.linuxjournal.com/article/8381
Thanks
search through linux tree (especially network stack) for create_proc_entry function. Figure out what file creates ip_forward (it must be in ip4v drivers) from name passed to create_proc_entry.
When you find the file, look at where proc_dir_entry structure is created and what functions are assigned to its read_proc, write_proc members.
I am new to FSL, using version 4.1.8. I am trying to run a script that reads and generates *.nii files, which format is normally supported by FSL. I am calling an FSL function, probtrackx from within Matlab. However, I get the following error message seemingly unable to generate or recognize *.nii files:
** ERROR (nifti_image_read): failed to find header file for '~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001'
** ERROR: nifti_image_open(~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001): bad header info
ERROR: failed to open file ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001
ERROR: Could not open image ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001
The files do exist but FSL fails to recognize them. Any help as to how to correct the issue and get FSL to work properly would be most appreciated. I suspect it's a Linux settings issue, just not sure how to fix it. A solution to a related problem in a previous posting suggested adding ls='ls --color=auto'. I've tried it to on avail.
Some FSL tools assume that the $FSLDIR unix unvironment variable is set, which might not be the case in your MATLAB environment. You can fix that with something like setenv('FSLDIR', '/usr/local/fsl') (modified of course if your FSL installation is in a different place). Some also need the regular FSL setup script to be executed as well: system('. ${FSLDIR}/etc/fslconf/fsl.sh'). See also: http://www.fmrib.ox.ac.uk/fsl/fsl/downloading.html.
Instead of the more complicated probtrackx script, another thing to try first is simply:
system('fslhd ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001')
If this fails with the same error, then you know that you entered the path to the data incorrectly. For example, do you mean to have the .. in there?
Also, in the future, the best place to get FSL support is on their mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=fsl
Does MATLAB have access to run other fsl commands? If you are able to run a command from the command line but not through MATLAB, the MATLAB user may not have access to run fsl or may be looking for some FSL variables.
You might have to do the equivalent of this for a linux system
I am using visual studio 2008 and MFC. I accept arguments using a subclass of CCommandLineInfo and overriding ParseParam().
Now I want to pass these arguments to the application while running. For example "test.exe /start" and then to type in the console "test.exe /initialize" to be initialized again.
is there any way to do that?
Edit 1: Some clarifications. My program starts with "test.exe /start". I want to type "test.exe /initialize" and initialize the one and only running process (without closing/opening). And by initialize I mean to read a different XML file, to change some values of the interface and other things.
I cannot think of an easy way to accomplish what you're asking about.
However, you could develop your application to specifically receive commands, and given those commands take any actions you wanted based upon receiving them. Since you're already using MFC, you can do this rather easily. Create a Window (HWND) for your application and register it. It doesn't have to be visible (this won't necessarily make you application a GUI application). Implement a WndProc, and define specific messages that you will receive based on WM_USER + <xxx>.
First and obvious question is why you want to have threads, instead of processes.
You may use GetCommandLine and CommandLineToArgvW to get the fully formatted command line. Detect the arguments, and the call CreateProcess or ShellExecute passing /watever to spawn the process. You may also want to use GetModuleBaseName to get the name of your own EXE.
I am trying to get some information about the flow of a large program. KCachegrind used to be great for this in the past. But the latest version (0.6kde) I have on my system (Kubuntu 10.10) won't display the call tree and caller map. It only draws a box with the current function, but no arrows and no callers. Here's the console output:
kcachegrind(27917)/kdecore (services) KMimeTypeFactory::parseMagic: Now parsing "/usr/share/mime/magic"
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/cosmin/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
CallGraphView::refresh
CallGraphView::refresh: Started process 0x1346f50, 'dot -Tplain'
CallGraphView::readDotOutput: QProcess 0x1346f50
CallGraphView::dotExited: QProcess 0x1346f50
I have dot (graphviz) installed, and the application was compiled with -g -O0.
Do you have any idea where the problem could be?
Oops... I was calling valgrind --tool=cachegrind instead of valgrind --tool=callgrind.