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:[email protected]]
> Gesendet: Dienstag, 9. August 2011 16:50
> An: [email protected]
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
