Re: [Valgrind-users] shmat parameters are modified by valgrind
Hi,
I have used below program for testing. Below are the steps I have followed.
Compile: gcc -g3 test_shm.c -o test_shm
Create shared memory: ./test_shm –c
Get shared memory without valgrind: ./test_shm –g ( this works fine)
Get with valgrind: /usr/bin/valgrind --tool=memcheck --leak-check=full
--track-origins=yes --log-file=/tmp/val_log /home/rtp99/test_shm –g
With valgrind shmat command fails.
Total shared memory segments active on the my system is 320.
My process will attach to 40 shared memory segments. Shmat will fails when
tested with 14 shared memory attach also.
Total RAM available on my system is 124GB. I am using HP C7000 blade hardware
with RHEL6.2 OS.
I am using 64bit binary. 'file test_shm' command output is
test_shm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
#include
#include
#include
#include
#include
struct shm_details
{
key_t key;
size_t size;
int shmid;
void *shm;
};
main(int argc,char **argv) {
int i;
struct shm_details test_shm[] =
{
{0xe300626d,2147456,-1,NULL },
{0xe300626c ,144271608 ,-1,NULL},
{0xe300626e,115604 ,-1,NULL},
{0xe300626f ,118376704 ,-1,NULL},
{0xe300653d ,574592 ,-1,NULL},
{0xe300653c ,22578504 ,-1,NULL},
{0xe300653e ,18092 ,-1,NULL},
{0xe300653f ,208416960 ,-1,NULL},
{0xe30066b9 ,2147456,-1,NULL},
{0xe30066b8 ,120870984 ,-1,NULL},
{0xe30066ba ,484260 ,-1,NULL},
{0xe30066bb ,9793648960 ,-1,NULL},
{0xe30068ad ,8438912,-1,NULL },
{0xe30068ac,553973472,-1,NULL}
};
int list = (sizeof(test_shm)/sizeof(test_shm[0]));
int shmflg;
int delete=0;
struct shmid_ds buf;
if(argc != 2)
{
printf(Usage: ./test_shm -c|-g|-d\n -c for create shared
memory\n -g for get shared memory\n -d delete the shared memory\n);
return(0);
}
if(strcmp(argv[1],-c) == 0)
{
shmflg = IPC_CREAT | 0666;
}else if(strcmp(argv[1],-g) == 0)
{
shmflg = 0666;
}else if(strcmp(argv[1],-d) == 0)
{
shmflg = 0666;
delete = 1;
}else{
printf(Usage: ./test_shm -c|-g|-d\n -c for create\n -g for get
shared memory\n -d delete the shared memory\n);
return(0);
}
for (i=0;i 'uname -a' output is
Linux mercury05 2.6.32-220.17.1.el6.x86_64 #1 SMP Thu Apr 26 13:37:13 EDT
2012 x86_64 x86_64 x86_64 GNU/Linux
using valgrind version 3.8.0 also shmat is failing with errno 22.
Thank you for that information. Is the process running in native 64-bit mode,
or is this a 32-bit [only] process whose environment is being emulated
by the x86_64 system?
Now, please try to construct a small test case which fails in the same way:
The test app calls shmat() and works without valgrind, but gets EINVAL
when run under valgrind-3.8.0. Post the actual code to this mailing list;
the code should be no more than a few dozen lines.
Here are some situations which might affect the results:
How many shared memory segments are attached by the app,
and how many other shared memory segments are active
at the same time in the whole system?
What is the mix of access permissions (ReadOnly, ReadWrite, ...)?
Were the shared memory segments created by the same process,
or did the segments exist already before the process began?
Is each shared memory segment being attached only once
by any particular process, or are there multiple mappings?
Is there any case which succeeds when (0!=shmaddr) ?
Attach using shmat(shmid, 0, 0); Remember the address;
Detach the segment; try to re-attach using shmat(shmid, old_addr, 0)
where old_addr is the address which was returned for the first
(successful) attach.
--
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
Re: [Valgrind-users] shmat parameters are modified by valgrind
The code was mangled by posting in HTML. Instead, use plain text (or an
attachment,
if the mailing list allows them.) I [attempt to] attach the code I used:
-rw-rw-r--. 1 jreiser jreiser 3125 Aug 14 09:30 shmtest.c
On my system, /usr/include/linux/shm.h says:
-
#define SHMMAX 0x200 /* max shared seg size (bytes) */
#define SHMMIN 1 /* min shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs system wide */
#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
#define SHMSEG SHMMNI/* max shared segs per process */
-
In particular, SHMMAX is only 32MiB, so several of the attempted shared segments
are too big. My current actual parameters in
$ cat /proc/sys/kernel/shmall
$ cat /proc/sys/kernel/shmmax
$ cat /proc/sys/kernel/shmmni
agree with the defaults that are in shm.h.
My test program works for me under valgrind-3.8.0 on Fedora 17 x86_64 in 64-bit
mode.
Linux host.domain 3.5.0-2.fc17.x86_64 #1 SMP Mon Jul 30 14:48:59 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
I [attempt to] attach the output that I get:
-rw-rw-r--. 1 jreiser jreiser 9321 Aug 14 09:31 shmtest.out
To see the system calls that valgrind sees:
valgrind --trace-syscalls=yes ...
Of course you can run that under strace, too, in order to verify
that valgrind actually does what it says it is doing:
strace valgrind --trace-syscalls=yes ...
but it is tedious to read the output.
--
#include sys/types.h
#include sys/shm.h
#include stdio.h
#include stdlib.h
struct shm_details
{
key_t key;
size_t size;
int shmid;
void *shm;
};
main(int argc,char **argv)
{
int i;
/* default SHMMAX is 32MB */
struct shm_details test_shm[] = {
{0xe300626d,2147456, -1, NULL },
{0xe300626c, 144271608, -1, NULL}, /* LARGE */
{0xe300626e, 115604, -1, NULL},
{0xe300626f, 118376704, -1, NULL}, /* LARGE */
{0xe300653d, 574592, -1, NULL},
{0xe300653c, 22578504, -1, NULL},
{0xe300653e, 18092, -1, NULL},
{0xe300653f, 208416960, -1, NULL}, /* LARGE */
{0xe30066b9,2147456, -1, NULL},
{0xe30066b8, 120870984, -1, NULL}, /* LARGE */
{0xe30066ba, 484260, -1, NULL},
{0xe30066bb, 9793648960, -1, NULL}, /* LARGE */
{0xe30068ad,8438912, -1, NULL},
{0xe30068ac, 553973472, -1, NULL} /* LARGE */
};
int n_err = 0;
int list = (sizeof(test_shm)/sizeof(test_shm[0]));
int shmflg;
int delete=0;
if (argc != 2) {
printf(Usage: ./test_shm -c|-g|-d\n -c for create shared memory\n -g for get shared memory\n -d delete the shared memory\n);
return(0);
}
if (strcmp(argv[1],-c) == 0) {
shmflg = IPC_CREAT | 0666;
}else if (strcmp(argv[1],-g) == 0) {
shmflg = 0666;
} else if (strcmp(argv[1],-d) == 0) {
shmflg = 0666;
delete = 1;
} else {
printf(Usage: ./test_shm -c|-g|-d\n -c for create\n -g for get shared memory\n -d delete the shared memory\n);
return(0);
}
n_err=0;
for (i=0;i sizeof(test_shm)/sizeof(test_shm[0]); ++i) {
test_shm[i].shmid = shmget(test_shm[i].key, test_shm[i].size, shmflg);
printf(\tid=%#8.8x = shmget(key=%#8.8x, size=%#8.8lx, flag=%#o)\n,
test_shm[i].shmid, test_shm[i].key, test_shm[i].size, shmflg);
if (test_shm[i].shmid == -1) {
perror(shmget);
printf(ERROR: shmget failed for shmkey=0x%)x\n, test_shm[i].key);
++n_err;
}
}
/*delete*/
n_err=0;
if (delete == 1) {
for (i=0;i sizeof(test_shm)/sizeof(test_shm[0]); ++i) {
struct shmid_ds buf;
int const r = shmctl(test_shm[i].shmid, IPC_RMID, buf);
printf(\tr=%d = shmctl(id=%#8.8x, op=%x)\n, r, test_shm[i].shmid, IPC_RMID);
if (r!=0) {
perror(shmctl);
printf(ERROR: shmctl failed for shmkey=0x%x)\n, test_shm[i].key);
++n_err;
}
}
printf(INFO: All shared memories are deleted\n);
return n_err;
}
/* Now we attach the segment to our data space. */
n_err=0;
for (i=0;i sizeof(test_shm)/sizeof(test_shm[0]); ++i) {
test_shm[i].shm = shmat(test_shm[i].shmid, 0, 0);
printf(\t%p = shmat(key=%#8.8x, 0, 0)\n, test_shm[i].shm, test_shm[i].shmid);
if (test_shm[i].shm == (char *) -1) {
perror(shmat);
printf(ERROR: shmat failed for shmkey=0x%x\n, test_shm[i].key);
++n_err;
}
}
n_err=0;
for (i=0;i sizeof(test_shm)/sizeof(test_shm[0]); ++i) {
int const r = shmdt(test_shm[i].shm);
printf(\t%#x = shmdt(addr=%p)\n, r, test_shm[i].shm);
if (r !=0 ) {
perror(shmat);
printf(ERROR: shmdt failed for shmkey=0x%x\n, test_shm[i].key);
++n_err;
}
return n_err;
}
printf(INFO: exit success\n);
return(0);
}
$ /usr/local/valgrind-3.8.0/bin/valgrind --tool=memcheck --leak-check=full
--track-origins=yes ./shmtest -c
==3629== Memcheck, a memory error detector
==3629== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3629== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==3629== Command: ./shmtest -c
==3629==
id=0x0035000e =
Re: [Valgrind-users] Valgrind for Windows update
On 13/08/2012 2:54 PM, Julian Seward wrote: Hi Christoph, Thanks for the update. It's great to hear this is being worked on. Hi Julian, nice to hear from you. I've been working on this project for about a year now, and I am 100% sure that there can be a working Valgrind for Windows one day. There are no unsolvable problems, it's only a matter of effort. However my time is limited so the reason for posting is to raise awareness about this project and hopefully attract more developers. Simple applications can be run, compiled with MSVC or GCC, even GUI ones (MessageBox). Memory errors (buffer overruns, uninitialized memory, memory leaks) are detected for 32 bit apps. The instrumentation, system calls -including callbacks from system calls-, function redirection, work in principle. The biggest issues right now are stability and making progress in the following areas: 1. debug information parsing, especially PDB, especially 64 bit 2. stack walking, both 32 and 64 bit 3. function redirection on 64 bit (32 bit seems to work) How well does it run GUI apps with --tool=none? I ask because 'none' does not require any debuginfor reading to work, and so it is a good test for how well your basic control-flow, memory management, etc, stuff works. --tool=none works much better than --tool=memcheck. I basically test with a simple MessageBox test program. I got the box pop up on Win32 and Win64 but not under Wow64. I can drag the box around and close it by clicking the button. I also tried to run Windows calculator. On Win32, the calculator displays and I can open the menu bar. However, if I click any menu item or button, the program stops abruptly. Win64 calculator stopped because of a misaligned memory access before displaying its window. I have not looked into those issues as my focus is on non-GUI applications. What are the problems with stack walking? Basically incomplete call stacks (displaying only one frame) or incorrect location information. I filed several tickets on V4Ws tracker describing the issues in detail. The current implementation uses dbghelp's StackWalk function, however I would prefer a solution that does not rely on this DLL but rather uses its own implementation, like Linux. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] DRD client request to disable CondRaceErr
I want to signal a pthread condition variable without holding the associated mutex. DRD (correctly) flags this as an error, but I want to suppress the error. I'd like to do it with a client request like DRD_IGNORE_VAR. I tried putting this on the cond and the mutex, and the error is still reported. Using --gen-suppressions won't work because there are lots of different stacks that trigger this, and the optimizer, especially with -flto, messes with the function names in a different way each time we build. Is there any other way to suppress this error? I see ANNOTATE_CONDVAR_* but they are all no-ops. -- Cheers, Leif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD client request to disable CondRaceErr
On Tuesday, August 14, 2012, Leif Walsh wrote: I want to signal a pthread condition variable without holding the associated mutex. Hmm, you really really want to do that and 110% understand the possible races that could result? I looked at a situation like this in NSPR some time back and found it extremely difficult to convince myself that the code was really safe. J -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD client request to disable CondRaceErr
On Tue, Aug 14, 2012 at 2:55 PM, Julian Seward jsew...@acm.org wrote: Hmm, you really really want to do that and 110% understand the possible races that could result? Yep, I really do want to do that. I really do not care about the race. I suppose I could switch to a semaphore or something and hope that makes it go away, but I would rather tell valgrind what I want than change my code to fit valgrind. I looked at a situation like this in NSPR some time back and found it extremely difficult to convince myself that the code was really safe. J -- Cheers, Leif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD client request to disable CondRaceErr
On Tuesday, August 14, 2012, Leif Walsh wrote: because there are lots of different stacks that trigger this, and the optimizer, especially with -flto, messes with the function names in a different way each time we build. Does it mess with the names so much that you can't use the * and ? wildcards, and the ... frame level wildcard, to reduce the number of suppressions to a manageable number? J -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD client request to disable CondRaceErr
This may work, I forgot you could use wildcards in function names. I'll come back if it doesn't. On Tue, Aug 14, 2012 at 3:46 PM, Julian Seward jsew...@acm.org wrote: On Tuesday, August 14, 2012, Leif Walsh wrote: because there are lots of different stacks that trigger this, and the optimizer, especially with -flto, messes with the function names in a different way each time we build. Does it mess with the names so much that you can't use the * and ? wildcards, and the ... frame level wildcard, to reduce the number of suppressions to a manageable number? J -- Cheers, Leif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] shmat parameters are modified by valgrind
On Tue, 2012-08-14 at 10:20 +, Adishesh wrote:
Hi,
I have used below program for testing. Below are the steps I have
followed.
Compile: gcc -g3 test_shm.c -o test_shm
Create shared memory: ./test_shm –c
Get shared memory without valgrind: ./test_shm –g ( this works fine)
Get with valgrind: /usr/bin/valgrind --tool=memcheck --leak-check=full
--track-origins=yes --log-file=/tmp/val_log /home/rtp99/test_shm –g
With valgrind shmat command fails.
Can you try again after applying the attached patch ?
Thanks
Philippe
Index: coregrind/m_syswrap/syswrap-generic.c
===
--- coregrind/m_syswrap/syswrap-generic.c (revision 12872)
+++ coregrind/m_syswrap/syswrap-generic.c (working copy)
@@ -1700,7 +1700,7 @@
/* -- */
static
-UInt get_shm_size ( Int shmid )
+SizeT get_shm_size ( Int shmid )
{
#ifdef __NR_shmctl
# ifdef VKI_IPC_64
@@ -1725,7 +1725,7 @@
if (sr_isError(__res))
return 0;
- return buf.shm_segsz;
+ return (SizeT) buf.shm_segsz;
}
UWord
@@ -1733,7 +1733,7 @@
UWord arg0, UWord arg1, UWord arg2 )
{
/* void *shmat(int shmid, const void *shmaddr, int shmflg); */
- UInt segmentSize = get_shm_size ( arg0 );
+ SizeT segmentSize = get_shm_size ( arg0 );
UWord tmp;
Bool ok;
if (arg1 == 0) {
@@ -1768,7 +1768,7 @@
UWord res,
UWord arg0, UWord arg1, UWord arg2 )
{
- UInt segmentSize = VG_PGROUNDUP(get_shm_size(arg0));
+ SizeT segmentSize = VG_PGROUNDUP(get_shm_size(arg0));
if ( segmentSize 0 ) {
UInt prot = VKI_PROT_READ|VKI_PROT_WRITE;
Bool d;
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
