on 03/08/2011 01:39 maestro something said the following:
hm userland and CTF not that I know. I only recompiled the kernel with CTF.
Do I
have to recompile userland (and would that be make world?) If so can i just
pass
the same WITH_CTF=1 option to make?
I _think_ (as in: not sure) that
on 03/08/2011 01:46 maestro something said the following:
What do I have to recompile for the patch to be picked up?
make libproc in /usr/src/lib
Correct way is:
$ cd /usr/src/lib/libproc
$ make obj
$ make depend
$ make
$ make install
--
Andriy Gapon
on 03/08/2011 03:47 maestro something said the following:
now it seems that the ustack() action on i386 and FreeBSD-9.0BETA1 almost
works.
Almost because dtrace still exits (this time without an error message) The
process for which the ustack should be genereated is terminated
Here are the
on 03/08/2011 11:42 Andriy Gapon said the following:
on 03/08/2011 03:47 maestro something said the following:
now it seems that the ustack() action on i386 and FreeBSD-9.0BETA1 almost
works.
Almost because dtrace still exits (this time without an error message) The
process for which the
Hi,
just finished installing FreeBSD-9BETA1 and recompiling the kernel with
dtrace.
This is even worse, I have the same behavior as mentioned here:
http://freebsd.1045724.n5.nabble.com/bin-158431-dtrace-crash-in-dt-proc-lookup-when-attaching-to-PID-assert-dpr-NULL-tt4535367.html#none
i.e.,
Hi,
This is even worse, I have the same behavior as mentioned here:
http://freebsd.1045724.n5.nabble.com/bin-158431-dtrace-crash-in-dt-proc-lookup-when-attaching-to-PID-assert-dpr-NULL-tt4535367.html#none
i.e., dtrace regardless of whether with or without any probes just quits
with the
on 02/08/2011 20:46 maestro something said the following:
Hi,
just finished installing FreeBSD-9BETA1 and recompiling the kernel with
dtrace.
This is even worse, I have the same behavior as mentioned here:
on 03/08/2011 00:03 Andriy Gapon said the following:
I tried to run dtruss (as you did) and I got this pre-amble before the
assertion:
[some dtrace script body]
: probe description proc:::exit does not match any probes
I guess that in my case I got it because my userland was not compiled
Hi,
http://freebsd.1045724.n5.nabble.com/bin-158431-dtrace-crash-in-dt-proc-lookup-when-attaching-to-PID-assert-dpr-NULL-tt4535367.html#none
Kind of a mentoring note: it would be much shorter and much more useful to
paste
PR 158431 or, even better, an http URL to the said PR in FreeBSD PR
Hi,
diff --git a/lib/libproc/proc_create.c b/lib/libproc/proc_create.c
index c372a47..9bd24a2 100644
--- a/lib/libproc/proc_create.c
+++ b/lib/libproc/proc_create.c
@@ -79,12 +79,11 @@ proc_attach(pid_t pid, int flags, struct proc_handle
**pphdl)
else
phdl-status =
On Tue, Aug 2, 2011 at 3:46 PM, maestro something maestr...@gmail.com wrote:
Hi,
diff --git a/lib/libproc/proc_create.c b/lib/libproc/proc_create.c
index c372a47..9bd24a2 100644
--- a/lib/libproc/proc_create.c
+++ b/lib/libproc/proc_create.c
@@ -79,12 +79,11 @@ proc_attach(pid_t pid, int
Hi,
Hi,
diff --git a/lib/libproc/proc_create.c b/lib/libproc/proc_create.c
index c372a47..9bd24a2 100644
--- a/lib/libproc/proc_create.c
+++ b/lib/libproc/proc_create.c
@@ -79,12 +79,11 @@ proc_attach(pid_t pid, int flags, struct proc_handle
**pphdl)
else
Running the same example on amd64 has the same behavior as on i386 (granted
the backtrace is slightly different).
That is, the kernel panics immediately when you use the ustack() action.
Furthermore, the crashdump does not provide the nececcary information to get
at the root of the cause (i.e.,
Hi,
I just tried your test on -STABLE + 1 fix from current [1] and got no trap.
dtrace: buffer size lowered to 2m
CPU IDFUNCTION:NAME
4 42224accept:return nc accept:return
Assertion failed: (dpr != NULL), file
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around. This is what I get when I
run
kgdb
On startup the assert frame is #7 and the probe frame is #8.
[snip]
kernel trap 12 with interrupts disabled
Fatal trap 12: page
on 30/07/2011 00:27 maestro something said the following:
on 30/07/2011 10:50 Andriy Gapon said the following:
#7 0xc11012d7 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko
Previous frame inner to this frame (corrupt stack?)
(kgdb)
what am I doing wrong and what do I have to do
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around. This is what I get
when I run
kgdb
On startup the assert frame is #7 and the probe frame is #8.
on 30/07/2011 21:19 maestro something said the following:
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around.
On Sat, Jul 30, 2011 at 11:27 AM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 21:19 maestro something said the following:
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the
Hi,
Have you started kgdb with the correct kernel and core file?
If yes, then I am out of ideas.
I hope so, I only recompiled the kernel once according to the DTRACE wiki
instructions and I certainly only have one /var/crash/vmcore.* file.
I'll try recompiling the kernel with -O1 and try
On Sat, Jul 30, 2011 at 12:05:33PM -0700, maestro something wrote:
Hi,
Have you started kgdb with the correct kernel and core file?
If yes, then I am out of ideas.
I hope so, I only recompiled the kernel once according to the DTRACE wiki
instructions and I certainly only have one
on 30/07/2011 22:05 maestro something said the following:
fb82i386# cat /etc/make.conf
CFLAGS= -O
(accodring to man make.conf only -O and -O2 is supported for CFLAGS anyways)
kernel.debug is the newly compiled kernel (according to the timestamp)
fb82i386# kgdb kernel.debug
Hi,
On Sat, Jul 30, 2011 at 12:52 PM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 22:05 maestro something said the following:
fb82i386# cat /etc/make.conf
CFLAGS= -O
(accodring to man make.conf only -O and -O2 is supported for CFLAGS
anyways)
kernel.debug is the newly
on 30/07/2011 23:03 maestro something said the following:
(kgdb) list *dtrace_probe+0xfd6
No source file for address 0xc10fa6a6.
Are the sources on the same machine?
This is probably the last idea from me.
--
Andriy Gapon
___
Hi,
on 30/07/2011 23:03 maestro something said the following:
(kgdb) list *dtrace_probe+0xfd6
No source file for address 0xc10fa6a6.
Are the sources on the same machine?
This is probably the last idea from me.
Yes all is done on the same (virtual 32bit) machine. Sources are there too.
Hi,
This is i386, right ?
I think the cause is that assembler routine panic_trigger does not
establish the standard i386 frame. Basically, you need either this,
or dwarf annotations, for gdb to be able to walk over the frame.
You need to add the standard prologue
pushl %ebp
Hi,
This is i386, right ?
I think the cause is that assembler routine panic_trigger does not
establish the standard i386 frame. Basically, you need either this,
or dwarf annotations, for gdb to be able to walk over the frame.
You need to add the standard prologue
pushl %ebp
Hi,
trying to do so I don't really find my way around. This is what I get when I
run kgdb
On startup the assert frame is #7 and the probe frame is #8.
kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the
on 26/07/2011 04:20 maestro something said the following:
Hi,
when using the ustack action on the latest FreeBSD8.2 i386 the kernel
panics.
Here is the information I could gather:
let me know if I can provide more information. (i.e., i have the full crash
information 80+mbs handy)
Use
29 matches
Mail list logo
