solve stack
trace", and then dump the text symbols found on the stack and all
possible exception frames.
(ander...@redhat.com)
- Trivial formatting fix to "bpf" help page.
(ander...@redhat.com)
- Fix the "bpf" command display on Linux 4.17-rc1 and later
(super_block_buf);
(gdb)
1595 }
(gdb)
0x in ?? ()
That is, there is definitely memory corruption somewhere and 'mount' is most
probably just a victim.
Alex
On 2018-05-17 09:36 AM, Alex Sidorenko wrote:
crash> mount
VFSMOUNT SUPERBLK TYPE DEVN
if (!one_vfsmount)
(gdb)
1589 FREEBUF(mntlist);
(gdb)
1590 if (VALID_STRUCT(mount))
(gdb)
1593 FREEBUF(vfsmount_buf);
(gdb)
1594 FREEBUF(super_block_buf);
(gdb)
1595 }
(gdb)
0x in ?? ()
That is, there is definitely memory corruption somewhere and 'mount' is
most
probab
On March 8, 2012 11:11:36 PM Lei Wen wrote:
> Seem I get no luck to build out the pykdump...
> I git clone its tree from:
> git://pykdump.git.sourceforge.net/gitroot/pykdump/pykdump
> After this, I do the ./configure -c
> and then make, the following error shows up:
> Makefile:24: slocal.mk: No su
Hello,
even though PyKdump extension is widely used both in HP and other companies, I
have not uploaded any binaries to SF since 2008. This is mainly due to the
lack of time - my colleagues in HP use binaries built by me on our internal
hosts and other companies are either building from sources
On July 26, 2012 11:57:05 AM Petr Tesarik wrote:
> Hi all,
>
> as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,
> which is a C++ project.
Hi all,
I have a working prototype (still in Alpha) of Python-Qt based GUI that works
remotely using the following approach:
-
On August 2, 2012 11:22:26 AM Michael Holzheu wrote:
> Again just for your information:
>
> qlcrash used an similar aproach. The communication layer was
> pluggable. Besides of a local plugin there was a remote plugin that
> talked to an lcrash daemon via TCPIP. We could even run
> qlcrash on wind
On August 13, 2012 11:02:22 AM David Mair wrote:
> On 08/01/2012 04:06 PM, Alex Sidorenko wrote:
> > On July 26, 2012 11:57:05 AM Petr Tesarik wrote:
> >> Hi all,
> >>
> >> as part of SUSE HackWeek8, David started work on a GUI extension using
> >>
n older binary (6.1.1) on the same
vmcore and it behaves similarly.
Regards,
Alex
--
------
Alex Sidorenko email: a...@hp.com
BCS ERT Linux Hewlett-Packard (Canada)
Cr
Pykdump-0.1 - Python extension and scripting support
LinuxDump-0.1 - Extra modules and examples for Pykdump
--
This is the initial release of framework that embeds the Python interpeter in
a dynamically-loadable 'crash' extensi
Hi Dave,
trying the latest crash-4.0-3.20 on the latest Ubuntu/feisty kernel
2.6.20-9-generic I have found that live access does not work because of the
following mismatch:
/proc/version:
Linux version 2.6.20-9-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu
4.1.2-0ubuntu3)) #2 SMP Mon
On May 2, 2007 09:36:44 am Sachin P. Sant wrote:
> Dave, i came across one of the Crash TODO list items about having
> a scripting infrastructure in crash.
>
> I was trying to evaluate the Alicia utility [mentioned in todo list].
> Here are some of my observations about Alicia.
Hi Sachin,
I am de
On May 2, 2007 09:36:44 am Sachin P. Sant wrote:
> Dave, i came across one of the Crash TODO list items about having
> a scripting infrastructure in crash.
>
> I was trying to evaluate the Alicia utility [mentioned in todo list].
> Here are some of my observations about Alicia.
Hi Sachin,
I am de
On May 3, 2007 02:27:02 am Sachin P. Sant wrote:
> > The same - I am mainly working on 'xportshow.py' - printing nicely
> > various tables/structures, mostly IPv6 aware. Routing tables, TCP/UDP/IP
> > connections analysis, ARP-cache, Netfilter, devpack and so on.
> >
>
> So pykdump will be used f
Hi Dave,
when I try to use 'vtop' for process pages on 2.6.20 kernel (Ubuntu/Feisty) on
x86 architecture, I get error messages about page table. The easiest way to
reproduce is to run 'ps -a' on a live kernel:
PID: 0 TASK: c03a2440 CPU: 0 COMMAND: "swapper"
ps: no user stack
PID: 0
On May 30, 2007 12:06:51 pm Dave Anderson wrote:
> I forgot about this anomoly because Red Hat RHEL kernels outlaw the use of
> /dev/mem for anything above the first 256 pages of physical memory (for
> security purposes). And for that reason, RHEL kernels contain the
> /dev/crash driver for live m
Hi Dave,
on some distributions (e.g. Ubuntu) crash cannot find the live kernel image
because of a slight mismatch between kt->proc_version and 'strings' output
from namelist file (e.g. /boot/vmlinux-debug-2.6.22-14-generic)
Namely, kt->proc_version is LF-terminated, but there is no LF in 'strin
ing() is used in two places to compare with
kt->proc_version and in one place with
if (!match_file_string(system_map, "D system_utsname", buffer))
Stripping LF makes strstr() find a partial match. This should be OK for
comparisons with /proc/version and I think it's OK for &qu
On March 14, 2008 09:35:59 am Dave Anderson wrote:
> Anyway, since match_file_string() is used by multiple entities, and in
> the future a caller may actually want to include the linefeed, it doesn't
> seem appropriate to make the change there.
>
> Can you test the attached patch on both a live sys
Prebuilt extension modules released for x86 and x86_64 architectures today.
You can download them from http://sourceforge.net/projects/pykdump/, two
packages of interest are
mpykdump-x86 (0.5.1)
mpykdump-x86_64 (0.5.1)
They can be used immediately on any x86 or x86_64 Linux distribution with
G
On March 20, 2008 04:27:17 pm Dave Anderson wrote:
> Hi Alex,
>
> Nice. Now that's a serious extension!
>
> I'd like to add a reference to the general Python/Crash API as a third main
> section to the http://people.redhat.com/anderson/extensions.html page, with
> a subsection within it that refere
Hi Dave,
I have found that crash-4.0.9 cannot load any extensions on 32-bit hosts, even
echo.so. Running crash with -d5 on a live 32-bit kernel I can see that it
fails as
crash> extend extensions/echo.so
extend: ./extensions/echo.so: machine type mismatch: 3
extend: ./extensions/echo.so: not an
On October 5, 2009 01:04:43 pm Dave Anderson wrote:
> Thanks -- I'll take a look. It appears that the extension module
> is passing this test in is_shared_object():
>
> if (elf64->e_ident[EI_CLASS] == ELFCLASS64 ...
>
> What does "readelf -a" show for the echo.so file? (I don't have
> a handy x
On October 5, 2009 03:02:50 pm Dave Anderson wrote:
> 4.0.9 regression -- patch attached.
>
> Thanks for the report,
Thanks for quick fix, I tested it and everything works fine.
Regards,
Alex
--
--
Alexandre Sidorenko e
Hi Dave,
while working on an NFS problem (Ubuntu/Hardy) I needed to get definitions
of 'struct svc_cacherep'. I have compiled nfsd.ko with debugging for an older
kernel.
Current kernel: 2.6.24-24-generic
nfsd.ko:2.6.24-21-generic
The definition of 'struct svc_cacherep' is the same. To
On October 5, 2009 04:25:49 pm Dave Anderson wrote:
> However, then you loaded (via an internal "add-symbol-file" gdb operation)
> the older nfsd.ko module's information into the crash utility -- and it
> overwrote the original symbol value data with that from the (non-matching)
> nfsd.ko that cont
On June 28, 2010 03:16:32 pm Ratnam Tatavarty wrote:
> Hi,
> I am looking for a way to code/compile my Crash tool extension .so in CPP.
> During compile step, I hit a name collision with "namespace" keyword upon
> including defs.h. Does anyone try any CPP extensions before and if yes are
> there a
27 matches
Mail list logo
