Date: Sat, 10 Aug 2002 12:37:53 -0400 From: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca> To: Martin Blapp <mb@imp.ch> Cc: <dev@porting.openoffice.org>, <openoffice@FreeBSD.ORG> Subject: Re: [porting-dev] Re: Crash with Test-Document in the second run. Memory allocation problem Message-ID: <200208101237.53297.kevin.hendricks@sympatico.ca> In-Reply-To: <20020810182303.J92422-100000@levais.imp.ch> References: <20020810182303.J92422-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Martin,
On August 10, 2002 12:26, Martin Blapp wrote:
> Hi,
>
> > pType ppThis
>
> (gdb) pType ppThis
> type = struct _rtl_uString {
> sal_Int32 refCount;
> sal_Int32 length;
> sal_Unicode buffer[1];
> } **
>
> > If it is the unicode buffer then throw out every high byte (which
> > should be zero) and you get the hex string:
> >
> > 74 53 72 61 72 57 74 69 72 65 35 20 30 2e 65 00
> >
> > As the asci string.
> >
> > Looking this up in my ascii table gives the following nonsense:
> > tSrarWtEre5 0.e
>
> Starwriter5.0 ? ;-)
Ah, I am BigEndian and your are LittleEndian so something is byteswapping
the ints of the buffer ... perhaps gdb does this when it uses x/20x (it
assumes an int and not a short)? Hmm, we should be dealing with short
ints and not ints here so an array of short ints should be readable in
normal order (and is on my BigEndian version of gdb!).
Perhaps there is another way to use gdb and x/20 to examine shorts and not
regular ints easily. Anyway, you can use that approach to see the string
contents.
> > Which looks like nonsense to me.? Please try:
> >
> > print * ppThis
> > print * pStr
>
> This one seems to be one.
>
> (gdb) print * ppThis
> $6 = (struct _rtl_uString *) 0x8390a40
>
> This one not.
>
> (gdb) print * pStr
> $7 = {refCount = 1474660693, length = -326937770, buffer = {59412}}
>
> Martin
Yes, it looks like pStr is pointing to garbage, but is this before the
assignment is done (and so garbage is okay) or after the assignment.
If after then I wonder if pStr is normal up the chain farther (whether
something corrupted the memory in this frame).
Kevin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-openoffice" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208101237.53297.kevin.hendricks>