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 appears to be coming
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
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
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
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 tools tree
Robert Watson rwat...@freebsd.org 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
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
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-headers
On Sat, Sep 18, 2010 at 6:52 AM, Robert N. M. Watson
rwat...@freebsd.org 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
On Sun, Sep 12, 2010 at 05:01:09PM +0200, Mateusz Guzik wrote:
On Sun, Sep 12, 2010 at 3:08 PM, Alexander Best arun...@freebsd.org 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
On 18 September 2010 17:52, Robert N. M. Watson rwat...@freebsd.org 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
2010/9/18 Andriy Gapon a...@icyb.net.ua:
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
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!
BTW,
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
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 guess,
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.
2010/9/18 Andriy Gapon a...@freebsd.org:
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
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
2010/9/18 Andriy Gapon a...@freebsd.org:
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
Tim Kientzle kient...@freebsd.org 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
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
21 matches
Mail list logo
