seemingly good gdbinit for freebsd kernel errors out
Hi,
Im trying to debug a gdb init script that errors
out saying: too few arguments in function call
Here is the script
define kldload
set $kld = linker_files.tqh_first
set $done = 0
while ($kld != 0 $done == 0)
if ($kld-filename == $arg0)
set $done = 1
else
set $kld = $kld-link.tqe_next
end
end
if ($done == 1)
shell /usr/bin/objdump -h $arg0 | \
awk '/ .text/ { print set \$offset = 0x $6 }' .kgdb.temp
source .kgdb.temp
add-symbol-file $arg0 $kld-address + $offset
end
end
document kldload
Loads a module. Arguments are module name and offset of text section.
end
Any thoughts ?
Thanks,
Sanjeev.
-
You rock. That's why Blockbuster's offering you one month of Blockbuster Total
Access, No Cost.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Regression tests for usr.sbin/zic and lib/libc/stdtime
Greetings, I have make an attempt to upgrade the code in usr.sbin/zic and lib/libc/stdtime from tzcode2004 to tzcode2008a. So far so good: I have been able to apply most of the patches, it compiles and when I rebooted the machine it came back and all applications started up... Note that this is a 32 bit machine and that the interesting stuff is happening on 64 bitters. I would like to know if somebody has ever thought about what kind of regression tests I can make to be sure that it all works as expected once (if ever) this patch-set gets applied. Edwin -- Edwin Groothuis [EMAIL PROTECTED] http://www.mavetju.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regression tests for usr.sbin/zic and lib/libc/stdtime
On Wed, Apr 02, 2008 at 10:54:08PM +1100, Edwin Groothuis wrote:
Greetings,
I have make an attempt to upgrade the code in usr.sbin/zic and
lib/libc/stdtime from tzcode2004 to tzcode2008a. So far so good: I
have been able to apply most of the patches, it compiles and when
I rebooted the machine it came back and all applications started
up... Note that this is a 32 bit machine and that the interesting
stuff is happening on 64 bitters.
I would like to know if somebody has ever thought about what kind
of regression tests I can make to be sure that it all works as
expected once (if ever) this patch-set gets applied.
Edwin
Hey Edwin-
If you would like some help with the testing, please let me know. I have
actually been going through the codebase and started replace sprintf
with snprintf.
I have a patch for zic. Perhaps this can also be included in the modifications
you are currently working on?
--
Steven Kreuzer
http://www.exit2shell.com/~skreuzer
Index: zic.c
===
RCS file: /usr/share/cvs/freebsd/src/usr.sbin/zic/zic.c,v
retrieving revision 1.18
diff -u -r1.18 zic.c
--- zic.c 3 Dec 2007 10:45:44 - 1.18
+++ zic.c 25 Mar 2008 22:27:15 -
@@ -959,7 +959,7 @@
}
if (strcmp(fields[ZF_NAME], TZDEFAULT) == 0 lcltime != NULL) {
buf = erealloc(buf, (int) (132 + strlen(TZDEFAULT)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(\Zone %s\ line and -l option are mutually exclusive),
TZDEFAULT);
error(buf);
@@ -967,7 +967,7 @@
}
if (strcmp(fields[ZF_NAME], TZDEFRULES) == 0 psxrules != NULL) {
buf = erealloc(buf, (int) (132 + strlen(TZDEFRULES)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(\Zone %s\ line and -p option are mutually exclusive),
TZDEFRULES);
error(buf);
@@ -979,7 +979,7 @@
buf = erealloc(buf, (int) (132 +
strlen(fields[ZF_NAME]) +
strlen(zones[i].z_filename)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(duplicate zone name %s (file \%s\, line %d)),
fields[ZF_NAME],
zones[i].z_filename,
@@ -1451,7 +1451,7 @@
}
fullname = erealloc(fullname,
(int) (strlen(directory) + 1 + strlen(name) + 1));
- (void) sprintf(fullname, %s/%s, directory, name);
+ (void) snprintf(fullname, sizeof(filename), %s/%s, directory, name);
/*
* Remove old file, if any, to snap links.
@@ -1546,7 +1546,7 @@
if (strchr(format, '/') == NULL) {
if (letters == NULL)
(void) strcpy(abbr, format);
- else(void) sprintf(abbr, format, letters);
+ else(void) snprintf(abbr, sizeof(abbr), format, letters);
} else if (isdst)
(void) strcpy(abbr, strchr(format, '/') + 1);
else {
@@ -1887,7 +1887,7 @@
if (type == NULL || *type == '\0')
return TRUE;
buf = erealloc(buf, (int) (132 + strlen(yitcommand) + strlen(type)));
- (void) sprintf(buf, %s %d %s, yitcommand, year, type);
+ (void) snprintf(buf, sizeof(buf), %s %d %s, yitcommand, year, type);
result = system(buf);
if (WIFEXITED(result)) switch (WEXITSTATUS(result)) {
case 0:
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regression tests for usr.sbin/zic and lib/libc/stdtime
On Wed, Apr 02, 2008 at 06:27:25PM +0400, Andrew Pantyukhin wrote:
On Wed, Apr 02, 2008 at 09:57:46AM -0400, Steven Kreuzer wrote:
- (void) sprintf(fullname, %s/%s, directory, name);
+ (void) snprintf(fullname, sizeof(filename), %s/%s, directory, name);
Has a typo crawled in?
Yes it did. Thanks for catching that.
The attached patch corrects that typo.
--
Steven Kreuzer
http://www.exit2shell.com/~skreuzer
Index: zic.c
===
RCS file: /usr/share/cvs/freebsd/src/usr.sbin/zic/zic.c,v
retrieving revision 1.18
diff -u -r1.18 zic.c
--- zic.c 3 Dec 2007 10:45:44 - 1.18
+++ zic.c 26 Mar 2008 16:27:43 -
@@ -959,7 +959,7 @@
}
if (strcmp(fields[ZF_NAME], TZDEFAULT) == 0 lcltime != NULL) {
buf = erealloc(buf, (int) (132 + strlen(TZDEFAULT)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(\Zone %s\ line and -l option are mutually exclusive),
TZDEFAULT);
error(buf);
@@ -967,7 +967,7 @@
}
if (strcmp(fields[ZF_NAME], TZDEFRULES) == 0 psxrules != NULL) {
buf = erealloc(buf, (int) (132 + strlen(TZDEFRULES)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(\Zone %s\ line and -p option are mutually exclusive),
TZDEFRULES);
error(buf);
@@ -979,7 +979,7 @@
buf = erealloc(buf, (int) (132 +
strlen(fields[ZF_NAME]) +
strlen(zones[i].z_filename)));
- (void) sprintf(buf,
+ (void) snprintf(buf, sizeof(buf),
_(duplicate zone name %s (file \%s\, line %d)),
fields[ZF_NAME],
zones[i].z_filename,
@@ -1451,7 +1451,7 @@
}
fullname = erealloc(fullname,
(int) (strlen(directory) + 1 + strlen(name) + 1));
- (void) sprintf(fullname, %s/%s, directory, name);
+ (void) snprintf(fullname, sizeof(fullname), %s/%s, directory, name);
/*
* Remove old file, if any, to snap links.
@@ -1546,7 +1546,7 @@
if (strchr(format, '/') == NULL) {
if (letters == NULL)
(void) strcpy(abbr, format);
- else(void) sprintf(abbr, format, letters);
+ else(void) snprintf(abbr, sizeof(abbr), format, letters);
} else if (isdst)
(void) strcpy(abbr, strchr(format, '/') + 1);
else {
@@ -1887,7 +1887,7 @@
if (type == NULL || *type == '\0')
return TRUE;
buf = erealloc(buf, (int) (132 + strlen(yitcommand) + strlen(type)));
- (void) sprintf(buf, %s %d %s, yitcommand, year, type);
+ (void) snprintf(buf, sizeof(buf), %s %d %s, yitcommand, year, type);
result = system(buf);
if (WIFEXITED(result)) switch (WEXITSTATUS(result)) {
case 0:
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regression tests for usr.sbin/zic and lib/libc/stdtime
On Wed, Apr 02, 2008 at 09:57:46AM -0400, Steven Kreuzer wrote: - (void) sprintf(fullname, %s/%s, directory, name); + (void) snprintf(fullname, sizeof(filename), %s/%s, directory, name); Has a typo crawled in? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: pfind() and the proc structure
Thanks for all your replies,
the all_proc lock is held in pfind(..) at the point PROC_LOCK(p) is
obtained. In the kern_wait(..) code below, the allproc_lock is acquired
before removing the proc from the list of all procs. The PROC_LOCK is
then acquired before continuing. Since the thread that called pfind(..)
has the PROC_LOCK, kern_wait(..) would need to wait for it to release
the PROC_LOCK before continuing. I hope this understanding is correct.
In http://fxr.watson.org/fxr/source/kern/kern_exit.c?v=RELENG62#L579
sx_xlock(allproc_lock);
675 LIST_REMOVE(p, p_list); /* off zombproc */
676 sx_xunlock(allproc_lock);
677 LIST_REMOVE(p, p_sibling);
678 leavepgrp(p);
679 sx_xunlock(proctree_lock);
680
681 /*
682 * As a side effect of this lock, we know
that
683 * all other writes to this proc are visible
now, so
684 * no more locking is needed for p.
685 */
686 PROC_LOCK(p);
-Original Message-
From: Giorgos Keramidas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 10:58 AM
To: Rao, Nikhil
Cc: Roman Divacky; freebsd-hackers@freebsd.org
Subject: Re: pfind() and the proc structure
On Tue, 1 Apr 2008 07:23:58 -0700, Rao, Nikhil [EMAIL PROTECTED]
wrote:
Ok, I should have caught that :-( Another question - Now that the
PROC_LOCK on p is obtained the all_proc lock is released and the
function returns, at this point can't the proc get deallocated ?
Nikhil
242 struct proc *
243 pfind(pid)
244 register pid_t pid;
245 {
246 register struct proc *p;
247
248 sx_slock(allproc_lock);
249 LIST_FOREACH(p, PIDHASH(pid), p_hash)
250 if (p-p_pid == pid) {
251 if (p-p_state == PRS_NEW) {
252 p = NULL;
253 break;
254 }
255 PROC_LOCK(p);
256 break;
257 }
258 sx_sunlock(allproc_lock);
259 return (p);
260 }
Not until you unlock the specific proc entry. You are holding a lock
for the specific proc entry, so anyone trying to `reap' the process
would have to wait until you are done with what you are doing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
crontab Patches
I wrote two patches for crontab.c that I was wondering if someone would take a look at. The first one zero out pw_passwd in crontab, just to be paranoid side. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122070 The second replaces sprintf with snprintf http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122137 On an unrleated note, I submitted a small change for the freebsd-tips fortune datfile that removes references to two ports that no longer exist. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/122296 Thanks -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pfind() and the proc structure
On Wed, 2 Apr 2008 10:59:26 -0700, Rao, Nikhil [EMAIL PROTECTED] wrote:
Thanks for all your replies,
the all_proc lock is held in pfind(..) at the point PROC_LOCK(p) is
obtained. In the kern_wait(..) code below, the allproc_lock is acquired
before removing the proc from the list of all procs. The PROC_LOCK is
then acquired before continuing. Since the thread that called pfind(..)
has the PROC_LOCK, kern_wait(..) would need to wait for it to release
the PROC_LOCK before continuing. I hope this understanding is correct.
In http://fxr.watson.org/fxr/source/kern/kern_exit.c?v=RELENG62#L579
sx_xlock(allproc_lock);
675 LIST_REMOVE(p, p_list); /* off zombproc */
676 sx_xunlock(allproc_lock);
677 LIST_REMOVE(p, p_sibling);
678 leavepgrp(p);
679 sx_xunlock(proctree_lock);
680
681 /*
682 * As a side effect of this lock, we know
that
683 * all other writes to this proc are visible
now, so
684 * no more locking is needed for p.
685 */
686 PROC_LOCK(p);
Yes, line 686 above will have to wait for any holders of the proc lock
on the specific proc entry. The allproc_lock is not needed anymore,
because these last lines are inside:
if (p-p_state == PRS_ZOMBIE) {
...
After the zombie process has been removed from the zombie list, we will
have to wait until the proc entry is unlocked. At that point, the proc
entry is no longer on the zombie list, so it won't be locked by anyone
else. We grab the lock, clean it up and it's gone for good.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crontab Patches
On Wed, 2 Apr 2008 15:35:02 -0400, Steven Kreuzer [EMAIL PROTECTED] wrote: I wrote two patches for crontab.c that I was wondering if someone would take a look at. The first one zero out pw_passwd in crontab, just to be paranoid side. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122070 The second replaces sprintf with snprintf http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122137 Thanks, I'll have a look at these :-) On an unrleated note, I submitted a small change for the freebsd-tips fortune datfile that removes references to two ports that no longer exist. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/122296 misc/instant-server is still there. I think it's ok to remove the tip about instant-workstation, because the port has been removed by: # $FreeBSD: ports/misc/Makefile,v 1.831 2007/01/05 17:08:38 miwi Exp $ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
