> I did a few more tests this evening...and here's what I found. Under
> 2.0.27 and 2.0.29, on a system using gcc 2.7.2.1 and libc 5.4.17, the test
> program oopses. On another system totally a.out (except for its 2.0.29
> ELF kernel compiled elsewhere) that uses gcc 2.6.3 and libc 4.7.6, the
> test program does nothing but segfault. However, if I compile an ELF
> static test program on the above ELF box and run it on the a.out box, I
> get the oops and the second run hangs.
>
> So, is it a kernel bug, a libc bug, or both?
It's a bug in the elf core-dump function, which is why the a.out program
does not exhibit the problem.
I suspect that the program dies, the file is unmapped, but the core-dump
function still tries to access it and fails. If you try to printf the
value of p after mmap you will notice that it has exactly the same value
as the address ext2_file_write tried to access (and oopsed).
To support my theory, I tried the following experiment: mmap a file
with both read and write permissions, and then force a core-dump by
explicitely dereferencing a NULL pointer. The same thing (an oops, then a
hang) happens.
I'll try to have a look at it sometime next week, as this week is awfully
busy for me...
[question: should a core-dump dump all the mmaped files, too? even if
mapped with MAP_SHARED?]
Ionut
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.