(Anonymous, 2005-09-21 09:49)
(Anonymous, 2005-09-22 11:29)
= How to report a bug =
If you find a bug in lighttpd you can help alot to find a fix for it by following some simple steps:
* [http://en.wikipedia.org/wiki/Don't_panic Don't Panic]
* if it is a crash generate a Backtrace
* if it behaves in a unexpected way prepare a strace
== Backtrace ==
A backtrace is a trace of the function which have been called before lighttpd died.
The best way to generate such a backtrace is using [http://valgrind.kde.org/ valgrind]:
$ valgrind --tool=memcheck -v --log-file=lighttpd --num-callers=8 lighttpd -D -f ./lighttpd.conf
valgrind does many useful things while it waits for the server to crash:
* checks for uninitialized variables
* checks for out-of-bounds access
* and many more
valgrind does not normally produce large log files and does not seem to degrade lightthpd's throughput much. Meaning, it's a very good alternative when debugging on busy servers as compared to strace.
If you can't use valgrind there is another way to generate a backtrace:
$ gdb lighttpd
(gdb) r -D -f lighttpd.conf
== strace ==
strace is the name of the syscall-tracer on Linux. Every Unix-like OS provides a utility to collect information about system call like open, write, close and so on.
The have different names like
* ktrace (then kdump to get output)
If strace is available it is prefered as it provides the most useful information. Execute it like:
$ strace -olighttpd.trace -tt -s 4000 lighttpd -D -f ./lighttpd.conf
It will generate a file called lighttpd.trace.
If you have a running instance of lighttpd and want to see what lighttpd is doing you can attach strace to the process:
$ strace -olighttpd.trace -tt -s 4000 -p <pidof-lighttpd>
Alternatively, if you want to debug a possible problem in lighttpd that is not related to networking and doing so on a busy server, try this:
$ strace -tt -s 4000 -etrace='!open,epoll_wait,epoll_ctl,sendfile64,read,fcntl,write,fcntl64,close,time,stat64,stat,writev,setsockopt,accept' -p <pidof-lighttpd>
The above would tell strace to exclude the system calls listed from the trace, thus reducing the performance impact on lighttpd as well as producing much less output that may actually not be necessary in order to debug the problem at hand.
== Memleaks ==
If you experience that lighttpd is using more than 1Gb of RAM you might have spotted a memleak. Valgrind, our valuable helper, can help you to provide the necessary information to fix it.
$ valgrind --tool=memcheck -v --log-file=lighttpd --num-callers=8 \
--leak-check=yes --show-reachable=yes \
lighttpd -D -f ./lighttpd.conf
Beware that this will use alot of memory and will slow down the process. You might not be able to run this on a production system with real load.
== Writing a bug report ==
If you have generated a backtrace or a syscall-trace please make sure that you can reproduce the problem. Otherwise it will be really hard for the developers to fix the problem for you.
If possible open a [http://trac.lighttpd.net/trac/newticket new ticket]
If the report contains sensitive data you might also send it directly to: mailto:firstname.lastname@example.org