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.

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.

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 :->.

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).

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!!!"