Here's a minimal test program that repros the problem.
On 8 January 2013 12:22, Tristan Schmelcher <tschmelc...@google.com> wrote:
>
>
>
> On 7 January 2013 22:43, Richard Weinberger <rich...@nod.at> wrote:
>
>> Am Mon, 7 Jan 2013 17:55:29 -0800
>> schrieb Tristan Schmelcher <tschmelc...@google.com>:
>>
>> > Hello,
>> >
>> > I am using UML as part of a hermetic build system and I have
>> > encountered an odd file corruption problem with the GNU Gold linker.
>> > When linking a binary inside a UML VM with Gold, if the output path
>> > is on a hostfs mount then all bytes in the output file produced by
>> > Gold are zero. However, the size of the output file is correct and
>> > the debugging output from running gold with --debug suggests that
>> > everything is working, so it seems like the content is being produced
>> > by Gold correctly but the file ends up containing all zeros instead.
>> > It has happened 100% of the time so far and it seems to be
>> > independent of the linker command line or input files.
>> >
>> > Are there any known issues where hostfs file content could end up as
>> > all zeros?
>>
>> Is the file corrupted or does it *always* contain zeros?
>>
>
> It's always all zeros. Not "corruption" in the normal sense.
>
>
>> If yes, the write command seems to fail.
>>
>> I'm wondering how gold writes a file.
>> Can you find out the system call sequence? (E.g using strace).
>>
>
> Certainly.
>
> Outside UML: http://pastebin.com/rJRL4guJ
> Inside UML writing to hostfs: http://pastebin.com/HyykiKfq
>
> The output file that gets the all-zero content
> is out/Debug/libvpx_obj_int_extract. Looks like gold uses posix_fallocate
> but that isn't implemented on hostfs, and glibc falls back to forcing
> blocks to be allocated via pwrite. Then it mmap's the file, presumably
> writes the content to the mmap'ed region, and closes.
>
> Hmm, maybe gold doesn't write anything to the mmap'ed region? Nope, it
> does: http://pastebin.com/nAzAibFv
>
> Hmm, maybe the EOPNOTSUPP code path in glibc is broken? Nope, works
> outside UML even if EOPNOTSUPP is forced: http://pastebin.com/nS90fB6t
>
> Perhaps there is a race in hostfs that causes the pwrite'ed pages to be
> written out after the mmap'ed data is written out?
>
>
>>
>> Thanks,
>> //richard
>>
>
>
// Test program to check if pwrite + mmap + munmap behaves.
#define _XOPEN_SOURCE 500
#include <sys/mman.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int fd = open(argv[1], O_RDWR|O_CREAT|O_TRUNC, 0644);
if (fd < 0) {
perror("open()");
return 1;
}
if (pwrite(fd, "", 1, 4095) != 1) {
perror("pwrite()");
return 1;
}
char *buf = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (buf == MAP_FAILED) {
perror("mmap()");
return 1;
}
buf[0] = 1;
if (munmap(buf, 4096) < 0) {
perror("munmap()");
return 1;
}
if (close(fd) < 0) {
perror("close()");
return 1;
}
return 0;
}
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
