----- "Gallus" <gall.cwpl@gmail.com> wrote:

> Hi,
> is it possible to display a stack trace of an user space process?

No.

You could do a raw "rd -u" of the user-space stack, but given that
the crash utility has no knowledge of any user-space symbols,
it's probably not going to be very illuminating.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

On 23 February 2010 19:28, Dave Anderson <anderson@redhat.com> wrote:



----- "Gallus" <gall.cwpl@gmail.com> wrote:



> Hi,

> is it possible to display a stack trace of an user space process?



No.



You could do a raw "rd -u" of the user-space stack, but given that

the crash utility has no knowledge of any user-space symbols,

it's probably not going to be very illuminating.



Dave


Thanks for the answer. If I will use addr2line or similar technique on the binary whose stack I will read by using "rd -u", then I can get something meaningful, right? (I have a binary that isn't striped).


Regards,
Gallus


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

----- "Gallus" <gall.cwpl@gmail.com> wrote:

> On 23 February 2010 19:28, Dave Anderson < anderson@redhat.com >
> wrote:
>
>
>
>
> ----- "Gallus" < gall.cwpl@gmail.com > wrote:
>
> > Hi,
> > is it possible to display a stack trace of an user space process?
>
> No.
>
> You could do a raw "rd -u" of the user-space stack, but given that
> the crash utility has no knowledge of any user-space symbols,
> it's probably not going to be very illuminating.
>
> Dave
>
> Thanks for the answer. If I will use addr2line or similar technique on
> the binary whose stack I will read by using "rd -u", then I can get
> something meaningful, right? (I have a binary that isn't striped).

Right -- you should see the user-space return-address values starting
from the point shown in the ESP (386) or RSP (x86_64) value shown
in the kernel entry-point exception frame. Although the first few
frames will typically be in a user library instead of the binary.

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

On 24 February 2010 13:45, Dave Anderson <anderson@redhat.com> wrote:
> Right -- you should see the user-space return-address values starting
> from the point shown in the ESP (386) or RSP (x86_64) value shown
> in the kernel entry-point exception frame. *Although the first few
> frames will typically be in a user library instead of the binary.
>
> Dave

Here is the bt:
#0 [f672de20] schedule at c0616008
#1 [f672de98] schedule_timeout at c061675c
#2 [f672debc] do_futex at c0438ea7
#3 [f672df80] sys_futex at c0439942
#4 [f672dfb8] system_call at c0404f10
EAX: 000000f0 EBX: 0a50db84 ECX: 00000000 EDX: 00000b73
DS: 007b ESI: bfd90dd8 ES: 007b EDI: 00000b73
SS: 007b ESP: bfd90dd0 EBP: bfd90e24
CS: 0073 EIP: 00f14402 ERR: 000000f0 EFLAGS: 00200206


I then do "rd -u bfd90dd0 16" and search for the addresses in the
binary, but they're not found. Is ESP's value the one that I should be
reading from?

Gallus

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

----- "Gallus" <gall.cwpl@gmail.com> wrote:

> On 24 February 2010 13:45, Dave Anderson <anderson@redhat.com> wrote:
> > Right -- you should see the user-space return-address values starting
> > from the point shown in the ESP (386) or RSP (x86_64) value shown
> > in the kernel entry-point exception frame. *Although the first few
> > frames will typically be in a user library instead of the binary.
> >
> > Dave
>
> Here is the bt:
> #0 [f672de20] schedule at c0616008
> #1 [f672de98] schedule_timeout at c061675c
> #2 [f672debc] do_futex at c0438ea7
> #3 [f672df80] sys_futex at c0439942
> #4 [f672dfb8] system_call at c0404f10
> EAX: 000000f0 EBX: 0a50db84 ECX: 00000000 EDX: 00000b73
> DS: 007b ESI: bfd90dd8 ES: 007b EDI: 00000b73
> SS: 007b ESP: bfd90dd0 EBP: bfd90e24
> CS: 0073 EIP: 00f14402 ERR: 000000f0 EFLAGS: 00200206
>
>
> I then do "rd -u bfd90dd0 16" and search for the addresses in the
> binary, but they're not found. Is ESP's value the one that I should be
> reading from?

That's right. That is the stack value that will be restored upon
return to user-space, and the EIP will be restored to 00f14402.

One thing to make sure of is that when you do the "rd -u", you
have set the crash utility to the context of the task whose "bt"
output you're showing. "rd -u" will read the user space of the
current task (i.e., the task shown if you do a "set" command).

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

On Wed, Feb 24, 2010 at 12:21 PM, Dave Anderson <anderson@redhat.com> wrote:

That's right. *That is the stack value that will be restored upon
return to user-space, and the EIP will be restored to 00f14402.



One thing to make sure of is that when you do the "rd -u", you

have set the crash utility to the context of the task whose "bt"

output you're showing. *"rd -u" will read the user space of the

current task (i.e., the task shown if you do a "set" command).



Could that be adapted into a way to produce a userspace core dump that we could feed to regular old gdb?

--Darrin*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

----- "Darrin Thompson" <darrinth@gmail.com> wrote:

> On Wed, Feb 24, 2010 at 12:21 PM, Dave Anderson < anderson@redhat.com
> > wrote:
>
>
>
> That's right. That is the stack value that will be restored upon
> return to user-space, and the EIP will be restored to 00f14402.
>
> One thing to make sure of is that when you do the "rd -u", you
> have set the crash utility to the context of the task whose "bt"
> output you're showing. "rd -u" will read the user space of the
> current task (i.e., the task shown if you do a "set" command).
>
> Could that be adapted into a way to produce a userspace core dump that
> we could feed to regular old gdb?

This question comes up from time to time.

If all of a task's user pages were in memory (not swapped out), and
therefore in the vmcore -- which is becoming more and more unlikely
with the use of makedumpfile to skip user pages altogether -- then
theoretically the kernel's elf_core_dump() function could basically
be "ported" to user-space. I think...

Anyway, I'm not particularly interested in doing it. But it would
be an excellent candidate for an extension module if anybody's willing
to take it on.

Dave




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility