I'm still pursuing a FreeBSD bug in "7.2-PRERELEASE FreeBSD" -- and yes,
we know this is wildly out of date, but it's not feasible to upgrade
right now -- and while trying to backport a fix suggested here
http://permalink.gmane.org/gmane.os.freebsd.current/134266 I got a
situation where the panic calls in one of these two macros from
sys/queue.h
#define QMD_LIST_CHECK_NEXT(elm, field) do { \
if (LIST_NEXT((elm), field) != NULL && \
LIST_NEXT((elm), field)->field.le_prev != \
&((elm)->field.le_next)) \
panic("Bad link elm %p next->prev != elm", (elm)); \
} while (0)
#define QMD_LIST_CHECK_PREV(elm, field) do { \
if (*(elm)->field.le_prev != (elm)) \
panic("Bad link elm %p prev->next != elm", (elm)); \
} while (0)
print the message, but *don't* then proceed to drop to the debugger --
instead the system hangs, with the CPU running but I had no luck getting
its attention to force it to the debugger.
I'm not clear just what could be causing the hangup.
For my immediate purposes, I'd be happy with any way in which I could
brutally kill the kernel and force it to the debugger, say by replacing
the panic call with a printf followed by "1/0;". But I'm a little
confused by the panic.c code -- it prints the arguments using a
var_args, and then calls "exit(1);'
So my questions:
(1) will my brutal method actually force what I want or am I
misunderstanding something
(2) *which* of the several implementations of "int exit(int)" or similar
is the one called in the FreeBSD kernel?
(3) and how then does exit work?
--
Charles R. (Charlie) Martin
Senior Software Engineer
SGI logo
1900 Pike Road
Longmont, CO 80501
Phone: 303-532-0209
E-Mail: crmar...@sgi.com <mailto:crmar...@sgi.com>
Website: www.sgi.com <http://www.sgi.com>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"