RE: dumping and browsing heap

["Charlls Quarra" <charlls_quarra@yahoo.com.ar>]

 the result was 

$ tr -c -d '\012' < blafile | wc -c
   2137

btw, looking at binaries in vi seems that the zero
ascii is represented by "@^" but still counted as a
single byte (the byte position increases by one when
displaced over those two characters)

and eol seem to be counted as a single byte (the
position of the first character in the next line is +2
the position of the last character in the previous
line)



--- Dave Korn <dk@artimi.com> escribió: > >
-----Original Message-----
> > From: gdb-owner On Behalf Of Charlls Quarra
> > Sent: 16 July 2004 03:03
> 
> > i want to give a look at the heap globally, so i
> do:
> > 
> > dump memory blafile 0x8100000 0x8300000
> > 
> >  
> > whenever i find something interesting in the
> blafile
> > (i open it with vi) a g<control-g> command gives
> me
> > the absolute position of the desired byte in the
> file
> > (at least that is the expected behaviour)
> > 
> > the dump should contain 0x200000 (2097152 in
> decimal)
> > bytes, however it happens to contain 2295106
> (197954
> > bytes in excess). Someone knows how to account for
> > these extra bytes? 
> 
> 
>   Mmm.  You're using vi.  Probably opens the file in
> textmode.  Is anything
> perhaps translating every LF to CR+LF, thereby
> adding an 0x0d in front of
> every 0x0a in the original file?  The way to find
> out would be
> 
> tr -c -d '\012' < blafile | wc -c
> 
> and if the result is 197954, there's your suspect.
> 
> 
>     cheers, 
>       DaveK
> -- 
> Can't think of a witty .sigline today....
> 
>  


	
	
		
___________________________________________________________
100mb gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar