----- Original Message ----- > Hi all, > > these questions pops up all the time, how to get a stack traces etc. > from a crashing ATS installation. So, here are some quick tips . > > First, it's important to have a properly built ATS version for > debugging to be efficient. The "best" option is to build ATS with > something like this: > > #! /bin/sh > # > # Created by configure > > "./configure" \ > "--enable-static-libts" \ > "--enable-debug" \ > "$@" Next, Linux can be finicky when it comes to generating core > files, so I'd recommend the following sysctl configs: > > kernel.core_uses_pid = 1 > kernel.core_pattern = /tmp/core This tells the kernel to dump the > core file into /tmp, with a name like core.12345. Also, you might
For more info see core(5) http://www.freebsd.org/cgi/man.cgi?core http://www.kernel.org/doc/man-pages/online/pages/man5/core.5.html > need to increase the resource limits on the size of the core file > that can be generated. This can be done with e.g. "ulimit -c > unlimited", or adding something like this to > /etc/security/limits.conf: > > root - core unlimited This is *bad* it will be inherited down to *all* processes started by root, which are bound to be many. traffic_server runs as nobody (per default) so add that user too: your_ats_user - core unlimited > We might still not be able to get a core > file with all this said and done, so in that case, you might have to > attach gdb directly to the running traffic_server process. You can > do that with e.g. > > % sudo gdb /usr/local/bin/traffic_server 12345 > Where 12345 is the pid of the running traffic_server process. Once > you have entered the command above, make sure to type the "cont" > command to have gdb continue executing traffic_server. Assuming you > instead got a core file (lets hope), then instead you would run > > % sudo gdb /usr/local/bin/traffic_server /tmp/core.12345 > Now with either a core file, or a crasher inside gdb directly, you > need to submit useful information to us. The best starting point is > to get some stack traces, so inside gdb type: > > (gdb) set pagination 0 > (gdb) bt > ... > (gdb) thread apply all bt See also gcore, which gets a stack from the running process There's also poor man's profiler: http://poormansprofiler.org/ I mirror it (with slight modifications) here: http://blag.esotericsystems.at/igor/hacks/pmprofiler > This is now useful information, particularly if you compiled ATS like > mentioned above. Attach this to a bug in Jira, together with > information from you environment. Useful information includes: > > > • Version of ATS (this is absolutely necessary to do any > debugging). More importantly, you should run the latest released > version (development releases preferably). > • Linux version / platform > • Any configuration changes you have made > • Any information about what causes the crash, i.e. if you know > of a particular request that triggers it, or anything else that > would help reproducing the problem, please include it. > • Anything else you can possibly think would be useful to help > debug the problem, including promises of beer. > > I'm sure I've missed plenty of details here, so feel free to add to > this. > > Thanks, > > -- leif i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
