Problem with shared store in dumps - Linux

This is a discussion on Problem with shared store in dumps - Linux ; Hi, We're having a problem getting shared store in a process dump generated by (e.g.) calling abort() on x86-64 Linux systems (both RedHat and Suse). On an older system, RHEL AS4 (2.6.9-5.0.3.Elsmp) and gcc 3.4.3, the resulting dump contains the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Problem with shared store in dumps

  1. Problem with shared store in dumps

    Hi,

    We're having a problem getting shared store in a process dump
    generated by (e.g.) calling abort() on x86-64 Linux systems
    (both RedHat and Suse).

    On an older system, RHEL AS4 (2.6.9-5.0.3.Elsmp) and gcc 3.4.3,
    the resulting dump contains the shared store as required.

    On RHEL AS release 4 Update 6 (2.6.9-67.Elsmp) and SLES 10 SP1
    (2.6.16.46-0.12-smp) the area of store representing the mapped
    segment has been dumped but with zero size, and can't be accessed
    with gdb.

    Can anyone suggest what may have changed in this area, or what
    steps we must take to get shared store in a dump on the latest
    kernels.

    Sample source here: http://www.jusme.com/stuff/dump.cpp
    Sample run here: http://www.jusme.com/stuff/dump.txt

    Cheers,
    --
    Ian

    "Tamahome!!!" - "Miaka!!!"

  2. Re: Problem with shared store in dumps

    Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com> writes:

    > We're having a problem getting shared store in a process dump
    > generated by (e.g.) calling abort() on x86-64 Linux systems
    > (both RedHat and Suse).
    >
    > On an older system, RHEL AS4 (2.6.9-5.0.3.Elsmp) and gcc 3.4.3,
    > the resulting dump contains the shared store as required.
    >
    > On RHEL AS release 4 Update 6 (2.6.9-67.Elsmp) and SLES 10 SP1
    > (2.6.16.46-0.12-smp) the area of store representing the mapped
    > segment has been dumped but with zero size, and can't be accessed
    > with gdb.


    Same thing with Fedora Core 2 (2.6.10-1.771_FC2smp).

    The problem comes from 'maydump()' in fs/binfmt_elf.c (2.6.11.6):

    /*
    * Decide whether a segment is worth dumping; default is yes to be
    * sure (missing info is worse than too much; etc).
    * Personally I'd include everything, and use the coredump limit...
    *
    * I think we should skip something. But I am not sure how. H.J.
    */
    static int maydump(struct vm_area_struct *vma)
    {
    /* Do not dump I/O mapped devices, shared memory, or special mappings */
    if (vma->vm_flags & (VM_IO | VM_SHARED | VM_RESERVED))
    return 0;

    /* If it hasn't been written to, don't write it out */
    if (!vma->anon_vma)
    return 0;

    return 1;
    }

    Newer kernels have changed this. Current code from
    http://lxr.linux.no/linux/fs/binfmt_elf.c reads:

    /* By default, dump shared memory if mapped from an anonymous file. */
    if (vma->vm_flags & VM_SHARED) {
    if (vma->vm_file->f_path.dentry->d_inode->i_nlink == 0)
    return test_bit(MMF_DUMP_ANON_SHARED, &mm_flags);
    else
    return test_bit(MMF_DUMP_MAPPED_SHARED, &mm_flags);
    }

    So, if you only care about this on your own systems, then update
    the kernel. But if you need it for arbitrary system, then install
    signal handler for SIGABRT (and whichever other signals you care
    about), and do something like this:

    void handler(int signo)
    {
    // remap the segment private (needs access to original address,
    // size and file descriptor)
    void *x = mmap(adrs, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, h, 0);
    // needed to mark the segment "dirty":
    *(char*)x = *(char*)x;
    // re-raise the signal
    signal(signo, SIG_DFL);
    raise(signo);
    }

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: Problem with shared store in dumps

    In message , Paul
    Pluzhnikov wrote:

    > *(char*)x = *(char*)x;


    That should be:
    *(volatile char*)x = *(char*)x;

    Volatile is needed here otherwise the compiler may remove the assignment.

  4. Re: Problem with shared store in dumps

    Timothy Baldwin writes:
    > In message , Paul
    > Pluzhnikov wrote:
    >
    >> *(char*)x = *(char*)x;

    >
    > That should be:
    > *(volatile char*)x = *(char*)x;
    >
    > Volatile is needed here otherwise the compiler may remove the assignment.


    Modifying an object is defined to be a side effect
    (5.1.2.3|2). 'volatile' has no meaning for this case, it only affects
    (read) accesses (by turning them into side effects, too). 5.1.2.3|3
    says that

    An actual implementation need not evaluate part of an expression if it
    can deduce that its value is not used and that no needed side
    effects are produced (including any caused by calling a
    function or accessing a volatile object).

    Of course, this doesn't really help, because it isn't defined what a
    'needed side effect' actually is, hence, a Haskell-champion may safely
    "conclude" that side effects are never needed and remove all of
    them. Neither is 'modifying' defined by the C-standard, so, another,
    even less unreasonable assumption would be that a self-assignment does
    not constitute a modification. Last but not least, there is the
    'Rullgard rubber clause', 6.5|5, which states that the behaviour is
    undefined if an 'exceptional condition' occurs during evaluation of an
    expression, not defining what 'exceptional condition' is supposed to
    mean. This means that it can be interpreted to suit any purpose a
    gcc-developers believes to be capable of getting away with aka 'strict
    overflows' and the C-standard is completely useless to predict any
    behaviour of anything.

    So, test your code and ignore it :->.




  5. Re: Problem with shared store in dumps

    Timothy Baldwin writes:
    > In message , Paul
    > Pluzhnikov wrote:
    >
    >> *(char*)x = *(char*)x;

    >
    > That should be:
    > *(volatile char*)x = *(char*)x;
    >
    > Volatile is needed here otherwise the compiler may remove the assignment.


    Modifying an object is defined to be a side effect
    (5.1.2.3|2). 'volatile' has no meaning for this case, it only affects
    (read) accesses (by turning them into side effects, too). 5.1.2.3|3
    says that

    An actual implementation need not evaluate part of an expression if it
    can deduce that its value is not used and that no needed side
    effects are produced (including any caused by calling a
    function or accessing a volatile object).

  6. Re: Problem with shared store in dumps

    On 2008-04-13, Paul Pluzhnikov wrote:
    >
    > Same thing with Fedora Core 2 (2.6.10-1.771_FC2smp).
    >
    > The problem comes from 'maydump()' in fs/binfmt_elf.c (2.6.11.6):


    Cheers for the pointers, this is just the information we need.

    Regards,
    --
    Ian

    "Tamahome!!!" - "Miaka!!!"

+ Reply to Thread