From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26473 invoked by alias); 16 Jul 2004 13:17:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26448 invoked from network); 16 Jul 2004 13:17:24 -0000 Received: from unknown (HELO web41809.mail.yahoo.com) (66.218.93.143) by sourceware.org with SMTP; 16 Jul 2004 13:17:24 -0000 Message-ID: <20040716131723.75703.qmail@web41809.mail.yahoo.com> Received: from [200.84.69.192] by web41809.mail.yahoo.com via HTTP; Fri, 16 Jul 2004 10:17:23 ART Date: Fri, 16 Jul 2004 14:04:00 -0000 From: =?iso-8859-1?q?Charlls=20Quarra?= Subject: RE: dumping and browsing heap To: gdb@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2004-07/txt/msg00201.txt.bz2 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 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 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