This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: dumping and browsing heap
- From: Charlls Quarra <charlls_quarra at yahoo dot com dot ar>
- To: gdb at sources dot redhat dot com
- Date: Fri, 16 Jul 2004 10:17:23 -0300 (ART)
- Subject: RE: dumping and browsing heap
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