Date: Mon, 6 Oct 2008 22:30:14 +0400 From: Andrey Chernov <ache@nagual.pp.ru> To: Tim Kientzle <kientzle@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: firefox3-bin crashes near arc4random_buf() Message-ID: <20081006183014.GB33333@nagual.pp.ru> In-Reply-To: <48E95D0E.50202@freebsd.org> References: <20081004080511.GA72641@lizzy.catnook.local> <20081004161024.GA67323@nagual.pp.ru> <20081004222249.GA48928@lizzy.catnook.local> <48E80F02.4070309@freebsd.org> <20081005233256.GB8507@lizzy.catnook.local> <48E95D0E.50202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 05, 2008 at 05:34:22PM -0700, Tim Kientzle wrote: > Something is still screwy about the backtrace. dbopen() > doesn't call arc4random_buf. However, it does call > mkstemp() which does call arc4random_uniform, which should > be right next to arc4random_buf in memory. GCC optimizations > could be obscuring the call stack here. FYI arc4random_uniform() just do some internal calculations then call arc4random() (perhaps several times) which have threaded lock, like any other arc4random* family. Like you can see, calculation not involves division, so division by zero can't happen and upper_bound passed by mkstemp() is very reasonable small number. Calling arc4random_buf() is not possible in this path. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081006183014.GB33333>