Home / Browse / Valgrind, an open-source memory debugger / Mail / Archive

Valgrind, an open-source memory debugger

Email Archive: valgrind-users (read-only)

2003:	_Jan	_Feb	_Mar (58)	_Apr (261)	_May (169)	_Jun (214)	_Jul (201)	_Aug (219)	_Sep (198)	_Oct (203)	_Nov (241)	_Dec (94)
2004:	_Jan (137)	_Feb (149)	_Mar (150)	_Apr (193)	_May (95)	_Jun (173)	_Jul (137)	_Aug (236)	_Sep (157)	_Oct (150)	_Nov (136)	_Dec (90)
2005:	_Jan (139)	_Feb (130)	_Mar (274)	_Apr (138)	_May (184)	_Jun (152)	_Jul (261)	_Aug (409)	_Sep (239)	_Oct (241)	_Nov (260)	_Dec (137)
2006:	_Jan (191)	_Feb (142)	_Mar (169)	_Apr (75)	_May (141)	_Jun (169)	_Jul (131)	_Aug (141)	_Sep (192)	_Oct (176)	_Nov (142)	_Dec (95)
2007:	_Jan (98)	_Feb (120)	_Mar (93)	_Apr (96)	_May (95)	_Jun (65)	_Jul (62)	_Aug (56)	_Sep (53)	_Oct (95)	_Nov (106)	_Dec (87)
2008:	_Jan (58)	_Feb (149)	_Mar (175)	_Apr (110)	_May (106)	_Jun (72)	_Jul (55)	_Aug (89)	_Sep (26)	_Oct (96)	_Nov (83)	_Dec (93)
2009:	_Jan (97)	_Feb (106)	_Mar (74)	_Apr (64)	_May (115)	_Jun (83)	_Jul (137)	_Aug (103)	_Sep (56)	_Oct (59)	_Nov (61)	_Dec (37)
2010:	_Jan (94)	_Feb (71)	_Mar (53)	_Apr (105)	_May (79)	_Jun (111)	_Jul (110)	_Aug (81)	_Sep (50)	_Oct (82)	_Nov (49)	_Dec (21)
2011:	_Jan (87)	_Feb (105)	_Mar (108)	_Apr (99)	_May (91)	_Jun (94)	_Jul (114)	_Aug (77)	_Sep (58)	_Oct (58)	_Nov (131)	_Dec (62)
2012:	_Jan (76)	_Feb (93)	_Mar (68)	_Apr (95)	_May (62)	_Jun (109)	_Jul (90)	_Aug (87)	_Sep (49)	_Oct (54)	_Nov (66)	_Dec (84)
2013:	_Jan (67)	_Feb (52)	_Mar (93)	_Apr (65)	_May (33)	_Jun (21)	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec


S	M	T	W	T	F	S
				1	2	3
					(1)
4	5	6	7	8	9	10
			(10)	(6)	(2)
11	12	13	14	15	16	17
	(3)	(9)	(10)	(2)	(1)
18	19	20	21	22	23	24
(1)	(2)	(7)	(2)	(7)	(11)	(5)
25	26	27	28	29	30
(3)	(8)	(7)	(8)		(1)

Re: [Valgrind-users] =?iso-8859-1?q?helgrind_=3A_sem=5Fwait_succeeded?= =?iso-8859-1?q?_on_semaphore=09without_prior_sem=5Fpost?=

From: Julian Seward <jseward@ac...> - 2007-11-30 11:12

Fixed (svn r7253).  Semphores with nonzero initial values should be
handled correctly now.

J

On Friday 23 November 2007 13:10, Matthieu CASTET wrote:
> Julian Seward <jseward <at> acm.org> writes:
> > Good point.  I guess it should check only that sem_wait cannot
> > succeed on a semaphore whose value is zero.  But Helgrind does
> > not track the value of the semaphore, so this check should
> > just disappear.
> >
> > Can you send a simple test program?
>
> #include <semaphore.h>
>
> int main()
> {
> 	sem_t sem;
>
> 	sem_init(&sem, 0, 1);
> 	sem_wait(&sem);
> 	return 0;
> }
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] corruption inside the object on the heap

From: Pawel K <pawlaczus@ya...> - 2007-11-28 15:25

> There is no heap corruption in this program :(
> You only rewrite m_country field.
> I think that such errors can be detected only if the
> program is compiled
> with some special instrumentation code.
> 
> If you program did 'strcpy ( m_sName,
> "SECNMZZZZZZZZZZZZZZZ" );' valgrind
> would have detected it...
> valgrind will also detect this bug if you exchange
> m_sName and m_country in
> your class definition.

> >
> > class Human
> > {
> >  char m_name[3];
> >  char m_sName[3];
> >  char *m_country;
> >
> > public:
> >
> >  void SetDefNames ( void )
> >  {
> >    strcpy ( m_name, "NM" );
> >    m_country = "ID";
> >    strcpy ( m_sName, "SECNM" ); // !!! corrupts
> > m_country pointer !!!
> >  }
> > };
> >
> > int main ( void )
> > {
> >  Human *human = new Human;
> >  human -> SetDefNames ();
> >  return 0;
> > }

What instrumentation code do you mean ?
Could you give me some indications please.

I thought it would be great to force Valgrind to
generate the log of all write operations (in
particular in a heap).
Each entry could consist of the address (symbol) and
lengths of written data.

After the program crash one could find when the
variable/poiter was overwritten.

Is it possible to write such a tool in Valgrind ?
Is it difficult to do that ?

thank you for an answer


      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs

Re: [Valgrind-users] corruption inside the object on the heap

From: Nicholas Nethercote <njn@cs...> - 2007-11-28 21:11

On Wed, 28 Nov 2007, Pawel K wrote:

> I thought it would be great to force Valgrind to generate the log of all 
> write operations (in particular in a heap). Each entry could consist of 
> the address (symbol) and lengths of written data.
>
> After the program crash one could find when the variable/poiter was 
> overwritten.
>
> Is it possible to write such a tool in Valgrind ?
> Is it difficult to do that ?

It's not hard.  Run "valgrind --tool=lackey --trace-mem=yes <prog>".  You 
get a huge amount of output, though.

Nick

[Valgrind-users] Strange Invalid read errors:

From: Christoph Bartoschek <bartoschek@or...> - 2007-11-28 13:45

Hi, 

I get the following error that sounds strange to me:

Invalid read of size 8
   at 0x6AA37C: XR_GBoxList_Next (xrgbox.h:3208)
   by 0x6B8E7D: xrDiffAndCompressPwrPAreaBlkTogether (XrBlk.c:1152)
   by 0x6B96C7: xrCompressPwrPAreaBlockages (XrBlk.c:1338)
   by 0x6B9A78: xrCompressBlockages (XrBlk.c:1501)
   by 0x6BC676: XrXi_SetupBlockages (XrBlk.c:2468)
   by 0x69E375: XrXi_vGenPhysicalData (XrXi.c:3572)
   by 0x64DD70: XRIo_Setup (xrio.c:1640)
   by 0x436B71: XRLo_InitializeLocalRouter (xrlroute.c:1347)
   by 0x41E053: main (xrlocal.c:119)
 Address 0x8cd8bd058 is 8 bytes inside a block of size 32 alloc'd
   at 0x5F29E2B: malloc (vg_replace_malloc.c:207)
   by 0xA6274D: XR_MD_Alloc (xrcntext.c:237)
   by 0x6A9C04: XR_GBoxList_Ins (xrgbox.h:2920)
   by 0x6B8C91: xrDiffAndCompressPwrPAreaBlkTogether (XrBlk.c:1134)
   by 0x6B96C7: xrCompressPwrPAreaBlockages (XrBlk.c:1338)
   by 0x6B9A78: xrCompressBlockages (XrBlk.c:1501)
   by 0x6BC676: XrXi_SetupBlockages (XrBlk.c:2468)
   by 0x69E375: XrXi_vGenPhysicalData (XrXi.c:3572)
   by 0x64DD70: XRIo_Setup (xrio.c:1640)
   by 0x436B71: XRLo_InitializeLocalRouter (xrlroute.c:1347)
   by 0x41E053: main (xrlocal.c:119)

