Re: ar(1) format_decimal failure is fatal?

On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote: > On Sun, 29 Aug 2010, Jilles Tjoelker wrote: > >> On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote: >>> [...] >>> building static egacy library >>> ar: fatal: Numeric user ID too large >>> *** Error code 70 >> >>> This error appe

KDB_TRACE and no backend

Here's a small patch that adds support for printing stack trace in form of frame addresses when KDB_TRACE is enabled, but there is no debugger backend configured. The patch is styled after "cheap" variant of stack_ktr. What do you think (useful/useless, correct, etc) ? --- a/sys/kern/subr_kdb.c

Re: zfs + uma

On Fri, 17 Sep 2010, Andre Oppermann wrote: Although keeping free items around improves performance, it does consume memory too. And the fact that that memory is not freed on lowmem condition makes the situation worse. Interesting. We may run into related issues with excessive mbuf (cluste

Re: zfs + uma

on 18/09/2010 14:23 Robert Watson said the following: > I've been keeping a vague eye out for this over the last few years, and > haven't > spotted many problems in production machines I've inspected. You can use the > umastat tool in the tools tree to look at the distribution of memory over > bu

Re: zfs + uma

On 18 Sep 2010, at 12:27, Andriy Gapon wrote: > on 18/09/2010 14:23 Robert Watson said the following: >> I've been keeping a vague eye out for this over the last few years, and >> haven't >> spotted many problems in production machines I've inspected. You can use the >> umastat tool in the tool

Re: zfs + uma

Robert Watson wrote: > On Fri, 17 Sep 2010, Andre Oppermann wrote: > > >> Although keeping free items around improves performance, it does consume > >> memory too. And the fact that that memory is not freed on lowmem > >> condition > >> makes the situation worse. > > > > Interesting. We may

Re: zfs + uma

on 18/09/2010 14:30 Robert N. M. Watson said the following: > Those issues are closely related, and in particular, wanted to point Andre at > umastat since he's probably not aware of it.. :-) I didn't know about the tool too, so thanks! But I perceived the issues as quite opposite: small items vs

Re: zfs + uma

On 18 Sep 2010, at 13:35, Fabian Keil wrote: > Doesn't build for me on amd64: > > f...@r500 /usr/src/tools/tools/umastat $make > Warning: Object directory not changed from original > /usr/src/tools/tools/umastat > cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector > -Wsystem-he

Re: zfs + uma

On Sat, Sep 18, 2010 at 6:52 AM, Robert N. M. Watson wrote: > > On 18 Sep 2010, at 13:35, Fabian Keil wrote: > >> Doesn't build for me on amd64: >> >> f...@r500 /usr/src/tools/tools/umastat $make >> Warning: Object directory not changed from original >> /usr/src/tools/tools/umastat >> cc -O2 -pip

Re: Why I can't trace linux process's childs with truss?

On Sun, Sep 12, 2010 at 05:01:09PM +0200, Mateusz Guzik wrote: > On Sun, Sep 12, 2010 at 3:08 PM, Alexander Best wrote: > > there's a PR related to this "issue" [1]. so is truss missing this > > functionality or is this in fact a feature, because truss musn't be used on > > any non freebsd executa

Re: zfs + uma

On 18 September 2010 17:52, Robert N. M. Watson wrote: > > On 18 Sep 2010, at 13:35, Fabian Keil wrote: > >> Doesn't build for me on amd64: >> >> f...@r500 /usr/src/tools/tools/umastat $make >> Warning: Object directory not changed from original >> /usr/src/tools/tools/umastat >> cc -O2 -pipe  -f

Re: KDB_TRACE and no backend

2010/9/18 Andriy Gapon : > > Here's a small patch that adds support for printing stack trace in form of > frame > addresses when KDB_TRACE is enabled, but there is no debugger backend > configured. > The patch is styled after "cheap" variant of stack_ktr. > > What do you think (useful/useless, co

Re: KDB_TRACE and no backend

on 18/09/2010 21:26 Attilio Rao said the following: > > You have to eventually wrap this logic within the 'STACK' option > (opt_stack.h for the check) because stack_save() will be uneffective > otherwise. STACK should be mandatory for DDB I guess, but it is not > for KDB. Thank you for the tip! B

Re: zfs + uma

> FWIW, kvm_read taking the second argument as unsigned long instead of > void* seems a bit inconsistent: I think it done on purpose, since address in the kernel address space has nothing to do with pointers for mere userland mortals. We shouldn't bother compiler with aliasing and other stuff in c

Re: KDB_TRACE and no backend

on 18/09/2010 21:41 Andriy Gapon said the following: > on 18/09/2010 21:26 Attilio Rao said the following: >> >> You have to eventually wrap this logic within the 'STACK' option >> (opt_stack.h for the check) because stack_save() will be uneffective >> otherwise. STACK should be mandatory for DDB I

Re: KDB_TRACE and no backend

on 18/09/2010 22:00 Andriy Gapon said the following: > Oh, wow, and I totally overlooked stack_print(). > Should have read stack(9) from the start. New patch. Hope this is better. I don't like that the printf is duplicated, but couldn't figure out a way to combine pre-processor and C conditions.

Re: KDB_TRACE and no backend

2010/9/18 Andriy Gapon : > on 18/09/2010 22:00 Andriy Gapon said the following: >> Oh, wow, and I totally overlooked stack_print(). >> Should have read stack(9) from the start. > > New patch.  Hope this is better. > I don't like that the printf is duplicated, but couldn't figure out a way to > comb

Re: KDB_TRACE and no backend

on 18/09/2010 23:35 Attilio Rao said the following: > It is still missing checking on opt_stack.h Yes, thanks, fixed it in my tree. > Besides, I'd reconsider having KDB_TRACE explanation in ddb(4) manpage > (right now it is rightly there because it is DDB specific only, as > long as it offers the

Re: KDB_TRACE and no backend

2010/9/18 Andriy Gapon : > on 18/09/2010 23:35 Attilio Rao said the following: >> It is still missing checking on opt_stack.h > > Yes, thanks, fixed it in my tree. > >> Besides, I'd reconsider having KDB_TRACE explanation in ddb(4) manpage >> (right now it is rightly there because it is DDB specifi

Re: ar(1) format_decimal failure is fatal?

Tim Kientzle wrote: > Personally, I wonder if it wouldn't make sense to just always > force the timestamp, uid, and gid to zero .. uid and gid, OK. Timestamp, no. It is not that rare to need to find out which version of some .o is in a particular .a file, usually in connection with debugging s

Re: zfs + uma

On Sat, 18 Sep 2010, Robert Watson wrote: On Fri, 17 Sep 2010, Andre Oppermann wrote: Although keeping free items around improves performance, it does consume memory too. And the fact that that memory is not freed on lowmem condition makes the situation worse. Interesting. We may run int