I need to profile my c++ application which starts with spawn-fcgi.
I tried to use callgrind but callgrind output in KCachegrind is not showing any information of my applications.
valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes --demangle=no --trace-children=yes --callgrind-out-file=%p spawn-fcgi -s /tmp/sock.tmp ./myApp arg1 arg2
This command creates two files 10012 and 10013, but second file is empty.
First file have function informations for location spawn-fcgi, ld-2.*.so amd libc.
Please suggest correct option to get profiling information for my application.
I experienced similar behaviour when profiled fastcgi process crashed on exit (so statistics isn't dumped on termination with SIGSEGV).
I used callgrind_control tool to dump statistics at arbitrary point of time:
callgrind_control --dump
Also you can stop gathering statistics with callgrind_control -i off, reenable with callgrind_control -i on, reset with callgrind_control -z.
See callgrind_control manual for details http://valgrind.org/docs/manual/cl-manual.html .
Related
I try to have separate ssp modes during connection using Bluetooth btmgmt utility. Basic idea is scan current device OUI and select ssp on/off modes. But I can't get any answer from neither btmgmt con or btmgmt info commands when I put them into .service files. My system is Arch Linux arm 32-bit and bluez stack version is 5.55-1. I tried
[Unit]
Description=check Bluetooth address
[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c '/usr/bin/btmgmt info >> /usr/local/lib/mac 2>&1'
without any success: it just puts nothing in output file. Some tricks like add
User=root
Group=root
or substitute ExecStart with
ExecStart=/bin/bash -c 'echo -e "$(btmgmt con)" >> /usr/local/lib/mac 2>&1
did nothing. I tried changed thing by putting btmgmt stuff in different bash script instead of start them right from service file, i.e.
ExecStart=/usr/local/lib/test1
to no avail. I'm confused completely, because of:
It doesn't seem to be general btmgmt thing problem, because I can set ssp mode from service files
in very simple manner, just using
ExecStart=btmgmt off
or
ExecStart=btmgmt off
even without full path.
It doesn't seem to be redirecting command error as well, because if I add
ExecStartPre=/usr/bin/bash -c '/usr/bin/fdisk -l > /usr/local/lib/mac 2>&1'
it does work without any problem and I see fdisk info in file (I use fdisk because it requires elevated rights same as btmgmt one).
Moreover, btmgmt info works in the same way, i.e. shows nothing in out file. It makes me think something is wrong in output of btmgmt. I talk about output because input parameters work fine in btmgmt ssp on/of commands and journalctl and systemct don't show any errors in btmgmt con/info cases, so it seems to like output generating successfully but then sending somewhere to outer space, but I'm not sure completely.
Thanks for any help in advance
Well, I make a statement: btmgmt is quite intended to be used for output at any manner, but they tried make a zillion variants of output which directed to exact result it should be: bug is buried somewhere deep inside of bt_shell_printf and struct data. I'm not ready run through all that disgusting documented code (I mean total absence of comments or more-or-less satisfactory mans), so I ended up with a liitte bit hacked version of utility downgraded to simple fprintf in output, leaving only commands I need: con, ssp, power and simplified until only current setting printing info. Everything works fine, and I can use that kind of btmgmt not with systemd only, but even with udev rules (indirectly, of course)
I know this is an old question, but I had the same problem, and managed to fix it after hours and hours of trying.
I don't know why in the world this happens to be so hard with btmgmt but here's the fix:
[Unit]
After=bluetooth.service
Description=Bluetooth service
[Service]
ExecStart=<your-process>
Group=root
StandardInput=tty
TTYPath=/dev/tty2
TTYReset=yes
TTYVHangup=yes
Type=simple
User=root
Basically, by occupying a TTY, btmgmt will think it's running in an interactive terminal, and will output as usual.
Hope this saves anyone the hell I've been through!
I want to extract execution traces (e.g., visited basic blocks) when testing Apache server (httpd). Since my work is based on LLVM infrastructure, I choose to use clang instrumentation based profiling as follows:
clang -fprofile-instr-generate ${options to compile httpd} -o httpd
export LLVM_PROFILE_FILE=code-%p.profraw
sudo -E ./httpd -k start # output a .profraw
curl ${url} # send a request
sudo -E ./httpd -k stop # output another .profraw
The compilation of instrumented httpd works well.
However, I want to track httpd's request handling which is executed in a separate child process. The output .profraw does not record any execution from child processes. As a result, I can only access the execution traces of starting and closing the server. How can I get the .profraw including request handling?
Not restricted in clang profiling. Any solution compatible with LLVM is great. Thanks!
Update
From the logs, it turns out the child process whose owner is "daemon" has no write permission to the files
LLVM Profile Error: Failed to write file "code-94752.profraw": Permission denied
Problem solved
The problem is the collision of prof file names. The process httpd -k start create multiple child processes as workers. When using LLVM_PROFILE_FILE=code-%p.profraw, their pid %p is same. So the main process is owned by root and creates the prof file first. Then latter process owned by daemon cannot write that file.
Solution: Use LLVM_PROFILE_FILE=code-%9m.profraw (%Nm instead of %p) to avoid name collisions.
There is no documentation that I can find beyond the oneliner provided by the command-line utility. It says:
-batch force batch I/O
So what's going on here if I pass it a query or multiple queries?
When the sqlite3 shell is run interactively, it shows a startup message and the sqlite> prompt, and (on Windows) tries to converts the input to UTF-8.
If the automatic console detection does not work as intended, it can be overridden with -batch or -interactive.
I'm trying to add the capability of generating a stack trace from a core dump on mac automatically when one of our tests crashes.
I was able to do it pretty easily on linux with
gdb --batch --quiet -ex "thread apply all bt" -ex "quit" <binary> <core file> 2> /dev/null
But I'm having some trouble doing the same on mac (OSX 10.8) with lldb. To start off, the version of lldb I'm using is lldb-310.2.37.
My initial approach was to use the -s option and pass in a script file like so:
target create -c <core file> <binary>
thread backtrace all
quit
Initially I had some trouble which I think was caused by missing a newline at the end of the script file which caused lldb to not exit, but after that was fixed, I'm getting the following:
Executing commands in 'lldbSource'.
(lldb) target create -c <core file> <binary>
Core file '<core file>' (x86_64) was loaded.
(lldb) thread backtrace all
error: Aborting reading of commands after command #1: 'thread backtrace all' failed with error: invalid thread
Aborting after_file command execution, command file: 'lldbSource' failed.
The funny thing is, after that happens, we're still running lldb, and issuing 'thread backtrace all' manually works just fine.
So, approach #2 was to create a python script and use their python API (I tried this before figuring out the initial blocker I described was due to a missing newline).
My script:
import lldb
debugger = lldb.SBDebugger.Create()
target = debugger.CreateTarget('<binary>')
if target:
process = target.LoadCore('<core file>')
if process:
print process.exit_description
for thread in process:
print 'Thread %s:' % str(thread.GetThreadID())
print '\n'.join(str(frame) for frame in thread)
The problem I'm having with this approach is that process.exit_description is returning None (and so is every other thing I've tried; LLDB's python API documentation is almost completely useless).
The output I'm looking for from that call is something similar to the following:
Process 0 stopped
* thread #1: tid = 0x0000, 0x00007fff8aca4670 libsystem_c.dylib`strlen + 16, stop reason = signal SIGSTOP
frame #0: 0x00007fff8aca4670 libsystem_c.dylib`strlen + 16
libsystem_c.dylib`strlen + 16:
-> 0x7fff8aca4670: pcmpeqb (%rdi), %xmm0
0x7fff8aca4674: andl $0xf, %ecx
0x7fff8aca4677: shll %cl, %eax
0x7fff8aca4679: pmovmskb %xmm0, %ecx
This is output automatically by LLDB proper when loading a core file. I don't necessarily need the assembly dump, but I want at least the thread, frame and reason.
I think the first approach I used, if it could be made to work, would be ideal, but either way is OK for me. I don't have control over the LLDB version that's going to be used unfortunately, so I can't just update to latest and see if it's a bug that was fixed.
Other approaches to get the desired output are also welcome. For context, this is going to be called from a perl script.
The --batch command line argument is supported in the version of lldb that ships with Xcode 7.2 (lldb-340.4.119), and possibly earlier.
It's not documented in the man page, but it is documented in lldb --help:
-b
--batch
Tells the debugger to running the commands from -s, -S, -o & -O,
and then quit. However if any run command stopped due to a signal
or crash, the debugger will return to the interactive prompt at the
place of the crash.
These other command line options are useful for lldb automation:
-o
--one-line
Tells the debugger to execute this one-line lldb command after any
file provided on the command line has been loaded.
-k
--one-line-on-crash
When in batch mode, tells the debugger to execute this one-line
lldb command if the target crashes.
Using these facilities, I pieced together the following command:
ulimit -c unlimited && (<binary> || (lldb -c `ls -t /cores/* | head -n1` \
--batch -o 'thread backtrace all' -o 'quit' && exit 1))
This command:
Enables core dumps
Runs the executable <binary>
If it fails, runs lldb on the most recently created core dump in /cores (hopefully the right one)
Prints the backtraces of all threads
Exits with a non-zero status, so that this command can be embedded in other workflows (CI scripts, Makefiles, etc.)
I would have preferred to run lldb on <binary> directly, so that the command does not rely on guessing at the correct core file. But lldb still appears to lack a way to cause it to exit with a non-zero exit status -- an equivalent of GDB's -return-child-result option or quit 1 command -- so I would have no way of knowing if the debugged program was successful or not. I filed an issue requesting such a feature.
TOT lldb from lldb.llvm.org has a new "--batch" mode to work pretty much like the gdb batch mode, and fixes some bugs that made command-line source commands behave better. If you can build your own lldb, you can get these fixes now, otherwise you'll have to wait till the next Xcode update.
The exit_description is None because your process didn't exit, it crashed. Note that at least on OS X several threads can have had simultaneous exceptions by the time the process gets around to crashing, it isn't really useful to say the process crashed. You have to ask the threads. The stop status that lldb prints out when a thread stops is available with the GetStatus method.
stream = lldb.SBStream()
process.threads[0].GetStatus(stream)
print stream.GetData()
That doesn't seem to have a very useful help string.
hi i am new to valgrind. I know how to run valgrind on executable files from command line. But how do you run valgrind on server processes like apache/myqld/traffic server etc ..
I want to run valgrind on traffic server (http://incubator.apache.org/projects/trafficserver.html) to detect some memory leaks taking place in the plugin I have written.
Any suggestions ?
thanks,
pigol
You have to start the server under Valgrind's control. Simply take the server's normal start command, and prepend it with valgrind.
Valgrind will attach to every process your main "server" process spawns. When each thread or process ends, Valgrind will output its analysis, so I'd recommend piping that to a file (not sure if it comes out on stderr or stdout.)
If your usual start command is /usr/local/mysql/bin/mysqld, start the server instead with valgrind /usr/local/mysql/bin/mysqld.
If you usually start the service with a script (like /etc/init.d/mysql start) you'll probably need to look inside the script for the actual command the script executes, and run that instead of the script.
Don't forget to pass the --leak-check=full option to valgrind to get the memory leak report.