Re: Freeing a record which contains a string field leads to a memory/string leak ?!
From: Rob Kennedy (me_at_privacy.net)
Date: 02/20/04
- Next message: Maarten Wiltink: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Previous message: Rob Kennedy: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- In reply to: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Next in thread: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 20 Feb 2004 12:36:54 -0600
Skybuck Flying wrote:
> Man that sounds painfull.... what would be the best way to prove
> this...
Trace the code in the CPU window.
> How can I make the app crash when it tries to do this...
Presumably, you'd just let it do that. There shouldn't be anything
special you need to do.
> What do you mean with free ? Dereferencing it ? Hmmm maybe if
> reference count happened to be higher than zero. yesyes, that's a
> good one.
Since there *is no string*, there is no reference count, so it can't be
greater than zero.
> So to make it crash I should probably try to mess around with the
> hidden reference count before the string.
No, you just let it crash.
> The dirty solution would be to secretly increment the string's
> reference count by 1... fooling delphi so it believes something still
> references it... ofcourse this is dirty because no one has to
> manually lower it... and pointer arithmetic trick is also a bit dirty
> reference count location could probably change in other delphi
> versions or so who knows...
Right. The reference count should be considered an implementation
detail. Let the compiler manage it exclusively.
> But but but but but this raising a somewhat little interesting
> question if you guys also new a 'legal' trick to keep the string
> alive but so that delphi does destroy the string when the pointer
> goes dead or is reassigned something else whatever.
There is no legal solution to the problem you posed. You're giving P a
pointer to a stack variable. As soon as the procedure returns, that
pointer will be invalid. The fact that P is pointing to a *string*
variable is totally irrelevant. If you want the pointer to remain valid
after the procedure returns, then you need to make it point to memory
allocated on the heap, not on the stack. An easy way to do that is to
allocate the pointer with New.
> If not then ofcourse the delphi developers could add extra run time
> information to raw pointers, secretly keeping track of what the
> pointer points to...
Pointers can already have types. And the compiler can be told to keep a
watch on those types while compiling. The default state is for it to
mostly ignore pointers' types, though. Enable the "typed @ operator"
compiler option for safer pointer code.
> if it points to something that is reference counted it will behave
> like strings for example hehe.
Or, you could just use a string and stop messing around with pointers.
> I am just kiding ofcourse... assigning strings to pointers like that
> would be super cool if it worked... because I could then hang strings
> in my double linked list and I would not have to wrap them up in a
> fricking record or class ===DDDD
You can store strings in linked lists. I don't know the specifics of
what you're doing, though, so I can't help you with that yet.
> Unless you guys know something which I dont know about pointers,
> strings and reference counting.
I'm sure I do, but I'm not clear on what you need to know.
> Because lot's be honest for a sec :D Classes can be assigned to
> pointers ! by not strings ?! wtf ?! :D
Strings can certainly be assigned to pointers. But that's not what
you're trying to do. You're assigning a pointer to a string to a
pointer. You could also assign a pointer to an object to a pointer, but
instead you've been assigning the object reference directly to the pointer.
> It's a hole if you ask me :D it's a big damn ugly hole ! :D I can
> assign anything to pointers without having to worry to much, but
> noooooo not strings...
> strings blow up in your face :D
Calm down. You're jumping to conclusions. You need to learn to wait for
other people to reply to your messages before you go off and answer them
yourself.
> Jipeeeeeeeee... I don't like new... it's so new... it's like C++'s
> new ahhhhhhhhh no plz dont kill me.
>
> With new I can't specify the size :(...........................:((((
You don't need to. The compiler already knows the size based on the type
of the pointer. In that way, New is much safer than GetMem since you
always get the right amount of space.
If you really have no idea how much space you need then go ahead and use
GetMem. However, if you don't know how much space you need, then chances
are that you also don't know what kind of data you're storing there
anyway, so I can't imagine that you'd be storing string references.
> But with GetMem I can :DDDDDDDDDDDDD
>
> And now thanks to initialize I can solve thezzz problemmmm. :D
Not really. Initialize expects a specific size, based on the pointer
type, just like New.
> Thanks dude !
>
> WITHOUT having to CHANGE any code !
>
> I only have the ADD code...
>
> THAT's JUST GREAT, I LOVE IT :D
>
> Otherwise I had to be reallllllllly carefull when changing from
> getmem to new.... oooeeee noooo plz dont kill me.
Hardly. All of your GetMem calls were using SizeOf. The compiler simply
inserts the size automatically with New. Internally, New calls GetMem.
> That would have been painfull.. Pthis, Pthat, Pnotanymore lol. Nooo
> not Tblablabla, must be Pblablabla or can it ?! :P:P:P
Could you try asking that again, after you've calmed down?
>>> I also hope that somebody knows a way how to prove that it does
>>> or does not lead to a memory leak,
>
> 2. Nonononononononono mister, you did not provide any proof...
You never asked for one. You merely hoped that someone knew of one. And
someone does.
> Provide a test method to euhm investigate what actually happens. This
> investigation will lead to either leaking or no leaking. YES sir !
OK, you're making a lot of requests, and I'm having trouble keeping
track of them all. Please take a moment to organize your thoughts, and
post separate questions if you have to.
> Don't rob me lol.
Yeah, cute. The last person to make that joke about my name was eight
years old.
-- Rob
- Next message: Maarten Wiltink: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Previous message: Rob Kennedy: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- In reply to: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Next in thread: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Reply: Skybuck Flying: "Re: Freeing a record which contains a string field leads to a memory/string leak ?!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
