THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This is a page that we hope will help you file useful bug reports. This is always going to be work in progress, please make changes and additions as necessary.
| Table of Contents |
|---|
Basic information
Before filing a new bug report, please spend a minute or two to see if there are already a bug filed identical or similar to your problem. You are also highly encouraged to reproduce and test your problem with the latest development release, or even better, a build from SVN trunk. With that said, here are a few bullets on information that each new bug should include:
...
The default build, aka a release build, of ATS has debug information, but it's also an optimized build. This makes it more difficult to debug using such a binary, because code gets reorganized, variables and parameters gets optimized out, and so on. For best debugging, you should build Traffic Server in a debug-build mode. For example:
| Code Block |
|---|
$ ./configure --enable-debug
$ gmake
|
...
For best use of GDB, the following commands should be placed in your .gdbinit config, or done manually after you start gdb:
| Code Block |
|---|
set pagination 0
handle SIGPIPE nopass nostop noprint
|
...
The easiest way to debug ATS is simply starting it directly under gdb. For example:
| Code Block |
|---|
$ sudo gdb bin/traffic_server
...
Reading symbols from /usr/local/bin/traffic_server...done.
(gdb) run
|
...
In a production environment, where you want to start Traffic Server in the normal way, you must attach gdb to the already running traffic_server process. This is easy, you just need to find the PID of the running traffic_server process (e.g. 12345), and then tell gdb to attach to that PID. For example:
| Code Block |
|---|
$ sudo gdb /usr/local/bin/traffic_server 12345
Loaded symbols for /lib64/libselinux.so.1
0x0000003f2dee1293 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) continue
Continuing.
|
...
With some luck, you might have gotten a core file from a running ATS system. If so, you can debug traffic_server without affecting the production system, and simply attach GDB to that core file. For example:
| Code Block |
|---|
$ sudo gdb /usr/local/bin/traffic_server /tmp/core.12345
...
(gdb) bt
|
...
For an application to be able to generate a core file, it must have write permission to the directory where it should dump the core. This is by default $PWD, and for Traffic Server, this is not a directory that is typically writeable. Therefore, you should tell the kernel to generate core files in a different directory. The following example shows how to tell the system to generate core files like /tmp/core.12345:
| Code Block |
|---|
$ sudo sysctl kernel.core_pattern=/tmp/core.%p
|
...
On older Linux systems you may need to use the following instead.
| Code Block |
|---|
$ sudo sysctl kernel.core_uses_pid=1
$ sudo sysctl kernel.core_pattern=/tmp/core
|
...
In addition to being able to write to a directory, there are also a couple of resource limits that must be increased. Before starting traffic_server you must make sure that the process has unlimited core file size, and file size. You have a few options here, including modifying root's hard limits via /etc/security/limits.conf (but be aware that affects all of root's processes). Easiest is to do it from command line, e.g.
| Code Block |
|---|
$ sudo -s
# ulimit -c unlimited
# ulimit -f unlimited
# /usr/local/bin/trafficserver start
|
If your traffic_server is started by root (via init or similar mechansim) it will call setuid/setgid. For Traffic Server versions before 3.1.1 (see TS-936) this will prevent a core file from being generated. To work around this you should set /proc/sys/fs/suid_dumpable to 1.
| Code Block |
|---|
# echo 1 > /proc/sys/fs/suid_dumpable
|
...