From: Phil Muldoon <pmuldoon@redhat.com>
To: Michael Stahl <mstahl@redhat.com>,
gdb@gnu.org, Doug Evans <dje@google.com>,
Doug Evans <xdje42@gmail.com>
Subject: Re: gdb 8.0 "lazy_string" exception "Length is larger than array size"
Date: Tue, 26 Sep 2017 07:56:00 -0000 [thread overview]
Message-ID: <a8fbe6d5-08f8-47ee-75c1-62a9b380d337@redhat.com> (raw)
In-Reply-To: <oqbdtj$nvc$1@blaine.gmane.org>
On 25/09/17 18:20, Michael Stahl wrote:
>
> hi,
>
> for the following string type:
>
> /** The implementation of a Unicode string.
> */
> typedef struct SAL_DLLPUBLIC_RTTI _rtl_uString
> {
> oslInterlockedCount refCount; /* opaque */
> sal_Int32 length;
> sal_Unicode buffer[1];
> } rtl_uString;
>
> the gdb python pretty-printer calls:
>
> return data.lazy_string(encoding, length)
>
> full python pretty-printer module:
>
> https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=solenv/gdb/libreoffice/util/string.py;h=32583718f83b2ad5707f75dd6327d9aa62764439;hb=5f210715fe090b4db4c80dcdee5f77dc404cf85c#l56
>
> now this results in this exception:
>
> Traceback (most recent call last):
> File "/work/lo/master/solenv/gdb/libreoffice/util/string.py", line
> 29, in to_string
> return self.make_string(data, self.encoding, len)
> File "/work/lo/master/solenv/gdb/libreoffice/util/string.py", line
> 66, in make_string
> return data.lazy_string(encoding, length)
> gdb.error: Length is larger than array size.
>
> this is with Fedora 26 "GNU gdb (GDB) Fedora 8.0.1-26.fc26" - in Fedora
> 25 this did not throw an exception.
>
> apparently the problem is that the array is statically declared as
> "buffer[1]", however its actual dynamic size is the same as "length".
>
> is this a bug in gdb or is lazy_string not intended to support this
> scenario?
>
> regards,
> michael
>
Yeah, it's determining the string is an array and finding that the
declared length is larger then the array size. This is (as you noted)
the initial length of the array is [1] and that array is then
modified later. This code was added at 34b433203b5 by Doug Evans and
it was noted it was a bug. I've not sure, though, fixing this bug
may have had unintended consequences. I've CC'd Doug on the patch
and maybe he could comment further.
Cheers
Phil
next prev parent reply other threads:[~2017-09-26 7:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 19:55 Michael Stahl
2017-09-26 7:56 ` Phil Muldoon [this message]
2017-09-26 8:06 ` Fwd: " Phil Muldoon
2017-09-26 10:30 ` Pedro Alves
2017-09-29 15:06 ` Michael Stahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8fbe6d5-08f8-47ee-75c1-62a9b380d337@redhat.com \
--to=pmuldoon@redhat.com \
--cc=dje@google.com \
--cc=gdb@gnu.org \
--cc=mstahl@redhat.com \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox