|
From: Kristaps D. <kri...@bs...> - 2014-12-08 12:38:12
|
Hello list,
I'm experiencing a very strange error with valgrind-3.10.1 on Mac OS X
10.7.5 (via homebrew). In short, mmap(2) returns 0x0 for a regular
MAP_FILE of <=4096 bytes. To reproduce, I use the following simple test:
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int
main(int argc, char *argv[])
{
int i, fd;
void *buf;
struct stat st;
for (i = 1; i < argc; i++) {
if (-1 == (fd = open(argv[i], O_RDONLY, 0))) {
perror(argv[i]);
break;
}
if (-1 == fstat(fd, &st)) {
perror(argv[i]);
break;
}
buf = mmap(NULL, st.st_size,
PROT_READ, MAP_SHARED, fd, 0);
if (MAP_FAILED == buf) {
perror(argv[i]);
break;
}
printf("%s -> %p (%zu)\n",
argv[i], buf, (size_t)st.st_size);
munmap(buf, st.st_size);
close(fd);
}
return(i < argc ? EXIT_FAILURE : EXIT_SUCCESS);
}
When I run it on perfectly ordinary files, at first it randomly returned
0x0 instead of the usual mapped address, for example,
% valgrind ./a.out ../kcgi/*.xml
../kcgi/index.xml -> 0x338000 (12424)
../kcgi/template.xml -> 0x0 (188)
../kcgi/test.xml -> 0x0 (4)
../kcgi/version_0_4_2.xml -> 0x0 (488)
../kcgi/version_0_4_3.xml -> 0x0 (576)
../kcgi/version_0_4_4.xml -> 0x0 (291)
And now without valgrind...
% ./a.out ../kcgi/*.xml
../kcgi/index.xml -> 0x109ecf000 (12424)
../kcgi/template.xml -> 0x109ecf000 (188)
../kcgi/test.xml -> 0x109ecf000 (4)
../kcgi/version_0_4_2.xml -> 0x109ecf000 (488)
../kcgi/version_0_4_3.xml -> 0x109ecf000 (576)
../kcgi/version_0_4_4.xml -> 0x109ecf000 (291)
After running this on more files, I noticed that large files seemed ok;
small files failed. I bisected, and in the end:
% valgrind ./a.out test*.xml
test1.xml -> 0x0 (617)
test2.xml -> 0x338000 (6170)
test3.xml -> 0x0 (3117)
test4.xml -> 0x338000 (4820)
test5.xml -> 0x0 (4096)
test6.xml -> 0x338000 (4097)
In short, I can reliably have a value of 0x0 returned for files of less
than or equal to 4096 bytes.
Any thoughts? valgrind itself doesn't report anything, and
--trace-syscalls for the offending parts show nothing different for the
"failed" cases.
Best,
Kristaps
|