What bothers me is:

1. We do not use any client requests to mark memory as unaddressable. 
2. The memory block is malloced and given to the client. The client writes to 
it directly after allocation.
3. The error does only appear on Xeon machines. Not on opteron machines.
4. It only appears when the client uses about 64 GiB of the 64 GiB available.

Currently we suspect that the error is due to the Xeon architecture (CPU or 
mainboard or memory or linux kernel).

Does anyone have an explanation for such an error? Or a hint on how to verify 
that it is an error of the architecture?

Christoph

Re: [Valgrind-users] Strange Invalid read errors:

From: Julian Seward <jseward@ac...> - 2007-11-28 14:08

You sure this isn't to do with realloc?  What message do you
get if you malloc, then realloc the pointer, then read/write
the old pointer?

J

On Wednesday 28 November 2007 14:45, Christoph Bartoschek wrote:
> Hi,
>
> I get the following error that sounds strange to me:
>
> Invalid read of size 8
>    at 0x6AA37C: XR_GBoxList_Next (xrgbox.h:3208)
>    by 0x6B8E7D: xrDiffAndCompressPwrPAreaBlkTogether (XrBlk.c:1152)
>    by 0x6B96C7: xrCompressPwrPAreaBlockages (XrBlk.c:1338)
>    by 0x6B9A78: xrCompressBlockages (XrBlk.c:1501)
>    by 0x6BC676: XrXi_SetupBlockages (XrBlk.c:2468)
>    by 0x69E375: XrXi_vGenPhysicalData (XrXi.c:3572)
>    by 0x64DD70: XRIo_Setup (xrio.c:1640)
>    by 0x436B71: XRLo_InitializeLocalRouter (xrlroute.c:1347)
>    by 0x41E053: main (xrlocal.c:119)
>  Address 0x8cd8bd058 is 8 bytes inside a block of size 32 alloc'd
>    at 0x5F29E2B: malloc (vg_replace_malloc.c:207)
>    by 0xA6274D: XR_MD_Alloc (xrcntext.c:237)
>    by 0x6A9C04: XR_GBoxList_Ins (xrgbox.h:2920)
>    by 0x6B8C91: xrDiffAndCompressPwrPAreaBlkTogether (XrBlk.c:1134)
>    by 0x6B96C7: xrCompressPwrPAreaBlockages (XrBlk.c:1338)
>    by 0x6B9A78: xrCompressBlockages (XrBlk.c:1501)
>    by 0x6BC676: XrXi_SetupBlockages (XrBlk.c:2468)
>    by 0x69E375: XrXi_vGenPhysicalData (XrXi.c:3572)
>    by 0x64DD70: XRIo_Setup (xrio.c:1640)
>    by 0x436B71: XRLo_InitializeLocalRouter (xrlroute.c:1347)
>    by 0x41E053: main (xrlocal.c:119)
>
> What bothers me is:
>
> 1. We do not use any client requests to mark memory as unaddressable.
> 2. The memory block is malloced and given to the client. The client writes
> to it directly after allocation.
> 3. The error does only appear on Xeon machines. Not on opteron machines.
> 4. It only appears when the client uses about 64 GiB of the 64 GiB
> available.
>
> Currently we suspect that the error is due to the Xeon architecture (CPU or
> mainboard or memory or linux kernel).
>
> Does anyone have an explanation for such an error? Or a hint on how to
> verify that it is an error of the architecture?
>
> Christoph
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Strange Invalid read errors:

From: Christoph Bartoschek <bartoschek@or...> - 2007-11-28 14:33

Am Mittwoch, 28. November 2007 schrieb Julian Seward:
> You sure this isn't to do with realloc?  What message do you
> get if you malloc, then realloc the pointer, then read/write
> the old pointer?

The whole program does not use realloc. However the message looks different:

==696== Invalid read of size 4
==696==    at 0x4008E4: main (in /lfs/user/bartosch/real)
==696==  Address 0x411f010 is 0 bytes inside a block of size 1,924 free'd
==696==    at 0x4A20F02: realloc (vg_replace_malloc.c:420)
==696==    by 0x4008B1: main (in /lfs/user/bartosch/real)

Christoph

Re: [Valgrind-users] Strange Invalid read errors:

From: Christoph Bartoschek <bartoschek@or...> - 2007-11-28 18:24

Am Mittwoch, 28. November 2007 schrieb Julian Seward:
> You sure this isn't to do with realloc?  What message do you
> get if you malloc, then realloc the pointer, then read/write
> the old pointer?

Hi,

I could now verify that it is a hardware problem. A small program reads and 
writes data into distinguished blocks with several threads. Sometimes a value 
read back is different from the written value.

This error is not specific for the memory banks because the error occurs on 
three machines with the same cpu, mainboard and os.  On a machine with 
different cpu and mainboard it does not occur.

Thanks,
Christoph

Re: [Valgrind-users] Strange Invalid read errors:

From: Nicholas Nethercote <njn@cs...> - 2007-11-28 21:09

On Wed, 28 Nov 2007, Christoph Bartoschek wrote:

> I could now verify that it is a hardware problem. A small program reads and
> writes data into distinguished blocks with several threads. Sometimes a value
> read back is different from the written value.

Yikes.  Well, at least it's not Valgrind's fault...  thanks for the update.

N

Re: [Valgrind-users] intel debug minimal and line numbers

From: Madhan Sadasivam <madhansivam@gm...> - 2007-11-28 06:01

Attachments: Message as HTML readelf.txt

