headers
Olivier Cochard-Labbé | 1 Feb 10:44
Gravatar

Re: /usr/src/sys/net/if_pfsync.c patch: Didn't compile without INET6

Sorry for the MIME attachment in my previous email.

Here is a simple display of the patch in text:

[olivier <at> generator]~$ cat if_pfsync.c.patch
--- sys/net/if_pfsync.c.orig    Mon Jan 30 17:55:28 2012
+++ sys/net/if_pfsync.c Mon Jan 30 17:55:54 2012
@@ -1852,8 +1852,8 @@
                                ip6_output(pd->pd_m, NULL, NULL, 0,
                                    NULL, NULL, NULL);
                                break;
-                       }
 #endif /* INET6 */
+                       }
                 }
        }
Permalink | Reply | 0 comments |
headers
Matthias Kilian | 2 Feb 00:10
Picon

Re: [PATCH][BUG] ksh / sh segfault

On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote:
> I could reproduce the bug, but I'm not 100% happy with your fix since
> it just pushes the failure to a bigger number of vars.
> 
> It's better to check for the case like below,
> 
> 	-Otto
> 
> Index: table.c
> ===================================================================
> RCS file: /cvs/src/bin/ksh/table.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 table.c
> --- table.c	17 Jan 2009 22:06:44 -0000	1.13
> +++ table.c	31 Jan 2012 12:07:20 -0000
> @@ -108,7 +108,10 @@ ktenter(struct table *tp, const char *n,
>  	}
>  
>  	if (tp->nfree <= 0) {	/* too full */
> -		texpand(tp, 2*tp->size);
> +		if (tp->size <= SHRT_MAX/2)
> +			texpand(tp, 2*tp->size);
> +		else
> +			internal_errorf(1, "too many vars");
>  		goto Search;
>  	}

Regardless of the other problem filling up the table, i think that
this should be comitted.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Otto Moerbeek | 2 Feb 10:43

Re: [PATCH][BUG] ksh / sh segfault

OK, the bounds check has been committed.

Based on Michael's suggestions, I'm now playing with the diff below.
It really makes the hastable behave faster. 

Still have to check if and why more entries than expected are used in
some cases. 

	-Otto

Index: table.c
===================================================================
RCS file: /cvs/src/bin/ksh/table.c,v
retrieving revision 1.14
diff -u -p -r1.14 table.c
--- table.c	2 Feb 2012 08:42:46 -0000	1.14
+++ table.c	2 Feb 2012 09:21:58 -0000
@@ -18,8 +18,8 @@ hash(const char *n)
 	unsigned int h = 0;

 	while (*n != '\0')
-		h = 2*h + *n++;
-	return h * 32821;	/* scatter bits */
+		h = 33*h + *n++;
+	return h;
 }

 void
@@ -44,7 +44,7 @@ texpand(struct table *tp, int nsize)
 	for (i = 0; i < nsize; i++)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Steffen Daode Nurpmeso | 2 Feb 15:31

Re: [PATCH][BUG] ksh / sh segfault

Otto Moerbeek wrote [2012-02-02 10:43+0100]:
> Based on Michael's suggestions, I'm now playing with the diff below.
> It really makes the hastable behave faster. 
> 
> Still have to check if and why more entries than expected are used in
> some cases. 
> 
> 	-Otto
> 
>  	while (*n != '\0')
> -		h = 2*h + *n++;
> -	return h * 32821;	/* scatter bits */
> +		h = 33*h + *n++;
> +	return h;
>  }

I'm using Chris Toreks hash algorithm (as stolen from some
Berkeley DB source) for more than a decade, after having performed
quite excessive testing on strings with several hash algorithms.

It is used in general purpose prime-indexed hashtables as well as
power-of-two spaced (and AND-mask indexed) string-key-only
dictionaries, and behaves well on all sorts of input ever since
(using table grow factors from 400% to 1600% percent, normally).
(Ever since: hmm, in the beginning i've often done
::dump_statistics(), but then ..)

So that's what i find in my hash_case.cc:

	for (h ^= h; *n; ++n)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Otto Moerbeek | 2 Feb 16:43

Re: [PATCH][BUG] ksh / sh segfault

On Thu, Feb 02, 2012 at 03:31:54PM +0100, Steffen Daode Nurpmeso wrote:

> Otto Moerbeek wrote [2012-02-02 10:43+0100]:
> > Based on Michael's suggestions, I'm now playing with the diff below.
> > It really makes the hastable behave faster. 
> > 
> > Still have to check if and why more entries than expected are used in
> > some cases. 
> > 
> > 	-Otto
> > 
> >  	while (*n != '\0')
> > -		h = 2*h + *n++;
> > -	return h * 32821;	/* scatter bits */
> > +		h = 33*h + *n++;
> > +	return h;
> >  }
> 
> I'm using Chris Toreks hash algorithm (as stolen from some
> Berkeley DB source) for more than a decade, after having performed
> quite excessive testing on strings with several hash algorithms.
> 
> It is used in general purpose prime-indexed hashtables as well as
> power-of-two spaced (and AND-mask indexed) string-key-only
> dictionaries, and behaves well on all sorts of input ever since
> (using table grow factors from 400% to 1600% percent, normally).
> (Ever since: hmm, in the beginning i've often done
> ::dump_statistics(), but then ..)
> 
> So that's what i find in my hash_case.cc:
(Continue reading)

Permalink | Reply | 9 comments |

Gmane