Bug Report

Submitting a Bug Report

For open-source products, if you want to report a bug please open an issue on Github. For commercial products you need to use our ticketing system.

Submitting a Code Patch

If you want to submit a patch please send us a merge request via Github.

What To Do In Case Of Crash

In the unlikely case of crash, we need to apply a code patch. In addition to reporting the problem verbally, it is helpful to also try to debug the application so that we can have an idea of where the problem could be. You do not have to be a programmer to do that, as with some simple steps you can help us making debugging easier.

Enable Debugging In The Code

By default the GNU toolchain enables debugging symbols in the Makefile. Unfortunately it also enables code optimization that makes debugging difficult. Thus you need to remove optimization doing these simple steps:

    1. cd <ntop or nProbe directory>
    2. ./autogen.sh
    3. ./configure
    4. Edit Makefile and plugins/Makefile files and remove from it -O2 and -Os. Note that depending on your platform it might be that -Os is no present. Save the Makefile‘s.
    5. make

Run The Application

The GNU toolchain creates the binary files inside the .libs directory. You need to run the code from such directory and not from the directory where you have compiled ntop or nProbe. Most platforms do not generate core dumps in case of crash thus it’s also necessary to enable core dump generation prior to run the code. This is done in different wait depending on the shell you use.

  1. cd <ntop or nProbe directory>/.libs
  2. ln -s ../plugins . (nProbe with Plugins and ntop)
  3. ln -s ../html . (ntop only)
  4. sudo su (become root)
  5. ulimit -c unlimited (bash) or limit coredumpsize unlimited (tcsh)
  6. export LD_LIBRARY_PATH=. (Linux) or export DYLD_LIBRARY_PATH=. (Mac OS X).
  7. Finally run the application: ./ntop <put your options here>

Wait Until The Problem Shows Up

Crashing the application is something that can take some time. Thus you have to be patient, and use the application as usual. When the crash happens a core dump should be generated. Depending on the platform the core is saved into the same directory where you have started the application, or on MacOS X it can be found in the /cores directory. Usually the core file is named core, sometimes it has a PID (process ID) appended to it cores.<PID>.

Analyze The Core File

In order to analyze the core file you need to install the gdb debugger. Done that you can debug the core as follows (we suppose you use the bash shell and that you are still in the cd <ntop or nProbe directory>/.libs directory):

  1. Run the gdb: gdb ntop core. At this point the debugger will open a shell where you can run commands.
  2. Backtrace
    (gdb) bt
    #0 0x00007fff96a6ee42 in __semwait_signal ()
    #1 0x00007fff92d55dea in nanosleep ()
    #2 0x00000001060d7601 in _ntopSleepMSWhileSameState (file=0x105fa8d82 "main.c", line=678, ulDelay=5000) at util.c:4103
    #3 0x00000001060d77e9 in _ntopSleepWhileSameState (file=0x105fa8d82 "main.c", line=678, secs=5) at util.c:4131
    #4 0x0000000105f9eb09 in main (argc=6, argv=0x7fff65b99ae0) at main.c:678
  3. Show threads information
    (gdb) info threads
    6 0x00007fff96a6faf2 in read ()
    5 0x00007fff96a6edf2 in select$DARWIN_EXTSN ()
    4 0x00007fff96a6ebca in __psynch_cvwait ()
    3 0x00007fff96a6ee42 in __semwait_signal ()
    2 0x00007fff96a6ee42 in __semwait_signal ()
    * 1 0x00007fff96a6ee42 in __semwait_signal ()

Debugging Packaged Applications

ntop also distributes binary applications that can easily be debugged even when they run as services. On operating systems with systemd, generating cores for applications running as services require systemd-coredump executable. On ubuntu the executable and its ancillary services can be installed with a single package installation:

apt-get install systemd-coredump

Other distributions may have a slightly different name for the package. Once the package is installed, core dumps will automatically be generated for all the running services that undergo a crash. It may also be necessary to add LimitCORE=infinity to the service unit file’s [Service] section to prevent core dumps from being limited in size.

By default, systemd writes core dumps to the journal. In order to see generated core dumps, run:

coredumpctl list
Wed 2018-05-30 15:02:14 BST 14595 0 0 11 * /bin/bash
Wed 2018-05-30 15:10:20 BST 22290 0 0 11 * /usr/bin/myapp
Wed 2018-05-30 15:50:38 BST 22739 0 0 11 * /usr/bin/myapp

To get the most recent myapp coredump and export it to a file called myapp.core, run:

coredumpctl -o myapp.core dump /usr/bin/myapp

Similarly, core dumps can also be extracted using the pid. For example, the following command can be run to extract core dump related to process with pid 22739 into file myapp.core:

coredumpctl -o myapp.core dump 22739

Once the core file has been extracted from the journal, it can be easily analyzed with gdb to find the cause of the issue as described above.

Contact Us

Package the above trace information and file an issue on Github.