dumping and browsing heap

dumping and browsing heap

[Charlls Quarra]

Hi,

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? 


 at the end i need to compute the real position in
memory from the position in the file dump


 cheers





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

RE: dumping and browsing heap

[Dave Korn]

> -----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....

RE: dumping and browsing heap

[Charlls Quarra]

 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