gcore extension module update
 

This update fixes a bug and improves register restoration for active
tasks. See the ChangeLog below.

Note that there's no support range change on kernel versions and
architectures.

Thanks Dave for your reviewing.

ChangeLog:

- Fix a bug that for a multi-thread tasks, register values for all the
tasks are equal to the register values of the task specified by user
in command-line.
(d.hatayama@jp.fujitsu.com)

- Retrieve register values in exception frame on kernel stack that is
leaved by KDUMP, NETDUMP or DISKDUMP mechanism. Also, use register
values included in note information of KVMDUMP format.
(d.hatayama@jp.fujitsu.com)

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

gcore extension module update
 

This update introduces a support of 32-bit user-space tasks on X86_64
, and fixes a number of bugs.

This time RHEL5.6 has newly been tested. Support range for 32-bit
tasks on X86_64 is just the same as for ordinary 64-bit tasks. In
summary, the current support range is as follows:

Architecture: X86_64 including 32-bit tasks and X86
Versions: RHEL4.8, RHEL5.5, RHEL5.6, RHEL6.0 and vanilla 2.6.36.

Note: there is the issue that register restoration for callee-saved
registers doesn't work well on RHEL6.0 and recent kernels that are
built with recent tools. I'm going to address this issue but it's
still under investigation. I'd stress here that the register values
restored is enough for back tracing.

Also any comment, suggestion and report is welcome.

ChangeLog:

- Support 32-bit user-space tasks on X86_64. Created are 32-bit ELF
core files containing the same kinds of note information as on X86.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in calculation of detecting whether NT_IOPERM is available
or not. Without this fix, NT_IOPERM is never included in a core
file.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in a processing of writing note information. Without this
patch, a length of ELF note section recorded in PT_NOTE program
header entry could be different from an actual size of written data,
and tools such as gdb and binutils recognize it as an invalid ELF
file.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in resuming an original task context. Without this patch,
gcore fails to let crash's state resume back to the original context
when specifying a different task context as a target from a current
one.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in getting register values from
NT_PRSTATUS. DISKDUMP/NETDUMP saves register values for a panic task
only, while KDUMP saves NT_PRSTATUS for all active tasks. Without
this patch, dumping processing fails if a non-panic active task is
specified and analyzed kernel dumpfile contains NT_PRSTATUS for
panic task only. Although best way is to check the number of
NT_PRSTATUS contained in a given kernel dumpfile, this fix
temporarilly only checks in what formats the analying kernel dump
is.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in restoring segment register DS. Without this patch, the
value of DS segment register in NT_PRSTATUS is always 0 if a dump
target task is a sleep task.
(d.hatayama@jp.fujitsu.com)

- Fix a bug in restoring segment registers. Field size for segment
registers in kernel is 2 bytes, while field size in note information
is 8 bytes. Without this patch, high 6-bytes has an arbitrary value
in note information. Low 2-bytes remains the same.
(d.hatayama@jp.fujitsu.com)

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

gcore extension module update
 

On Thu, Feb 10, 2011 at 1:44 AM, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:

This update fixes a bug and improves register restoration for active

tasks. See the ChangeLog below.



Note that there's no support range change on kernel versions and

architectures.
[snip]

Let me just send a shout out, and say thanks for gcore!* For reasons I may never know (human error? communication?) a developer (vendor) asked me for a crash dump, when he really wanted a kill -6 of a user process.* If you haven't kept it in mind already, I am looking forward to writing out a new core file of just the user process.* Not a high priority, but something that would be grand for shipping off the user core when the crash dump is not needed in whole.


Thanks again!


Scott Edwards
-- Daxal Communications - http://www.daxal.com/?from=crash+mailinglist

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

gcore extension module update
 

The gcore files on http://people.redhat.com/anderson/extensions.html
have been updated.

Thanks,
Dave


----- Original Message -----
> This update fixes a bug and improves register restoration for active
> tasks. See the ChangeLog below.
>
> Note that there's no support range change on kernel versions and
> architectures.
>
> Thanks Dave for your reviewing.
>
> ChangeLog:
>
> - Fix a bug that for a multi-thread tasks, register values for all the
> tasks are equal to the register values of the task specified by user
> in command-line.
> (d.hatayama@jp.fujitsu.com)
>
> - Retrieve register values in exception frame on kernel stack that is
> leaved by KDUMP, NETDUMP or DISKDUMP mechanism. Also, use register
> values included in note information of KVMDUMP format.
> (d.hatayama@jp.fujitsu.com)
>
> Thanks.
> HATAYAMA Daisuke

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

gcore extension module update
 

----- Original Message -----

> Let me just send a shout out, and say thanks for gcore! For reasons I
> may never know (human error? communication?) a developer (vendor)
> asked me for a crash dump, when he really wanted a kill -6 of a user
> process. If you haven't kept it in mind already, I am looking forward
> to writing out a new core file of just the user process. Not a high
> priority, but something that would be grand for shipping off the user
> core when the crash dump is not needed in whole.
>
> Thanks again!
>
>
> Scott Edwards
> -- Daxal Communications - http://www.daxal.com/?from=crash+mailinglist

Hi Scott,

Help me out -- doesn't gcore do exactly what you're asking for?

Dave

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

gcore extension module update
 

Hi Scott,



Help me out -- doesn't gcore do exactly what you're asking for?



Dave




Why it appears so. I'm pretty sure I did not have access to gcore before. I still have a ~6mo old 16GB crash dump tucked away somewhere, and want to retry analysis after I find it.* It's probably a short circuit. I've been fuzzy ever since I left work yesterday.* Car was stuck twice on icy+snowy hills, took three hours for a normal 40 minute commute, and I'm sore all over. :)* I'm doing fine now. But still a big thank you for someone reaching for this fruit that's a little too high up for me.


Regards,


Scott Edwards
-- Daxal Communications - http://www.daxal.com/?from=crash+mailinglist

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

gcore extension module update
 

----- Original Message -----
> This update introduces a support of 32-bit user-space tasks on X86_64,
> and fixes a number of bugs.
>
> This time RHEL5.6 has newly been tested. Support range for 32-bit
> tasks on X86_64 is just the same as for ordinary 64-bit tasks. In
> summary, the current support range is as follows:
>
> Architecture: X86_64 including 32-bit tasks and X86
> Versions: RHEL4.8, RHEL5.5, RHEL5.6, RHEL6.0 and vanilla 2.6.36.
>
> Note: there is the issue that register restoration for callee-saved
> registers doesn't work well on RHEL6.0 and recent kernels that are
> built with recent tools. I'm going to address this issue but it's
> still under investigation. I'd stress here that the register values
> restored is enough for back tracing.
>
> Also any comment, suggestion and report is welcome.

The extensions page has been updated to reference the files in
this package:

http://people.redhat.com/anderson/extensions.html

Thanks,
Dave


> ChangeLog:
>
> - Support 32-bit user-space tasks on X86_64. Created are 32-bit ELF
> core files containing the same kinds of note information as on X86.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in calculation of detecting whether NT_IOPERM is available
> or not. Without this fix, NT_IOPERM is never included in a core
> file.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in a processing of writing note information. Without this
> patch, a length of ELF note section recorded in PT_NOTE program
> header entry could be different from an actual size of written data,
> and tools such as gdb and binutils recognize it as an invalid ELF
> file.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in resuming an original task context. Without this patch,
> gcore fails to let crash's state resume back to the original context
> when specifying a different task context as a target from a current
> one.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in getting register values from
> NT_PRSTATUS. DISKDUMP/NETDUMP saves register values for a panic task
> only, while KDUMP saves NT_PRSTATUS for all active tasks. Without
> this patch, dumping processing fails if a non-panic active task is
> specified and analyzed kernel dumpfile contains NT_PRSTATUS for
> panic task only. Although best way is to check the number of
> NT_PRSTATUS contained in a given kernel dumpfile, this fix
> temporarilly only checks in what formats the analying kernel dump
> is.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in restoring segment register DS. Without this patch, the
> value of DS segment register in NT_PRSTATUS is always 0 if a dump
> target task is a sleep task.
> (d.hatayama@jp.fujitsu.com)
>
> - Fix a bug in restoring segment registers. Field size for segment
> registers in kernel is 2 bytes, while field size in note information
> is 8 bytes. Without this patch, high 6-bytes has an arbitrary value
> in note information. Low 2-bytes remains the same.
> (d.hatayama@jp.fujitsu.com)
>
> Thanks.
> HATAYAMA Daisuke
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

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