[Snort-devel] [ snort-Bugs-466576 ] Core dump: PruneSessionCache

noreply at ...12... noreply at ...12...
Thu Oct 25 20:33:06 EDT 2001

Bugs item #466576, was opened at 2001-09-30 10:09
You can respond by visiting: 

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gerard Tromp (gtromp)
Assigned to: Martin Roesch (roesch)
Summary: Core dump: PruneSessionCache 

Initial Comment:
Snort version:

SunOS sanger 5.6 Generic_105181-17 sun4m sparc

gcc -v
Reading specs from
gcc version 2.95.2 19991024 (release)

Almost all of the standard current rules. 

Command line:
./snort -oedbD -c snort.conf

Error messages:

gdb of core:
#0  0x7ba34 in ubi_btNext ()
#1  0x80958 in PruneSessionCache ()
#2  0x7dc78 in ReassembleStream4 ()
#3  0x54144 in Preprocess ()
#4  0x466b4 in ProcessPacket ()
#5  0x82854 in pcap_read ()
#6  0x8344c in pcap_loop ()
#7  0x47cc8 in InterfaceThread ()
#8  0x46550 in main ()

adb of core:
ubi_btNext() + 20
+ 54
+	5cc
+ 58
+ 140
+ 170
+ 34
+ 70
main(0x0,0xeffffbc4,0xeffffbd8,0x165c30,0x0,0x0) + 814

It appears that ubi_btNext() is being provided with no
argument (pointer to binary tree node) in
the function PruneSessionCache.

I recently compiled snort 1.8.1 RELEASE and am finding
that it dumps core after running for some time. Except
for some trouble getting the make process running due
not having automake installed, everything worked well. 

The configuration file is similar to the one that I was
using for version 1.7. (Of course I edited the new
snort.conf to make use of the new features.)

Initially had trouble with the portscan pre-processor.
Did not want to ignore hosts. Built a debug version of
snort and with debuging of MSTRING and PREPROCESSOR
figured out that the DNS SERVERS have to be space

The output produced by the debug version of snort is
enormous and it runs for hours before dumping core with
a SIGBUS error. I have not yet run the debug version
until it dumped core. 

If you have suggestion for limiting unnecessary output
of debug-enabled snort will be willing to give it a run
-- will adding -ggdb to the compiler instruction


>Comment By: Martin Roesch (roesch)
Date: 2001-10-25 18:56

Logged In: YES 

No response for two weeks, I assume the problem was solved
with Build 84.  Closed.


Comment By: Martin Roesch (roesch)
Date: 2001-10-15 19:19

Logged In: YES 

Ok, please check out build 84 from CVS or from snort.org
(snort-current.tar.gz) and see if that fixes the problem.


Comment By: Gerard Tromp (gtromp)
Date: 2001-10-03 16:48

Logged In: YES 


Before anyone suggests it, I am running debug-enabled snort 
from with gdb (as daemon, but I have attached to the 
process and can set breakpoints etc. -- current watch is 

Will try to produce some additional and more informative 
data. It just happens that the core dumps apparently occur  
randomly anywhere from 1 hour to tens of hours. Also, on 
occasion running a program from within a debugger prevents 
the symptoms from showing up.

Will keep you informed.


Comment By: Gerard Tromp (gtromp)
Date: 2001-09-30 13:24

Logged In: YES 

Additional information:

gdb of core from debug-enabled snort:
#0  ubi_btNext (P=0x80a0c002) at ubi_BinTree.c:394
394	    while( NULL != P->Link[ whichway ] )
(gdb) info stack
#0  ubi_btNext (P=0x80a0c002) at ubi_BinTree.c:394
#1  0x849a8 in PruneSessionCache (thetime=1001874768,
mustdie=528132) at spp_stream4.c:2414
#2  0x824bc in ReassembleStream4 (p=0xeffff4c8) at
#3  0x56004 in Preprocess (p=0xeffff4c8) at rules.c:3426
#4  0x46858 in ProcessPacket (user=0x0, pkthdr=0xeffff4c8,
pkt=0x1a0800 "") at snort.c:534
#5  0x87d94 in pcap_read ()
#6  0x8898c in pcap_loop ()
#7  0x48068 in InterfaceThread (arg=0x16f000) at
#8  0x466f4 in main (argc=0, argv=0xeffffbc4) at snort.c:467

Looks like adb did incorrectly reported no arguments to
ubi_btNext. (Still does -- reports same register contents as
for the call to PruneSessionCache.)

output from the debug-enabled snort itself was not very
informative.  The log terminated with incomplete line, i.e.
buffer not flushed. The expected message "pruning stale
session"  from that portion of the code was not logged,
either because snort was not pruning the seesion or because
the message was not flushed..


You can respond by visiting: 

More information about the Snort-devel mailing list