LS0tIC4uLy4uLy4uL3ZhbGdyaW5kLTMuMi4zX29yZy9jb3JlZ3JpbmQvbV9kZWJ1Z2luZm8vcmVh
ZGR3YXJmLmMJMjAwNy0xMS0xOSAwODoyMjo0NC4wMDAwMDAwMDAgLTA4MDAKKysrIC4vcmVhZGR3
YXJmLmMJMjAwNy0xMS0yMSAxMDo1Mzo0OS4wMDAwMDAwMDAgLTA4MDAKQEAgLTE5Myw2ICsxOTMs
OSBAQAogICBJbnQgICBpc19zdG10OwogICBJbnQgICBiYXNpY19ibG9jazsKICAgSW50ICAgZW5k
X3NlcXVlbmNlOworICAvKiBUaGlzIHZhcmlhYmxlIGhvbGQgdGhlIG51bWJlciBvZiB0aGUgbGFz
dCBlbnRyeSBzZWVuCisgICAgIGluIHRoZSBGaWxlIFRhYmxlLiAgKi8KKyAgVUludCAgbGFzdF9m
aWxlX2VudHJ5OwogfSBTTVI7CiAKIApAQCAtMjgyLDYgKzI4NSw3IEBACiAgICBzdGF0ZV9tYWNo
aW5lX3JlZ3MuaXNfc3RtdCA9IGlzX3N0bXQ7CiAgICBzdGF0ZV9tYWNoaW5lX3JlZ3MuYmFzaWNf
YmxvY2sgPSAwOwogICAgc3RhdGVfbWFjaGluZV9yZWdzLmVuZF9zZXF1ZW5jZSA9IDA7CisgIHN0
YXRlX21hY2hpbmVfcmVncy5sYXN0X2ZpbGVfZW50cnkgPSAwOwogfQogCiAvKiBMb29rIHVwIGEg
ZGlyZWN0b3J5IG5hbWUsIG9yIHJldHVybiBOVUxMIGlmIHVua25vd24uICovCkBAIC0xMDExLDYg
KzEwMTUsNDMzIEBACiAgICB9CiB9CiAKKy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCisvLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLworCisvKiBT
dHJ1Y3R1cmUgZm91bmQgaW4gdGhlIC5kZWJ1Z19saW5lIHNlY3Rpb24uICAqLwordHlwZWRlZiBz
dHJ1Y3QKK3sKKyAgVUNoYXIgbGlfbGVuZ3RoICAgICAgICAgIFs0XTsKKyAgVUNoYXIgbGlfdmVy
c2lvbiAgICAgICAgIFsyXTsKKyAgVUNoYXIgbGlfcHJvbG9ndWVfbGVuZ3RoIFs0XTsKKyAgVUNo
YXIgbGlfbWluX2luc25fbGVuZ3RoIFsxXTsKKyAgVUNoYXIgbGlfZGVmYXVsdF9pc19zdG10IFsx
XTsKKyAgVUNoYXIgbGlfbGluZV9iYXNlICAgICAgIFsxXTsKKyAgVUNoYXIgbGlfbGluZV9yYW5n
ZSAgICAgIFsxXTsKKyAgVUNoYXIgbGlfb3Bjb2RlX2Jhc2UgICAgIFsxXTsKK30KK0RXQVJGMl9F
eHRlcm5hbF9MaW5lSW5mbzsKKwordHlwZWRlZiBzdHJ1Y3QKK3sKKyAgVUludCAgIGxpX2xlbmd0
aDsKKyAgVVNob3J0IGxpX3ZlcnNpb247CisgIFVJbnQgICBsaV9wcm9sb2d1ZV9sZW5ndGg7Cisg
IFVDaGFyICBsaV9taW5faW5zbl9sZW5ndGg7CisgIFVDaGFyICBsaV9kZWZhdWx0X2lzX3N0bXQ7
CisgIEludCAgICBsaV9saW5lX2Jhc2U7CisgIFVDaGFyICBsaV9saW5lX3JhbmdlOworICBVQ2hh
ciAgbGlfb3Bjb2RlX2Jhc2U7Cit9IAorRFdBUkYyX0ludGVybmFsX0xpbmVJbmZvOworCisKKy8q
IEhhbmRsZWQgYW4gZXh0ZW5kIGxpbmUgb3AuICBSZXR1cm5zIHRydWUgaWYgdGhpcyBpcyB0aGUg
ZW5kCisgICBvZiBzZXF1ZW5jZS4gIC0gMi40LjEgdmVyc2lvbiovCitzdGF0aWMgCitpbnQgcHJv
Y2Vzc19leHRlbmRlZF9saW5lX29wMiggc3RydWN0IF9TZWdJbmZvKiBzaSwgT2ZmVCBkZWJ1Z19v
ZmZzZXQsIAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoYXIqKiogZm5hbWVzLCAK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVQ2hhciogZGF0YSwgCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgSW50IGlzX3N0bXQsIAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEludCBwb2ludGVyX3NpemUpCit7CisgIFVDaGFyICAgb3BfY29kZTsKKyAgSW50
ICAgICBieXRlc19yZWFkOworICBVSW50ICAgIGxlbjsKKyAgVUNoYXIgKiBuYW1lOworICBBZGRy
ICAgIGFkcjsKKworICBsZW4gPSByZWFkX2xlYjEyOCAoZGF0YSwgJiBieXRlc19yZWFkLCAwKTsK
KyAgZGF0YSArPSBieXRlc19yZWFkOworCisgIGlmIChsZW4gPT0gMCkKKyAgICB7CisgICAgICBW
R18obWVzc2FnZSkoVmdfVXNlck1zZywKKyAgICAgICAgICJiYWRseSBmb3JtZWQgZXh0ZW5kZWQg
bGluZSBvcCBlbmNvdW50ZXJlZCFcbiIpOworICAgICAgcmV0dXJuIGJ5dGVzX3JlYWQ7CisgICAg
fQorCisgIGxlbiArPSBieXRlc19yZWFkOworICBvcF9jb2RlID0gKiBkYXRhICsrOworCisgIGlm
ICgwKSBWR18ocHJpbnRmKSgiZHdhcmYyOiBleHQgT1BDOiAlZFxuIiwgb3BfY29kZSk7CisKKyAg
c3dpdGNoIChvcF9jb2RlKQorICAgIHsKKyAgICBjYXNlIERXX0xORV9lbmRfc2VxdWVuY2U6Cisg
ICAgICBpZiAoMCkgVkdfKHByaW50ZikoIjEwMDE6IHNpLT5vICVwLCBzbXIuYSAlcFxuIiwgCisg
ICAgICAgICAgICAgICAgICAgICAgICAgZGVidWdfb2Zmc2V0LCBzdGF0ZV9tYWNoaW5lX3JlZ3Mu
YWRkcmVzcyApOworICAgICAgc3RhdGVfbWFjaGluZV9yZWdzLmVuZF9zZXF1ZW5jZSA9IDE7IC8q
IEpSUzogYWRkZWQgZm9yIGNvbXBsaWFuY2UKKyAgICAgICAgIHdpdGggc3BlYzsgaXMgcG9pbnRs
ZXNzIGR1ZSB0byByZXNldF9zdGF0ZV9tYWNoaW5lIGJlbG93IAorICAgICAgKi8KKyAgICAgIGlm
IChzdGF0ZV9tYWNoaW5lX3JlZ3MuaXNfc3RtdCkgeworCSBpZiAoc3RhdGVfbWFjaGluZV9yZWdz
Lmxhc3RfYWRkcmVzcykKKwkgICAgTUxfKGFkZExpbmVJbmZvKSAoc2ksICgqZm5hbWVzKVtzdGF0
ZV9tYWNoaW5lX3JlZ3MubGFzdF9maWxlXSwgCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBOVUxMLAorCQkJICAgICAgZGVidWdfb2Zmc2V0ICsgc3RhdGVfbWFjaGluZV9yZWdzLmxhc3Rf
YWRkcmVzcywgCisJCQkgICAgICBkZWJ1Z19vZmZzZXQgKyBzdGF0ZV9tYWNoaW5lX3JlZ3MuYWRk
cmVzcywgCisJCQkgICAgICBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9saW5lLCAwKTsKKyAgICAg
IH0KKyAgICAgIHJlc2V0X3N0YXRlX21hY2hpbmUgKGlzX3N0bXQpOworICAgICAgYnJlYWs7CisK
KyAgICBjYXNlIERXX0xORV9zZXRfYWRkcmVzczoKKyAgICAgIC8qIFhYWDogUG9pbnRlciBzaXpl
IGNvdWxkIGJlIDggKi8KKyAgICAgIHZnX2Fzc2VydChwb2ludGVyX3NpemUgPT0gNCk7CisgICAg
ICBhZHIgPSAqKChBZGRyICopZGF0YSk7CisgICAgICBpZiAoMCkgVkdfKHByaW50ZikoInNtci5h
IDo9ICVwXG4iLCBhZHIgKTsKKyAgICAgIHN0YXRlX21hY2hpbmVfcmVncy5hZGRyZXNzID0gYWRy
OworICAgICAgYnJlYWs7CisKKyAgICBjYXNlIERXX0xORV9kZWZpbmVfZmlsZToKKyAgICAgICsr
IHN0YXRlX21hY2hpbmVfcmVncy5sYXN0X2ZpbGVfZW50cnk7CisgICAgICBuYW1lID0gZGF0YTsK
KyAgICAgIGlmICgqZm5hbWVzID09IE5VTEwpCisgICAgICAgICpmbmFtZXMgPSBWR18oYXJlbmFf
bWFsbG9jKShWR19BUl9TWU1UQUIsIHNpemVvZiAoVUludCkgKiAyKTsKKyAgICAgIGVsc2UKKyAg
ICAgICAgKmZuYW1lcyA9IFZHXyhhcmVuYV9yZWFsbG9jKSgKKyAgICAgICAgICAgICAgICAgICAg
IFZHX0FSX1NZTVRBQiwgKmZuYW1lcywKKyAgICAgICAgICAgICAgICAgICAgIHNpemVvZihVSW50
KSAKKyAgICAgICAgICAgICAgICAgICAgICAgICogKHN0YXRlX21hY2hpbmVfcmVncy5sYXN0X2Zp
bGVfZW50cnkgKyAxKSk7CisgICAgICAoKmZuYW1lcylbc3RhdGVfbWFjaGluZV9yZWdzLmxhc3Rf
ZmlsZV9lbnRyeV0gPSBNTF8oYWRkU3RyKSAoc2ksbmFtZSwgLTEpOworICAgICAgZGF0YSArPSBW
R18oc3RybGVuKSAoKGNoYXIgKikgZGF0YSkgKyAxOworICAgICAgcmVhZF9sZWIxMjggKGRhdGEs
ICYgYnl0ZXNfcmVhZCwgMCk7CisgICAgICBkYXRhICs9IGJ5dGVzX3JlYWQ7CisgICAgICByZWFk
X2xlYjEyOCAoZGF0YSwgJiBieXRlc19yZWFkLCAwKTsKKyAgICAgIGRhdGEgKz0gYnl0ZXNfcmVh
ZDsKKyAgICAgIHJlYWRfbGViMTI4IChkYXRhLCAmIGJ5dGVzX3JlYWQsIDApOworICAgICAgYnJl
YWs7CisKKyAgICBkZWZhdWx0OgorICAgICAgYnJlYWs7CisgICAgfQorCisgIHJldHVybiBsZW47
Cit9CisKKworCisvKiBDb2xsZWN0IHRoZSBkZWJ1ZyBpbmZvIGZyb20gZHdhcmYyIGRlYnVnZ2lu
ZyBzZWN0aW9ucworICogb2YgYSBnaXZlbiBtb2R1bGUuCisgKiAKKyAqIElucHV0czogZ2l2ZW4g
LmRlYnVnX3h4eCBzZWN0aW9ucworICogT3V0cHV0OiB1cGRhdGUgc2kgdG8gY29udGFpbiBhbGwg
dGhlIGR3YXJmMiBkZWJ1ZyBpbmZvcworICovCit2b2lkIE1MXyhyZWFkX2RlYnVnbGluZWluZm9f
ZHdhcmYyKSAKKyAgICAgICAgKCBzdHJ1Y3QgX1NlZ0luZm8qIHNpLCBPZmZUIGRlYnVnX29mZnNl
dCwKKyAgICAgICAgICBVQ2hhciogZGVidWdpbmZvLCAgIEludCBkZWJ1Z19pbmZvX3N6LCAgLyog
LmRlYnVnX2luZm8gKi8KKyAgICAgICAgICBVQ2hhciogZGVidWdhYmJyZXYsICAgICAgICAgICAg
ICAgICAgICAgLyogLmRlYnVnX2FiYnJldiAqLworICAgICAgICAgIFVDaGFyKiBkd2FyZjIsIElu
dCBkd2FyZjJfc3osICAgICAgICAgICAvKiAuZGVidWdfbGluZSAqLworICAgICAgICAgIFVDaGFy
KiBkZWJ1Z3N0ciApICAgICAgICAgICAgICAgICAgICAgICAvKiAuZGVidWdfc3RyICovCit7Cisg
IERXQVJGMl9FeHRlcm5hbF9MaW5lSW5mbyAqIGV4dGVybmFsOworICBEV0FSRjJfSW50ZXJuYWxf
TGluZUluZm8gICBpbmZvOworICBVQ2hhciAqICAgICAgICAgICAgc3RhbmRhcmRfb3Bjb2RlczsK
KyAgVUNoYXIgKiAgICAgICAgICAgIGRhdGEgPSBkd2FyZjI7CisgIFVDaGFyICogICAgICAgICAg
ICBlbmQgID0gZHdhcmYyICsgZHdhcmYyX3N6OworICBVQ2hhciAqICAgICAgICAgICAgZW5kX29m
X3NlcXVlbmNlOworICBDaGFyICAqKiAgICAgICAgICAgZm5hbWVzID0gTlVMTDsKKworICAvKiBG
YWlscyBkdWUgdG8gZ2NjIHBhZGRpbmcgLi4uCisgIHZnX2Fzc2VydChzaXplb2YoRFdBUkYyX0V4
dGVybmFsX0xpbmVJbmZvKQorICAgICAgICAgICAgPT0gc2l6ZW9mKERXQVJGMl9JbnRlcm5hbF9M
aW5lSW5mbykpOworICAqLworCisgIHdoaWxlIChkYXRhIDwgZW5kKQorICAgIHsKKyAgICAgIGV4
dGVybmFsID0gKERXQVJGMl9FeHRlcm5hbF9MaW5lSW5mbyAqKSBkYXRhOworCisgICAgICAvKiBD
aGVjayB0aGUgbGVuZ3RoIG9mIHRoZSBibG9jay4gICovCisgICAgICBpbmZvLmxpX2xlbmd0aCA9
ICogKChVSW50ICopKGV4dGVybmFsLT5saV9sZW5ndGgpKTsKKworICAgICAgaWYgKGluZm8ubGlf
bGVuZ3RoID09IDB4ZmZmZmZmZmYpCisgICAgICAgeworICAgICAgICAgTUxfKHN5bWVycikoIjY0
LWJpdCBEV0FSRiBsaW5lIGluZm8gaXMgbm90IHN1cHBvcnRlZCB5ZXQuIik7CisgICAgICAgICBi
cmVhazsKKyAgICAgICB9CisKKyAgICAgIGlmIChpbmZvLmxpX2xlbmd0aCArIHNpemVvZiAoZXh0
ZXJuYWwtPmxpX2xlbmd0aCkgPiBkd2FyZjJfc3opCisgICAgICAgeworICAgICAgICBNTF8oc3lt
ZXJyKSgiRFdBUkYgbGluZSBpbmZvIGFwcGVhcnMgdG8gYmUgY29ycnVwdCAiCisgICAgICAgICAg
ICAgICAgICAiLSB0aGUgc2VjdGlvbiBpcyB0b28gc21hbGwiKTsKKyAgICAgICAgIHJldHVybjsK
KyAgICAgICB9CisKKyAgICAgIC8qIENoZWNrIGl0cyB2ZXJzaW9uIG51bWJlci4gICovCisgICAg
ICBpbmZvLmxpX3ZlcnNpb24gPSAqICgoVVNob3J0ICopIChleHRlcm5hbC0+bGlfdmVyc2lvbikp
OworICAgICAgaWYgKGluZm8ubGlfdmVyc2lvbiAhPSAyKQorICAgICAgIHsKKyAgICAgICAgIE1M
XyhzeW1lcnIpKCJPbmx5IERXQVJGIHZlcnNpb24gMiBsaW5lIGluZm8gIgorICAgICAgICAgICAg
ICAgICAgICJpcyBjdXJyZW50bHkgc3VwcG9ydGVkLiIpOworICAgICAgICAgcmV0dXJuOworICAg
ICAgIH0KKworICAgICAgaW5mby5saV9wcm9sb2d1ZV9sZW5ndGggPSAqICgoVUludCAqKSAoZXh0
ZXJuYWwtPmxpX3Byb2xvZ3VlX2xlbmd0aCkpOworICAgICAgaW5mby5saV9taW5faW5zbl9sZW5n
dGggPSAqICgoVUNoYXIgKikoZXh0ZXJuYWwtPmxpX21pbl9pbnNuX2xlbmd0aCkpOworCisgICAg
ICBpbmZvLmxpX2RlZmF1bHRfaXNfc3RtdCA9IFRydWU7IAorICAgICAgICAgLyogV0FTOiA9ICog
KChVQ2hhciAqKShleHRlcm5hbC0+bGlfZGVmYXVsdF9pc19zdG10KSk7ICovCisgICAgICAgICAv
KiBKb3NlZiBXZWlkZW5kb3JmZXIgKDIwMDIxMDIxKSB3cml0ZXM6CisKKyAgICAgICAgICAgIEl0
IHNlZW1zIHRvIG1lIHRoYXQgdGhlIEludGVsIEZvcnRyYW4gY29tcGlsZXIgZ2VuZXJhdGVzCisg
ICAgICAgICAgICBiYWQgRFdBUkYyIGxpbmUgaW5mbyBjb2RlOiBJdCBzZXRzICJpc19zdG10IiBv
ZiB0aGUgc3RhdGUKKyAgICAgICAgICAgIG1hY2hpbmUgaW4gdGhlIHRoZSBsaW5lIGluZm8gcmVh
ZGVyIHRvIGJlIGFsd2F5cworICAgICAgICAgICAgZmFsc2UuIFRodXMsIHRoZXJlIGlzIG5ldmVy
IGEgc3RhdGVtZW50IGJvdW5kYXJ5IGdlbmVyYXRlZAorICAgICAgICAgICAgYW5kIHRoZXJlZm9y
ZSBuZXZlciBhIGluc3RydWN0aW9uIHJhbmdlL2xpbmUgbnVtYmVyCisgICAgICAgICAgICBtYXBw
aW5nIGdlbmVyYXRlZCBmb3IgdmFsZ3JpbmQuCisKKyAgICAgICAgICAgIFBsZWFzZSBoYXZlIGEg
bG9vayBhdCB0aGUgRFdBUkYyIHNwZWNpZmljYXRpb24sIENoLiA2LjIKKyAgICAgICAgICAgICh4
ODYuZGRqLmNvbS9mdHAvbWFudWFscy90b29scy9kd2FyZi5wZGYpLiAgUGVyaGFwcyBJCisgICAg
ICAgICAgICB1bmRlcnN0YW5kIHRoaXMgd3JvbmcsIGJ1dCBJIGRvbid0IHRoaW5rIHNvLgorCisg
ICAgICAgICAgICBJIGp1c3QgaGFkIGEgbG9vayBhdCB0aGUgR0RCIERXQVJGMiByZWFkZXIuLi4g
IFRoZXkKKyAgICAgICAgICAgIGNvbXBsZXRlbHkgaWdub3JlICJpc19zdG10IiB3aGVuIHJlY29y
ZGluZyBsaW5lIGluZm8gOy0pCisgICAgICAgICAgICBUaGF0J3MgdGhlIHJlYXNvbiAib2JqZHVt
cCAtUyIgd29ya3Mgb24gZmlsZXMgZnJvbSB0aGUgdGhlCisgICAgICAgICAgICBpbnRlbCBmb3J0
cmFuIGNvbXBpbGVyLiAgCisgICAgICAgICAqLworCisKKyAgICAgIC8qIEpSUzogY2hhbmdlZCAo
VUludCopIHRvIChVQ2hhciopICovCisgICAgICBpbmZvLmxpX2xpbmVfYmFzZSAgICAgICA9ICog
KChVQ2hhciAqKShleHRlcm5hbC0+bGlfbGluZV9iYXNlKSk7CisKKyAgICAgIGluZm8ubGlfbGlu
ZV9yYW5nZSAgICAgID0gKiAoKFVDaGFyICopKGV4dGVybmFsLT5saV9saW5lX3JhbmdlKSk7Cisg
ICAgICBpbmZvLmxpX29wY29kZV9iYXNlICAgICA9ICogKChVQ2hhciAqKShleHRlcm5hbC0+bGlf
b3Bjb2RlX2Jhc2UpKTsgCisKKyAgICAgIGlmICgwKSBWR18ocHJpbnRmKSgiZHdhcmYyOiBsaW5l
IGJhc2U6ICVkLCByYW5nZSAlZCwgb3BjIGJhc2U6ICVkXG4iLAorCQkgIGluZm8ubGlfbGluZV9i
YXNlLCBpbmZvLmxpX2xpbmVfcmFuZ2UsIGluZm8ubGlfb3Bjb2RlX2Jhc2UpOworCisgICAgICAv
KiBTaWduIGV4dGVuZCB0aGUgbGluZSBiYXNlIGZpZWxkLiAgKi8KKyAgICAgIGluZm8ubGlfbGlu
ZV9iYXNlIDw8PSAyNDsKKyAgICAgIGluZm8ubGlfbGluZV9iYXNlID4+PSAyNDsKKworICAgICAg
ZW5kX29mX3NlcXVlbmNlID0gZGF0YSArIGluZm8ubGlfbGVuZ3RoIAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICArIHNpemVvZiAoZXh0ZXJuYWwtPmxpX2xlbmd0aCk7CisKKyAgICAgIHJl
c2V0X3N0YXRlX21hY2hpbmUgKGluZm8ubGlfZGVmYXVsdF9pc19zdG10KTsKKworICAgICAgLyog
UmVhZCB0aGUgY29udGVudHMgb2YgdGhlIE9wY29kZXMgdGFibGUuICAqLworICAgICAgc3RhbmRh
cmRfb3Bjb2RlcyA9IGRhdGEgKyBzaXplb2YgKCogZXh0ZXJuYWwpOworCisgICAgICAvKiBSZWFk
IHRoZSBjb250ZW50cyBvZiB0aGUgRGlyZWN0b3J5IHRhYmxlLiAgKi8KKyAgICAgIGRhdGEgPSBz
dGFuZGFyZF9vcGNvZGVzICsgaW5mby5saV9vcGNvZGVfYmFzZSAtIDE7CisKKyAgICAgIGlmICgq
IGRhdGEgPT0gMCkgCisgICAgICAgeworICAgICAgIH0KKyAgICAgIGVsc2UKKyAgICAgICB7Cisg
ICAgICAgICAvKiBXZSBpZ25vcmUgdGhlIGRpcmVjdG9yeSB0YWJsZSwgc2luY2UgZ2NjIGdpdmVz
IHRoZSBlbnRpcmUKKyAgICAgICAgICAgIHBhdGggYXMgcGFydCBvZiB0aGUgZmlsZW5hbWUgKi8K
KyAgICAgICAgIHdoaWxlICgqIGRhdGEgIT0gMCkKKyAgICAgICAgICAgeworICAgICAgICAgICAg
IGRhdGEgKz0gVkdfKHN0cmxlbikgKChjaGFyICopIGRhdGEpICsgMTsKKyAgICAgICAgICAgfQor
ICAgICAgIH0KKworICAgICAgLyogU2tpcCB0aGUgTlVMIGF0IHRoZSBlbmQgb2YgdGhlIHRhYmxl
LiAgKi8KKyAgICAgIGlmICgqZGF0YSAhPSAwKSB7CisgICAgICAgICBNTF8oc3ltZXJyKSgiY2Fu
J3QgZmluZCBOVUwgYXQgZW5kIG9mIERXQVJGMiBkaXJlY3RvcnkgdGFibGUiKTsKKyAgICAgICAg
IHJldHVybjsKKyAgICAgIH0KKyAgICAgIGRhdGEgKys7CisKKyAgICAgIC8qIFJlYWQgdGhlIGNv
bnRlbnRzIG9mIHRoZSBGaWxlIE5hbWUgdGFibGUuICAqLworICAgICAgaWYgKCogZGF0YSA9PSAw
KQorICAgICAgIHsKKyAgICAgICB9CisgICAgICBlbHNlCisgICAgICAgeworICAgICAgICAgd2hp
bGUgKCogZGF0YSAhPSAwKQorICAgICAgICAgICB7CisgICAgICAgICAgICAgVUNoYXIgKiBuYW1l
OworICAgICAgICAgICAgIEludCBieXRlc19yZWFkOworCisgICAgICAgICAgICAgKysgc3RhdGVf
bWFjaGluZV9yZWdzLmxhc3RfZmlsZV9lbnRyeTsKKyAgICAgICAgICAgICBuYW1lID0gZGF0YTsK
KyAgICAgICAgICAgICAvKiBTaW5jZSB3ZSBkb24ndCBoYXZlIHJlYWxsb2MgKDAsIC4uLi4pID09
IG1hbGxvYyAoLi4uKQorCQlzZW1hbnRpY3MsIHdlIG5lZWQgdG8gbWFsbG9jIHRoZSBmaXJzdCB0
aW1lLiAqLworCisgICAgICAgICAgICAgaWYgKGZuYW1lcyA9PSBOVUxMKQorICAgICAgICAgICAg
ICAgZm5hbWVzID0gVkdfKGFyZW5hX21hbGxvYykoVkdfQVJfU1lNVEFCLCBzaXplb2YgKFVJbnQp
ICogMik7CisgICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgZm5hbWVzID0gVkdfKGFy
ZW5hX3JlYWxsb2MpKFZHX0FSX1NZTVRBQiwgZm5hbWVzLAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc2l6ZW9mKFVJbnQpIAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiAoc3Rh
dGVfbWFjaGluZV9yZWdzLmxhc3RfZmlsZV9lbnRyeSArIDEpKTsKKyAgICAgICAgICAgICBkYXRh
ICs9IFZHXyhzdHJsZW4pICgoQ2hhciAqKSBkYXRhKSArIDE7CisgICAgICAgICAgICAgZm5hbWVz
W3N0YXRlX21hY2hpbmVfcmVncy5sYXN0X2ZpbGVfZW50cnldID0gTUxfKGFkZFN0cikgKHNpLG5h
bWUsIC0xKTsKKworICAgICAgICAgICAgIHJlYWRfbGViMTI4IChkYXRhLCAmIGJ5dGVzX3JlYWQs
IDApOworICAgICAgICAgICAgIGRhdGEgKz0gYnl0ZXNfcmVhZDsKKyAgICAgICAgICAgICByZWFk
X2xlYjEyOCAoZGF0YSwgJiBieXRlc19yZWFkLCAwKTsKKyAgICAgICAgICAgICBkYXRhICs9IGJ5
dGVzX3JlYWQ7CisgICAgICAgICAgICAgcmVhZF9sZWIxMjggKGRhdGEsICYgYnl0ZXNfcmVhZCwg
MCk7CisgICAgICAgICAgICAgZGF0YSArPSBieXRlc19yZWFkOworCisgICAgICAgICAgICAgaWYg
KDApIFZHXyhwcmludGYpKCJmaWxlICVzXG4iLCAgCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGZuYW1lc1tzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9maWxlX2VudHJ5XSk7CisgICAg
ICAgICAgIH0KKyAgICAgICB9CisKKyAgICAgIC8qIFNraXAgdGhlIE5VTCBhdCB0aGUgZW5kIG9m
IHRoZSB0YWJsZS4gICovCisgICAgICBpZiAoKmRhdGEgIT0gMCkgeworICAgICAgICAgTUxfKHN5
bWVycikoImNhbid0IGZpbmQgTlVMIGF0IGVuZCBvZiBEV0FSRjIgZmlsZSBuYW1lIHRhYmxlIik7
CisgICAgICAgICByZXR1cm47CisgICAgICB9CisgICAgICBkYXRhICsrOworCisgICAgICAvKiBO
b3cgZGlzcGxheSB0aGUgc3RhdGVtZW50cy4gICovCisKKyAgICAgIHdoaWxlIChkYXRhIDwgZW5k
X29mX3NlcXVlbmNlKQorICAgICAgIHsKKyAgICAgICAgIFVDaGFyIG9wX2NvZGU7CisgICAgICAg
ICBJbnQgICAgICAgICAgIGFkdjsKKyAgICAgICAgIEludCAgICAgICAgICAgYnl0ZXNfcmVhZDsK
KworICAgICAgICAgb3BfY29kZSA9ICogZGF0YSArKzsKKworCSBpZiAoMCkgVkdfKHByaW50Ziko
ImR3YXJmMjogT1BDOiAlZFxuIiwgb3BfY29kZSk7CisKKyAgICAgICAgIGlmIChvcF9jb2RlID49
IGluZm8ubGlfb3Bjb2RlX2Jhc2UpCisgICAgICAgICAgIHsKKyAgICAgICAgICAgICBJbnQgYWR2
QWRkcjsKKyAgICAgICAgICAgICBvcF9jb2RlIC09IGluZm8ubGlfb3Bjb2RlX2Jhc2U7CisgICAg
ICAgICAgICAgYWR2ICAgICAgPSAob3BfY29kZSAvIGluZm8ubGlfbGluZV9yYW5nZSkgCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAqIGluZm8ubGlfbWluX2luc25fbGVuZ3RoOworICAgICAg
ICAgICAgIGFkdkFkZHIgPSBhZHY7CisgICAgICAgICAgICAgc3RhdGVfbWFjaGluZV9yZWdzLmFk
ZHJlc3MgKz0gYWR2OworICAgICAgICAgICAgIGlmICgwKSBWR18ocHJpbnRmKSgic21yLmEgKz0g
JXBcbiIsIGFkdiApOworICAgICAgICAgICAgIGFkdiA9IChvcF9jb2RlICUgaW5mby5saV9saW5l
X3JhbmdlKSArIGluZm8ubGlfbGluZV9iYXNlOworICAgICAgICAgICAgIGlmICgwKSBWR18ocHJp
bnRmKSgiMTAwMjogc2ktPm8gJXAsIHNtci5hICVwXG4iLCAKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZGVidWdfb2Zmc2V0LCBzdGF0ZV9tYWNoaW5lX3JlZ3MuYWRkcmVzcyApOwor
ICAgICAgICAgICAgIHN0YXRlX21hY2hpbmVfcmVncy5saW5lICs9IGFkdjsKKworCSAgICAgaWYg
KHN0YXRlX21hY2hpbmVfcmVncy5pc19zdG10KSB7CisJCSAvKiBvbmx5IGFkZCBhIHN0YXRlbWVu
dCBpZiB0aGVyZSB3YXMgYSBwcmV2aW91cyBib3VuZGFyeSAqLworCQkgaWYgKHN0YXRlX21hY2hp
bmVfcmVncy5sYXN0X2FkZHJlc3MpIAorCQkgICAgIE1MXyhhZGRMaW5lSW5mbykgKHNpLCBmbmFt
ZXNbc3RhdGVfbWFjaGluZV9yZWdzLmxhc3RfZmlsZV0sIAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgTlVMTCwKKwkJCQkgICAgICAgZGVidWdfb2Zmc2V0ICsgc3RhdGVf
bWFjaGluZV9yZWdzLmxhc3RfYWRkcmVzcywgCisJCQkJICAgICAgIGRlYnVnX29mZnNldCArIHN0
YXRlX21hY2hpbmVfcmVncy5hZGRyZXNzLCAKKwkJCQkgICAgICAgc3RhdGVfbWFjaGluZV9yZWdz
Lmxhc3RfbGluZSwgMCk7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9hZGRyZXNzID0gc3Rh
dGVfbWFjaGluZV9yZWdzLmFkZHJlc3M7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9maWxl
ID0gc3RhdGVfbWFjaGluZV9yZWdzLmZpbGU7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9s
aW5lID0gc3RhdGVfbWFjaGluZV9yZWdzLmxpbmU7CisJICAgICB9CisgICAgICAgICAgIH0KKyAg
ICAgICAgIGVsc2Ugc3dpdGNoIChvcF9jb2RlKQorICAgICAgICAgICB7CisgICAgICAgICAgIGNh
c2UgRFdfTE5TX2V4dGVuZGVkX29wOgorICAgICAgICAgICAgIGRhdGEgKz0gcHJvY2Vzc19leHRl
bmRlZF9saW5lX29wMiAoCisgICAgICAgICAgICAgICAgICAgICAgICBzaSwgZGVidWdfb2Zmc2V0
LCAmZm5hbWVzLCBkYXRhLCAKKyAgICAgICAgICAgICAgICAgICAgICAgIGluZm8ubGlfZGVmYXVs
dF9pc19zdG10LCBzaXplb2YgKEFkZHIpKTsKKyAgICAgICAgICAgICBicmVhazsKKworICAgICAg
ICAgICBjYXNlIERXX0xOU19jb3B5OgorICAgICAgICAgICAgIGlmICgwKSBWR18ocHJpbnRmKSgi
MTAwMjogc2ktPm8gJXAsIHNtci5hICVwXG4iLCAKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZGVidWdfb2Zmc2V0LCBzdGF0ZV9tYWNoaW5lX3JlZ3MuYWRkcmVzcyApOworCSAgICAg
aWYgKHN0YXRlX21hY2hpbmVfcmVncy5pc19zdG10KSB7CisJCS8qIG9ubHkgYWRkIGEgc3RhdGVt
ZW50IGlmIHRoZXJlIHdhcyBhIHByZXZpb3VzIGJvdW5kYXJ5ICovCisJCWlmIChzdGF0ZV9tYWNo
aW5lX3JlZ3MubGFzdF9hZGRyZXNzKSAKKwkJICAgICBNTF8oYWRkTGluZUluZm8pIChzaSwgZm5h
bWVzW3N0YXRlX21hY2hpbmVfcmVncy5sYXN0X2ZpbGVdLCAKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIE5VTEwsCisJCQkJICAgICAgIGRlYnVnX29mZnNldCArIHN0YXRl
X21hY2hpbmVfcmVncy5sYXN0X2FkZHJlc3MsIAorCQkJCSAgICAgICBkZWJ1Z19vZmZzZXQgKyBz
dGF0ZV9tYWNoaW5lX3JlZ3MuYWRkcmVzcywKKwkJCQkgICAgICAgc3RhdGVfbWFjaGluZV9yZWdz
Lmxhc3RfbGluZSwgMCk7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9hZGRyZXNzID0gc3Rh
dGVfbWFjaGluZV9yZWdzLmFkZHJlc3M7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9maWxl
ID0gc3RhdGVfbWFjaGluZV9yZWdzLmZpbGU7CisJCSBzdGF0ZV9tYWNoaW5lX3JlZ3MubGFzdF9s
aW5lID0gc3RhdGVfbWFjaGluZV9yZWdzLmxpbmU7CisJICAgICB9CisgICAgICAgICAgICAgc3Rh
dGVfbWFjaGluZV9yZWdzLmJhc2ljX2Jsb2NrID0gMDsgLyogSlJTIGFkZGVkICovCisgICAgICAg
ICAgICAgYnJlYWs7CisKKyAgICAgICAgICAgY2FzZSBEV19MTlNfYWR2YW5jZV9wYzoKKyAgICAg
ICAgICAgICBhZHYgPSBpbmZvLmxpX21pbl9pbnNuX2xlbmd0aCAKKyAgICAgICAgICAgICAgICAg
ICAgICAqIHJlYWRfbGViMTI4IChkYXRhLCAmIGJ5dGVzX3JlYWQsIDApOworICAgICAgICAgICAg
IGRhdGEgKz0gYnl0ZXNfcmVhZDsKKyAgICAgICAgICAgICBzdGF0ZV9tYWNoaW5lX3JlZ3MuYWRk
cmVzcyArPSBhZHY7CisgICAgICAgICAgICAgaWYgKDApIFZHXyhwcmludGYpKCJzbXIuYSArPSAl
cFxuIiwgYWR2ICk7CisgICAgICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgICAgY2FzZSBEV19M
TlNfYWR2YW5jZV9saW5lOgorICAgICAgICAgICAgIGFkdiA9IHJlYWRfbGViMTI4IChkYXRhLCAm
IGJ5dGVzX3JlYWQsIDEpOworICAgICAgICAgICAgIGRhdGEgKz0gYnl0ZXNfcmVhZDsKKyAgICAg
ICAgICAgICBzdGF0ZV9tYWNoaW5lX3JlZ3MubGluZSArPSBhZHY7CisgICAgICAgICAgICAgYnJl
YWs7CisKKyAgICAgICAgICAgY2FzZSBEV19MTlNfc2V0X2ZpbGU6CisgICAgICAgICAgICAgYWR2
ID0gcmVhZF9sZWIxMjggKGRhdGEsICYgYnl0ZXNfcmVhZCwgMCk7CisgICAgICAgICAgICAgZGF0
YSArPSBieXRlc19yZWFkOworICAgICAgICAgICAgIHN0YXRlX21hY2hpbmVfcmVncy5maWxlID0g
YWR2OworICAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgICAgIGNhc2UgRFdfTE5TX3NldF9j
b2x1bW46CisgICAgICAgICAgICAgYWR2ID0gcmVhZF9sZWIxMjggKGRhdGEsICYgYnl0ZXNfcmVh
ZCwgMCk7CisgICAgICAgICAgICAgZGF0YSArPSBieXRlc19yZWFkOworICAgICAgICAgICAgIHN0
YXRlX21hY2hpbmVfcmVncy5jb2x1bW4gPSBhZHY7CisgICAgICAgICAgICAgYnJlYWs7CisKKyAg
ICAgICAgICAgY2FzZSBEV19MTlNfbmVnYXRlX3N0bXQ6CisgICAgICAgICAgICAgYWR2ID0gc3Rh
dGVfbWFjaGluZV9yZWdzLmlzX3N0bXQ7CisgICAgICAgICAgICAgYWR2ID0gISBhZHY7CisgICAg
ICAgICAgICAgc3RhdGVfbWFjaGluZV9yZWdzLmlzX3N0bXQgPSBhZHY7CisgICAgICAgICAgICAg
YnJlYWs7CisKKyAgICAgICAgICAgY2FzZSBEV19MTlNfc2V0X2Jhc2ljX2Jsb2NrOgorICAgICAg
ICAgICAgIHN0YXRlX21hY2hpbmVfcmVncy5iYXNpY19ibG9jayA9IDE7CisgICAgICAgICAgICAg
YnJlYWs7CisKKyAgICAgICAgICAgY2FzZSBEV19MTlNfY29uc3RfYWRkX3BjOgorICAgICAgICAg
ICAgIGFkdiA9ICgoKDI1NSAtIGluZm8ubGlfb3Bjb2RlX2Jhc2UpIC8gaW5mby5saV9saW5lX3Jh
bmdlKQorICAgICAgICAgICAgICAgICAgICAqIGluZm8ubGlfbWluX2luc25fbGVuZ3RoKTsKKyAg
ICAgICAgICAgICBzdGF0ZV9tYWNoaW5lX3JlZ3MuYWRkcmVzcyArPSBhZHY7CisgICAgICAgICAg
ICAgaWYgKDApIFZHXyhwcmludGYpKCJzbXIuYSArPSAlcFxuIiwgYWR2ICk7CisgICAgICAgICAg
ICAgYnJlYWs7CisKKyAgICAgICAgICAgY2FzZSBEV19MTlNfZml4ZWRfYWR2YW5jZV9wYzoKKyAg
ICAgICAgICAgICAvKiBYWFg6IE5lZWQgc29tZXRoaW5nIHRvIGdldCAyIGJ5dGVzICovCisgICAg
ICAgICAgICAgYWR2ID0gKigoVVNob3J0ICopZGF0YSk7CisgICAgICAgICAgICAgZGF0YSArPSAy
OworICAgICAgICAgICAgIHN0YXRlX21hY2hpbmVfcmVncy5hZGRyZXNzICs9IGFkdjsKKyAgICAg
ICAgICAgICBpZiAoMCkgVkdfKHByaW50ZikoInNtci5hICs9ICVwXG4iLCBhZHYgKTsKKyAgICAg
ICAgICAgICBicmVhazsKKworICAgICAgICAgICBjYXNlIERXX0xOU19zZXRfcHJvbG9ndWVfZW5k
OgorICAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgICAgIGNhc2UgRFdfTE5TX3NldF9lcGls
b2d1ZV9iZWdpbjoKKyAgICAgICAgICAgICBicmVhazsKKworICAgICAgICAgICBjYXNlIERXX0xO
U19zZXRfaXNhOgorICAgICAgICAgICAgIGFkdiA9IHJlYWRfbGViMTI4IChkYXRhLCAmIGJ5dGVz
X3JlYWQsIDApOworICAgICAgICAgICAgIGRhdGEgKz0gYnl0ZXNfcmVhZDsKKyAgICAgICAgICAg
ICBicmVhazsKKworICAgICAgICAgICBkZWZhdWx0OgorICAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgIGludCBqOworICAgICAgICAgICAgICAgZm9yIChqID0gc3RhbmRhcmRfb3Bjb2Rlc1tv
cF9jb2RlIC0gMV07IGogPiAwIDsgLS1qKQorICAgICAgICAgICAgICAgICB7CisgICAgICAgICAg
ICAgICAgICAgcmVhZF9sZWIxMjggKGRhdGEsICZieXRlc19yZWFkLCAwKTsKKyAgICAgICAgICAg
ICAgICAgICBkYXRhICs9IGJ5dGVzX3JlYWQ7CisgICAgICAgICAgICAgICAgIH0KKyAgICAgICAg
ICAgICB9CisgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgIH0KKyAgICAgICB9CisgICAg
ICBWR18oYXJlbmFfZnJlZSkoVkdfQVJfU1lNVEFCLCBmbmFtZXMpOworICAgICAgZm5hbWVzID0g
TlVMTDsKKyAgICB9Cit9CiAKIC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCiAvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLwo=

