|
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
|
|
From: EXTERNAL W. P. (F. T. CM-AI/PJ-CF31)
<ext...@de...> - 2011-08-11 15:47:43
|
Uhh, I learned another option "--trace-syscalls=yes"
SYSCALL[967,1]( 99) sys_statfs ( 0x4c76768(/dev/shm), 0x7de32b48 )[sync] --> Success(0x0:0x0)
SYSCALL[967,1](240) sys_futex ( 0x4c821a4, 129, 2147483647, 0x0, 0x7de32bd0 ) --> [async] ...
SYSCALL[967,1](240) ... [async] --> Success(0x0:0x0)
SYSCALL[967,1]( 78) sys_gettimeofday ( 0x7de32b90, 0x0 )[sync] --> Success(0x0:0x0)
SYSCALL[967,1](196) sys_lstat64 ( 0x7de32bd0(/dev/shm/sem.04lA13), 0x7de32b28 )[sync] --> Failure(0x2)
SYSCALL[967,1]( 5) sys_open ( 0x7de32bd0(/dev/shm/sem.04lA13), 194, 438 ) --> [async] ...
SYSCALL[967,1]( 5) ... [async] --> Success(0x0:0x4)
SYSCALL[967,1]( 4) sys_write ( 4, 0x7de32c2c, 16 ) --> [async] ...
SYSCALL[967,1]( 4) ... [async] --> Success(0x0:0x10)
SYSCALL[967,1](192) sys_mmap2 ( 0x0, 16, 3, 1, 4, 0 ) --> [pre-fail] Failure(0x16)
SYSCALL[967,1]( 10) sys_unlink ( 0x7de32bd0(/dev/shm/sem.04lA13) ) --> [async] ...
SYSCALL[967,1]( 10) ... [async] --> Success(0x0:0x0)
SYSCALL[967,1]( 6) sys_close ( 4 )[sync] --> Success(0x0:0x0)
SYSCALL[967,1]( 4) sys_write ( 2, 0x7de305a8, 48 ) --> [async] ...
sem_open(line 588) failed: 22: Invalid argument
SYSCALL[967,1]( 4) ... [async] --> Success(0x0:0x30)
the sys_mmap2 fails with "0x16 -> 22" EINVAL if running inside valgrind.
without valgind not:
> 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
Mit freundlichen Grüßen / Best regards
Peter Wächtler
> -----Ursprüngliche Nachricht-----
> Von: EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31)
> [mailto:ext...@de...]
> Gesendet: Dienstag, 9. August 2011 16:50
> An: Val...@li...
> Betreff: [Valgrind-users] problems with sem_open under
> valgrind 3.6.1 on ARM
>
> 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
>
>
>
> --------------------------------------------------------------
> ----------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing
> Subversion and
> the tools developers use with it. Learn more about uberSVN
> and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|