HTTP-ANALYZE 2.0 BUG REPORT


Open a Call

Please use this form to open a call and submit a bug report.

Note: Only registered customers are entitled to open calls and submit bug reports this way. You will be asked for your username and password to access the extended support area on our web site.

Version:
Platform/OS:
Customer:
Registration ID:

Core dumps

In case of core dumps, please check the Customer Support section first there is a rollup patch available already. Please do not send us the core dump itself, but rather list the stack backtrace using a symbolic debugger such as sdb, dbx, or gdb. This stack backtrace can show the exact location of the crash. To create a stack backtrace, follow these steps (since different systems have different symbolic debuggers, the following commands may not work literally on your platform, but you probably have another debugger such as sdb, gdb, or even adb which use similar commands to list a stack backtrace:

  1. By default, http-analyze is compiled with the compiler option -g, which includes debugging information (necessary for the symbolic debugger) in the executable. If you did remove this option, you have to re-compile http-analyze again with -g.
  2. Run the program to create the core file. Depending on the location of the program flow, the core may be created in the current directory or in the directory specified by either the -o option on the command line or the "OutputDir (former "HTMLDir") directive in the configuration file.
  3. Then, start a symbolic debugger with the name of the executable as the first and the name of the core file as the second argument. List the stack backtrace using the appropriate command for the debugger (where in gdb, t in dbx and sdb):
    
    $ dbx http-analyze testd/core
     dbx version 6.2 Mar 9 1996 15:23:28
     Core from signal SIGSEGV: Segmentation violation
     (dbx) t
     > 0 strlen(0x3d3d0000, 0x10008c53, 0x0, 0x1) ["strlen.s":57]
       1 _doprnt(0x10008c10, 0x7fff24c0, 0xfb48db4, 0x1) ["doprnt.c":1222]
       2 fprintf(0xfb48db4, 0x10008c10, 0xfffffff9, 0x61) ["fprintf.c":45]
       3 prNavYear(ofp=0xfb48db4) ["http-analyze.c":2277]
       4 prMonIndex(stdir="www1997", current=0, last=0) ["http-analyze.c":2919]
       5 main(argc=5, argv=0x7fff2f14) ["http-analyze.c":1273]
       6 __istart() ["crt1tinit.s":13]
     (dbx) quit
     $
    

Include this stack backtrace together with a short description what you did in the bug report above.

Note : If the debugger is not able to tell you the location of the crash, this means that the frame and stack pointers got corrupted. In this case, the use of a debugger isn't much help.


Copyright © by RENT-A-GURU®