Reporting Bugs¶

Reporting a bug¶

First step is to check that the issue has not been yet reported. To do so look in the Issues page of this website.

If the bug is not in the database, then you can create a new entry. Click here

The more information developers have the more easily they can understand the problem and found a solution. So all output are welcome in the bug report.

On of them is the output of suricata --build-info:

# suricata --build-info
pevma@DONPEDRO:~$ suricata --build-info
This is Suricata version 3.0dev (rev 44a444b)
Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LUA HAVE_LUAJIT HAVE_LIBJANSSON TLS 
SIMD support: SSE_4_2 SSE_4_1 SSE_3 
Atomic intrisics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 4.9.2, C version 199901
L1 cache line size (CLS)=64
thread local storage method: __thread
compiled with LibHTP v0.5.18, linked against LibHTP v0.5.18

Suricata Configuration:
  AF_PACKET support:                       yes
  PF_RING support:                         no
  NFQueue support:                         no
  NFLOG support:                           no
  IPFW support:                            no
  Netmap support:                          no
  DAG enabled:                             no
  Napatech enabled:                        no

  Unix socket enabled:                     yes
  Detection enabled:                       yes

  libnss support:                          yes
  libnspr support:                         yes
  libjansson support:                      yes
  hiredis support:                         no
  Prelude support:                         no
  PCRE jit:                                yes
  LUA support:                             yes, through luajit
  libluajit:                               yes
  libgeoip:                                yes
  Non-bundled htp:                         no
  Old barnyard2 support:                   no
  CUDA enabled:                            no

  Suricatasc install:                      yes

  Unit tests enabled:                      no
  Debug output enabled:                    no
  Debug validation enabled:                no
  Profiling enabled:                       no
  Profiling locks enabled:                 no
  Coccinelle / spatch:                     no

Generic build parameters:
  Installation prefix:                     /usr
  Configuration directory:                 /etc/suricata/
  Log directory:                           /var/log/suricata/

  --prefix                                 /usr
  --sysconfdir                             /etc
  --localstatedir                          /var

  Host:                                    x86_64-unknown-linux-gnu
  Compiler:                                gcc (exec name) / gcc (real)
  GCC Protect enabled:                     no
  GCC march native enabled:                yes
  GCC Profile enabled:                     no
  Position Independent Executable enabled: yes
  CFLAGS                                   -O0 -ggdb -march=native
  PCAP_CFLAGS                               -I/usr/include
  SECCFLAGS                                

In case of a crash, one great source of information is the core file. One possiblity it to provide developers (privately) the generated core file (see below for an explanation on where to find it) and Suricata binary. The core file will be really helpful if Suricata build has been made to include the maximum of debugging information. To do so, you have to modify the configure command line and rebuild suricata:

./configure YOUR_USUAL_FLAGS CFLAGS="-ggdb -O0" 

If you're using Rust, add --enable-rust-debug or --enable-debug to get Rust symbols.

An other possibility is to provide us a gdb output. Assuming that /usr/local/bin/suricata has created a /core file. An interesting output is:

# gdb /usr/local/bin/suricata /core
(gdb) set logging on
(gdb) thread apply all bt

Then press return till you get back to the prompt. Then tape quit. This process has created a gdb.txt file containing a copy of the output that describe the state of the different threads. You can then attach this file to the bug report.

For more info on how to get more details about what Suricata was doing during the crash, check Debugging.

Getting the core¶

If daemon mode is not used¶

Core file are created in the current working directory of Suricata. When Suricata is not running in daemon mode, the current working directory is the place where Suricata command has been launched. You should find a file named core into that directory. If there is multiple core, the PID is appended to the name.

In daemon mode¶

In Daemon mode, this is different. System is managing the output setting. Daemon mode setting can be tuned, see Dameon core for more information. Please note that core file can use much space so setting a directory where there is place enough is a good idea.

On Ubuntu server, apport is handling the core dump. So you need to get a look at apport.log to see if a core has been created:

# tail /var/log/apport.log -n100
ERROR: apport (pid 13795) Thu Dec 13 11:55:19 2012: called for pid 10741, signal 6
ERROR: apport (pid 13795) Thu Dec 13 11:55:19 2012: executable: /usr/local/bin/suricata (command line "/usr/local/bin/suricata -c /etc/suricata/regit-yaml/suricata-20120912.yaml --af-packet=eth3 -D")
ERROR: apport (pid 13795) Thu Dec 13 11:55:19 2012: executable does not belong to a package, ignoring
ERROR: apport (pid 13795) Thu Dec 13 11:55:19 2012: writing core dump to /core (limit: 18889465931478580853760)