|
From: EXTERNAL W. P. (F. T. CM-AI/PJ-CF31)
<ext...@de...> - 2011-08-09 14:50:24
|
Hello,
I have a problem on ARM Linux (armv6l) with sem_open in libpthread-2.8.so.
We have a shared lib for resource managing that initializes a shared memory segment
in the constructor and protect against init races with a named semaphore via
init_lock = sem_open(OSAL_NAME_LOCK, O_CREAT|O_EXCL, 0666, 0,0);
if (init_lock == SEM_FAILED) {
fprintf(stderr,"sem_open(line %d) failed: %d: %s\n", __LINE__, errno, strerror(errno));
}
surprisingly this call fails if running inside valgrind:
root# valgrind ./procint
==912== Memcheck, a memory error detector
==912== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==912== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==912== Command: ./procint
[...]
==912==
sem_open(line 588) failed: 22: Invalid argument
when running without valgrind the call doesn't fail (yes I removed the objects with "rm /dev/shm/*")
statfs("/dev/shm", {f_type=0x1021994, f_bsize=4096, f_blocks=51955, f_bfree=51955, f_bavail=51955, f_files=51955, f_ffree=51954, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
futex(0x2af261a4, 0x81 /* FUTEX_??? */, 2147483647) = 0
gettimeofday({9735, 701869}, NULL) = 0
lstat64("/dev/shm/sem.pfO5mY", 0x7ec0fbc8) = -1 ENOENT (No such file or directory)
open("/dev/shm/sem.pfO5mY", O_RDWR|O_CREAT|O_EXCL, 0666) = 4
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16
mmap2(NULL, 16, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2aacc000
link("/dev/shm/sem.pfO5mY", "/dev/shm/sem.OSAL-init") = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=16, ...}) = 0
brk(0) = 0x15000
brk(0x36000) = 0x36000
unlink("/dev/shm/sem.pfO5mY") = 0
close(4) = 0
Besides wondering why glibc uses so many syscalls for sem_open - why does it fail with EINVAL?
Does the "syscall wrapper" gets confused about number of arguments or what?
At least sem_open can take just 2 or 4 arguments depending on O_CREAT.
To narrow the problem down, I resembled the shared lib and wrote a minimal test case.
But I'm really out of luck: the program runs fine inside valgrind:
root@bosch-nemid:/opt/bosch# ./sem_test
init(18)
sem_open: Success
shm_open: Success
init(40)
sem_open: Success
shm_open: Success
fini(45)
root@bosch-nemid:/opt/bosch# rm /dev/shm/*
root@bosch-nemid:/opt/bosch# valgrind ./sem_test
==932== Memcheck, a memory error detector
==932== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==932== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==932== Command: ./sem_test
==932==
init(18)
sem_open: Success
shm_open: Success
init(40)
sem_open: Success
shm_open: Success
fini(45)
==932==
==932== HEAP SUMMARY:
==932== in use at exit: 50 bytes in 2 blocks
==932== total heap usage: 2 allocs, 0 frees, 50 bytes allocated
==932==
==932== LEAK SUMMARY:
==932== definitely lost: 0 bytes in 0 blocks
==932== indirectly lost: 0 bytes in 0 blocks
==932== possibly lost: 0 bytes in 0 blocks
==932== still reachable: 50 bytes in 2 blocks
==932== suppressed: 0 bytes in 0 blocks
==932== Rerun with --leak-check=full to see details of leaked memory
==932==
==932== For counts of detected and suppressed errors, rerun with: -v
==932== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 6)
Best regards
Peter Wächtler
|