From: Doug Evans <dje@google.com>
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: gdb@sourceware.org
Subject: TYPE_NAME memory management
Date: Fri, 04 Sep 2009 21:18:00 -0000 [thread overview]
Message-ID: <e394668d0909041417x3e65c584v7633e188bbdf4d6e@mail.gmail.com> (raw)
On Fri, Sep 4, 2009 at 11:03 AM, Doug Evans<dje@google.com> wrote:
> On Fri, Sep 4, 2009 at 10:59 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:
>> On Fri, Sep 4, 2009 at 8:25 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:
>>
>>> I am still working on a stand-alone repro case.
>>
>> Here it is:
>>
>>[...]
>> Segmentation fault (core dumped)
>>
>> I will not be able to work on a fix before next Tuesday, so if anybody
>> fixes this before then, please let me know.
Memory management for TYPE_NAME and TYPE_TAG_NAME is a bit random.
E.g.
bash$ grep "TYPE_NAME *(.*) *= " *.c
bash$ grep "TYPE_TAG_NAME *(.*) *= " *.c
Sometimes it's a string constant, sometimes it's in malloc space,
sometimes it's on objfile's obstack, and now sometimes it can live in
mmap'd space.
Obviously one would rather not place ordering constraints on objfile
data cleanups. All the above uses are "ok" (modulo any memory leaks
from malloc'd strings) except for the new mmap'd values, so it seems
like the thing to do for now is copy such strings onto the objfile's
obstack.
I'm not sure what the speed loss will be, but I think it's the thing
to do pending data that says something more clever is needed.
next reply other threads:[~2009-09-04 21:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-04 21:18 Doug Evans [this message]
2009-09-04 22:42 ` Tom Tromey
2009-09-04 22:54 ` Doug Evans
2009-09-04 23:04 ` Joel Brobecker
2009-09-09 16:40 ` Doug Evans
2009-09-09 17:30 ` Paul Pluzhnikov
2009-09-09 17:38 ` Doug Evans
2009-09-09 17:46 ` Tom Tromey
2009-09-04 22:44 ` Joel Brobecker
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=e394668d0909041417x3e65c584v7633e188bbdf4d6e@mail.gmail.com \
--to=dje@google.com \
--cc=gdb@sourceware.org \
--cc=ppluzhnikov@google.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