This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [python] don't try to free "independent" types

Tom Tromey wrote:
> Last night I thought of another scenario whereby we could end up
> referring to a free'd "struct type".  This script shows the problem:
>     break 44
>     run
>     print &s
>     python s = gdb.get_value_from_history(0)
>     python t = gdb.Type ('PTR')
>     kill
>     file
>     python s = s.cast(t.pointer())
>     python t = None
>     python print s.type()
> When we evaluate "t = None", we delete the underlying struct type.
> However, "s" still refers to it by virtue of the cast operation.
> After considering this for a while I arrived at the conclusion that,
> short of a value-and-type garbage collector, there is not much that
> can be done.

Any way to implement reference counts with a free-on-count-equal-zero
sort of thing?  (This may be a phenomenally bone-headed suggestion--I
don't know a thing about python.  If it is, consider it the

> I think this would be pretty controversial.  So, instead of doing this
> on the branch, I am checking in this patch, which removes freeing of
> objfile-less types.  This is a memory leak, but I think such types are
> likely to be relatively rare, and this is preferable to a crash.  I
> will raise this issue when I submit the Type work upstream.
> I added a new test case for this particular scenario.  More losing
> cases exist though; basically any operation on the Value resulting
> from Value.cast can cause problems, including things like extracting
> the underlying struct value for MI pretty-printing.
> Tom

Chris Moller

  I know that you believe you understand what you think I said, but
  I'm not sure you realize that what you heard is not what I meant.
      -- Robert McCloskey

Attachment: signature.asc
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]