[Valgrind-users] Massif (3.3.0-SVN) question

From: Brian J. Miller <miller125@ll...> - 2007-11-27 16:14

I've been testing the trunk version of massif and have a question.  Is 
the peak
heap memory used simply the largest heap use among the regular samples 
or is it the
max over the course of the run? 

Also, thanks for the changes to massif.  I find the output in MB much 
more useful. 

Thanks,
Brian

-- 
________________________________________________________________________
 Brian Miller, L-556
 Center for Applied Scientific Computing (CASC)
 Lawrence Livermore National Lab (LLNL)        Email: miller125@...
 P.O. Box 808, 7000 East Ave.                  Phone: (925)424-4773
 Livermore, CA  94551                          Fax: (925)422-9429
________________________________________________________________________

Re: [Valgrind-users] Massif (3.3.0-SVN) question

From: Nicholas Nethercote <njn@cs...> - 2007-11-27 21:33

On Tue, 27 Nov 2007, Brian J. Miller wrote:

> I've been testing the trunk version of massif and have a question.  Is the 
> peak heap memory used simply the largest heap use among the regular 
> samples or is it the max over the course of the run?

The latter -- it checks for a peak after every deallocation.  I'll clarify 
this in the docs.

But note that by default the reported peak can be up to 1% away from the 
true peak.  You can change this with the --peak-inaccuracy option, but if 
you set it to zero (or close to zero) Massif will slow down a lot.

> Also, thanks for the changes to massif.  I find the output in MB much
> more useful.

Good!  Thanks for the feedback.

Nick

[Valgrind-users] corruption inside the object on the heap

From: Pawel K <pawlaczus@ya...> - 2007-11-27 13:55

Hello

Is Valgrind able to detect the heap corruption in the
below program:

class Human
{
  char m_name[3];
  char m_sName[3];
  char *m_country;

public:
  
  void SetDefNames ( void )
  {
    strcpy ( m_name, "NM" );
    m_country = "ID";
    strcpy ( m_sName, "SECNM" ); // !!! corrupts
m_country pointer !!!
  }
};

int main ( void )
{
  Human *human = new Human;
  human -> SetDefNames ();
  return 0;
}

I can see that:
valgrind ./a.out does not detect error.

How can I force Valgrind to detect such heap
corruptions ?
Should I write any valgrind tool or something ?

Please give me some indications.

Thank you for help


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Valgrind-users] corruption inside the object on the heap

From: Robert Walsh <rjwalsh@du...> - 2007-11-27 17:25

Valgrind cannot detect this kind of corruption: as far as it's  
concerned, you're simply writing data into valid memory.  The meaning  
of the data may be bogus, but Valgrind has no way of knowing this.   
Later on, accessing the now bogus pointer will most likely cause an  
error that Valgrind can detect.

On Nov 27, 2007, at 5:55 AM, Pawel K wrote:

> Hello
>
> Is Valgrind able to detect the heap corruption in the
> below program:
>
> class Human
> {
>  char m_name[3];
>  char m_sName[3];
>  char *m_country;
>
> public:
>
>  void SetDefNames ( void )
>  {
>    strcpy ( m_name, "NM" );
>    m_country = "ID";
>    strcpy ( m_sName, "SECNM" ); // !!! corrupts
> m_country pointer !!!
>  }
> };
>
> int main ( void )
> {
>  Human *human = new Human;
>  human -> SetDefNames ();
>  return 0;
> }
>
> I can see that:
> valgrind ./a.out does not detect error.
>
> How can I force Valgrind to detect such heap
> corruptions ?
> Should I write any valgrind tool or something ?
>
> Please give me some indications.
>
> Thank you for help
>
>
>       
> ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users