Re: Re: [Crash-utility] User Stack back trace of the process
May be I'm posting to wrong mailing list.kindly guide me...
I have modified the elf_core dump functionality, to take only text, data and stack
segments. I'm not intrested in dynamic allocated memroy of the proces.
Below is the modification i have done in "binfmt_elf.c" file.
In maydump() function I'm checking for the VMA mapped to dynamic memory of the proces
or not.
-------------------------------------------------------
if ((vma->vm_file == NULL) &&
(!((current->mm->start_stack) < vma->vm_end)))
return 0;
-------------------------------------------------------
It is working fine for single threaded processes, but when i take the core dump of the
multi-threaded process, I only get the core dump of the process i kill. And in gdb I'm
not able to switch between the threads.
Please let me know whether those modifications are correct or not.
--Regards,
rajesh
On Wed, 05 Sep 2007 Dave Anderson wrote :
Rajesh wrote:
>Sorry in my previous e-mail I mistyped.
>
>I want to dump only code and stack segments of a process.
>
>--Regards,
>rajesh
stack segments would have: (vma->vm_flags & VM_GROWSDOWN)
>
>
>On Wed, 05 Sep 2007 Rajesh wrote :
> >Hi,
> >
> >Is there any way to find using kernel data structure, the VMA of a process
belongs to stack or heap. It is easy to distinguish the VMA belongs to code segment or
not from vm_area_struct structure, using "vm_flags" variable.
> >
> >In "elf_core_dump()" function I'm planning to dump only code and
data segments.
> >
> >Can any body please guide me...
> >
> >--Regards,
> >rajesh
> >
> >On Wed, 05 Sep 2007 Dave Anderson wrote :
> > >Rajesh wrote:
> > >>Dave,
> > >>
> > >>Thanks for your explanation.
> > >>
> > >>Well the reason behind my questions is, we have an application running
on customer site and the application consumes around 60GB of system memory.
> > >>When this process receives the segmentation fault or signal abort, the
kernel will start to take the process core dump. Here is the problem. Kernel takes at
least 1hr (60-minutes) to come out from core dump. During this time the system is
unresponsive (hung), and I feel it is because the system is entering into thrashing due to
huge memory usage by the process. This long down time is not acceptable by the customer.
> > >>
> > >>So I started to find the better way or tackling the problem.
> > >>
> > >>1>First thing we thought is changing the system page size from 4KB
to 8KB. Since this change could not be done on our x86_64 architecture, since x86_64
architecture doesnt support multi-page size option.
> > >>
> > >>2>We wrote a program using libbfd APIs and used with in our
application. Whenever the SIGSEGV or SIGABRT is received by the process it will log the
stack trace of all the threads within that process. This feature is not so effective or
flexible as compared to process core dump.
> > >>
> > >>3>Last we thought of using kcore/vmcore to analyze the cause for
SIGSEGV or SIGABRT.
> > >>
> > >>4>I have one more thought, making the elf_core_dump() function
SMP. This function is responsible for dumping the core, and the function is present in
/usr/src/linux/fs/binfmt_elf.c
> > >>
> > >>
> > >>Any comments/ideas are welcome.
> > >>
> > >>--Regards,
> > >>rajesh
> > >
> > >Maybe tinker with maydump()?
> > >
> > >If you know that the core dump contains the VMA's that are
> > >not necessary to dump, such as large shared memory segments,
> > >and you can identify them from the VMA, you can prevent
> > >them from being copied to the core dump. There's this
> > >patch floating around, which may have been updated:
> > >
> > > http://lkml.org/lkml/2007/2/16/149
> > >
> > >Dave
> > >
> > >
> > >
> > >
> >--
> >Crash-utility mailing list
> >Crash-utility(a)redhat.com
> >https://www.redhat.com/mailman/listinfo/crash-utility
>
>
>
><http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/signature-home.htm/1050715198@Middle5/1422717_1416193/1422162/1?PARTNER=3&OAS_QUERY=null
target=new >
>
Attachments:
- attachment.html (text/html — 5.6 KB)