| Re: Ghost object [message #21190] |
Thu, 17 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
Well, I got that problem to repeat itself. Although I have no idea what
causes it, I am now convinced it is a bug. Here is what happens. Thanks
to Randall Frank for suggestion to use head numbers to locate the source
of leaking heap variable, it helped.
The "ghostfont" is caused to appear by the following line in the code:
self.scene -> add, view
If this line is commented out, the ghost "IDLgrFont" does not appear.
*If IDL is restarted*, it does not appear with this line present either,
*until* .Reset_session is not invoked several times (I have not tested,
how many exactly). .Full_reset_session does not cure the problem. I
could provide code snippets but I'll just send output logs:
***Comment out "self.scene -> add, view", compile, run.
IDL> display
*** Perform cleanup, but leave all code-created FONT ant TEXT objects undeleted.
IDL> widget_control, /reset & close, /all & heap_gc, /verbose & retall
<ObjHeapVar3123>
STRUCT = -> IDLGRFONT Array[1]
<ObjHeapVar3156>
STRUCT = -> IDLGRTEXT Array[1]
<ObjHeapVar3160>
STRUCT = -> IDLGRTEXT Array[1]
***All of these were made by the code. First TEXT is 33 references
***after the code-created FONT.
***Uncomment "self.scene -> add, view" and recompile, run
% Compiled module: DISPLAY.
IDL> display
TEMP (PARGRPLOT_TOP_WINDOW)
OBJREF = <ObjHeapVar3179(PARGRPLOT)>
IDL> widget_control, /reset & close, /all & heap_gc, /verbose & retall
<ObjHeapVar3190>
STRUCT = -> IDLGRFONT Array[1]
<ObjHeapVar3223>
STRUCT = -> IDLGRTEXT Array[1]
<ObjHeapVar3227>
STRUCT = -> IDLGRTEXT Array[1]
<ObjHeapVar3245>
STRUCT = -> IDLGRFONT Array[1]
***First three these made by the code. First TEXT is 33 references
***after the code-created FONT.
***Second instance of IDLGRFONT appears AFTER everything else.
I have no idea what exactly is going on, but adding a view to a scene
should not cause this. Looks like a bug in .Reset_session.
Cheers,
Pavel
|
|
|
|
| Re: Ghost object [message #21200 is a reply to message #21190] |
Thu, 17 August 2000 00:00  |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
Well I certainly appreciate Martin's Virus warning. Its been a while
since I laughed so hard.
On a more serious note, I'd like myself to find out that it was an error
in my code. One good advice Randall Frank gave me is to use heap head
numbers to track down when that suspect was created. If I see it again,
I'll do that and confess to the public that it was my fault, or otherwise.
Thanks for your attention to the infestation of my computer.
Cheers,
Pavel
|
|
|
|
| Re: Ghost object [message #21280 is a reply to message #21190] |
Wed, 16 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
David Fanning wrote:
>
> Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
>
>> And... here again comes IDLGRFONT, Array[1].
>
> Uh, you're not using one of my programs, are you. :-(
Nope. And it is not happening today, either. The code is untouched. I am
convinced it is a one-time glitch (that sometimes repeats at regular
intervals :-)
Solution: I'll just quit IDL to let it rest over the lunch break :-)
Cheers,
Pavel
|
|
|
|
|
|
| Re: Ghost object [message #21291 is a reply to message #21280] |
Wed, 16 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
Martin Schultz wrote:
> .. but: suppose you create the font object while testing your object,
> then you edit
> and recompile while the object is still alive, removing the cleanup of
> something
> that caused the font object to appear -- well, THEN you may indeed find
> a situation
> where you have a memory leak. Hell, this is convoluted! If it works
> after you exit and
> restart, and doesn't show up again: why bother? I would only bother if
> you thought
> your program had finished the development stage and the error occurs
> reproducibly
> when running the code.
>
> Martin
Thanks Martin, this would be an explanation. I tried to design this code
"leakproof". The object exists only for as long as its top base exists.
If its killed, cleanup is performed. I never execute the *creation* code
while its alive, only the event handling routine. Every single object
used in it was placed in a container to be wiped by the cleanup routine.
All objects are IDLgr***, so nothing I use is calling IDLGRFONT from
behind my back. Can compilation by itself create an instance of an
object? That would be strange.
Well, I'd leave it as it was, but yesterday, after *quitting* IDL and
starting over, everything was just fine for an hour. I was happy with
how it all worked, and never edited that part of the code again,
developing other parts. And... here again comes IDLGRFONT, Array[1]. I
recorded the number of objects created by my code and compared them with
the number of objects in containers, and I do remove everything I make.
Something else somewhere is creating that one. In fact, if I don't place
the *only* instance of IDLGRFONT I made in a container, then I get this
one remaining in the heap, too, so I end up with two leftover objects.
Strange. If this persists, I'll ask people to test the code on their machines.
I am beginning to think if accessing IDLgrText objects may in some
instances cause them to lose their Font objects? I have used them before
and never noticed that.
Cheers,
Pavel
P.S. If my first theory of tired IDL is true, then I should not see this
again till noon at least :-)
|
|
|
|
| Re: Ghost object [message #21300 is a reply to message #21280] |
Wed, 16 August 2000 00:00 |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
David Fanning wrote:
>
> Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
>
>> Does anybody have an explanation?
>
> I learned not to even listen to the problem until the person had
> quit IDL and started over.
Wow, I wasn't aware RSI employed MicroSoft Software Fix techniques.
that's too bad.
--
Paul van Delst Ph: (301) 763-8000 x7274
CIMSS @ NOAA/NCEP Fax: (301) 763-8545
Rm.202, 5200 Auth Rd. Email: pvandelst@ncep.noaa.gov
Camp Springs MD 20746
|
|
|
|
| Re: Ghost object [message #21305 is a reply to message #21280] |
Wed, 16 August 2000 00:00 |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
Craig Markwardt wrote:
>
> I don't really know IDL objects from my oss, but it sounds like some
> *other* compiled IDL function or method was creating the font object.
> If by any chance you edited the source but forgot to recompile it,
> then this could have happened. When you restart the IDL session then
> it finally was recompiled anew.
>
> I do this kind of thing once in a while (edit but forget to compile),
> and it leaves me very confused. However, you say you were
> recompiling, so that doesn't seem like the right solution. Oh well.
>
> Craig
>
> Pavel Romashkin <promashkin@cmdl.noaa.gov> writes:
>> Hi,
>> I have just lost an hour and a half trying to find a heap leak in my
>> code. It is a simple object graphics, universal replacement for PLOT but
>> with zoom, edit etc. capabilities. Anyway, once I kill the plot window,
>> a cleanup routine is called that does total sweep of the heap variables
>> by looping through object fields and destroying objects and pointers.
>> Once its done, I'd call our favorite Heap_gc to see if there was a leak.
>> Sure enough, it was always finding and deleting an instance of
>> IDLGRFONT. I tried everything I could: commented out the only line where
>> IDLGRFONT was used, tried all sorts of explicit object destruction
>> immediately after creation, etc. I felt it was not my fault, so I tried
>> "Clear IDL" and .Reset, and .Full_reset. Same thing: once I recompile,
>> run and kill the object tree, IDLGRFONT would still always be found by
>> Heap_gc. It was not a fake, as its heap ID would be always higher each time.
>> Frustrated, I quit IDL and restarted. What do you think? It stopped
>> doing that. I swear the code is the same, because I went through every
>> single line checking it, saved it, tried it, got a leak and quit IDL.
>> But after restart IDLGRFONT stopped appearing in the heap.
>> I have no idea what it was, but it certainly complicated my leak search.
>> Does anybody have an explanation?
>> Thanks,
>> Pavel
>
> --
> ------------------------------------------------------------ --------------
> Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
> Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
> ------------------------------------------------------------ --------------
.. but: suppose you create the font object while testing your object,
then you edit
and recompile while the object is still alive, removing the cleanup of
something
that caused the font object to appear -- well, THEN you may indeed find
a situation
where you have a memory leak. Hell, this is convoluted! If it works
after you exit and
restart, and doesn't show up again: why bother? I would only bother if
you thought
your program had finished the development stage and the error occurs
reproducibly
when running the code.
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
| Re: Ghost object [message #21307 is a reply to message #21280] |
Wed, 16 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Theo Brauers (th.brauers@fz-juelich.de) writes:
> An engineer, a physicist, and a programmer are driving in a car
> when it suddenly stops in the middle of nowhere. The engineer:
> 'Shoot, we ran out of gas!' The physicist: 'This is probably an
> engine problem.' The programmer: 'Let's exit the car, we enter
> again, and everything will be fine.'
There is a power or force in the Universe that cannot
be unleashed without exiting the program. I can't explain
it, but I have observed it too many times not to be a
firm believer in it.
I think Pavel's original explanation is pretty close
to the truth. Software that runs in heated conditions
for hours at 400 Hz can get flustered. Exiting the
program gives the software a chance to compose itself.
It is sort of like taking the screaming baby out of
the hands of a young mother for five minutes. It puts
the Universe back in order and makes it possible to
move forward.
An alternative technique is to have the instructor come
up and look over your shoulder while you demonstrate the
problem. The downfall of this technique is that it only
has a 75-80% success rate.
Of course, the over-the-shoulder technique works in reverse
too. Try to demo a perfectly working program to anyone
higher than you on the food chain and there is at least
a 75-80% chance that the program will crash in the first
30 seconds.
Cheers,
David
P.S. Let's just say life is a Mystery, and I like it
that way. :-)
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Ghost object [message #21308 is a reply to message #21280] |
Wed, 16 August 2000 00:00 |
Theo Brauers
Messages: 58
Registered: November 1997
|
Member |
|
|
An engineer, a physicist, and a programmer are driving in a car
when it suddenly stops in the middle of nowhere. The engineer:
'Shoot, we ran out of gas!' The physicist: 'This is probably an
engine problem.' The programmer: 'Let's exit the car, we enter
again, and everything will be fine.'
Best Theo
David Fanning wrote:
>
> Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
>
>> My point, actually, was that I thought .Full_reset_session was pretty
>> much the same as starting over. I guess it is not in those cases when
>> IDL gets a little upset.
>
> Scene at a medium-sized computer software company. Tight
> shot of cubicle piled high with copies of PC World and
> Byte magazines. Our hero talks on the phone.
>
> Hero: Why don't you just exit IDL and try it again?
>
> Customer: I did start over. It always happens.
>
> Hero: Uh, huh. Well, just to humor me exit IDL and try it
> again.
>
> Customer: It won't make a difference.
>
> Hero: Uh, huh. But just to humor me. Please.
>
> Customer: Sigh...I already tried that, but here you go.
>
> (45 seconds of typing can be heard on the phone lines.)
>
> Customer: OK, I did that and it is still broken.
>
> Hero: You exited IDL!?
>
> Customer: Well, no. I thought .Reset_Session was the same thing.
>
> Hero (an audible hitch in his voice): Well, how about you
> just try exiting IDL and run it again.
>
> Customer: Oh, friggin hell! Alright, I exited IDL and .....
> Oh ... well, never mind.
>
> (Sound of phone being hung up.)
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting
> Phone: 970-221-0438 E-Mail: davidf@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155
--
----------------------------------------------
Theo Brauers
Institut fuer Atmosphaerische Chemie (ICG-3)
Forschungszentrum Juelich
52425 JUELICH, Germany
Tel. +49-2461-61-6646 Fax. +49-2461-61-5346
http://www.kfa-juelich.de/icg/icg3/MITARBEITER/th.brauers.ht ml
|
|
|
|
| Re: Ghost object [message #21315 is a reply to message #21280] |
Tue, 15 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
> My point, actually, was that I thought .Full_reset_session was pretty
> much the same as starting over. I guess it is not in those cases when
> IDL gets a little upset.
Scene at a medium-sized computer software company. Tight
shot of cubicle piled high with copies of PC World and
Byte magazines. Our hero talks on the phone.
Hero: Why don't you just exit IDL and try it again?
Customer: I did start over. It always happens.
Hero: Uh, huh. Well, just to humor me exit IDL and try it
again.
Customer: It won't make a difference.
Hero: Uh, huh. But just to humor me. Please.
Customer: Sigh...I already tried that, but here you go.
(45 seconds of typing can be heard on the phone lines.)
Customer: OK, I did that and it is still broken.
Hero: You exited IDL!?
Customer: Well, no. I thought .Reset_Session was the same thing.
Hero (an audible hitch in his voice): Well, how about you
just try exiting IDL and run it again.
Customer: Oh, friggin hell! Alright, I exited IDL and .....
Oh ... well, never mind.
(Sound of phone being hung up.)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Ghost object [message #21316 is a reply to message #21315] |
Tue, 15 August 2000 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
I don't really know IDL objects from my oss, but it sounds like some
*other* compiled IDL function or method was creating the font object.
If by any chance you edited the source but forgot to recompile it,
then this could have happened. When you restart the IDL session then
it finally was recompiled anew.
I do this kind of thing once in a while (edit but forget to compile),
and it leaves me very confused. However, you say you were
recompiling, so that doesn't seem like the right solution. Oh well.
Craig
Pavel Romashkin <promashkin@cmdl.noaa.gov> writes:
> Hi,
> I have just lost an hour and a half trying to find a heap leak in my
> code. It is a simple object graphics, universal replacement for PLOT but
> with zoom, edit etc. capabilities. Anyway, once I kill the plot window,
> a cleanup routine is called that does total sweep of the heap variables
> by looping through object fields and destroying objects and pointers.
> Once its done, I'd call our favorite Heap_gc to see if there was a leak.
> Sure enough, it was always finding and deleting an instance of
> IDLGRFONT. I tried everything I could: commented out the only line where
> IDLGRFONT was used, tried all sorts of explicit object destruction
> immediately after creation, etc. I felt it was not my fault, so I tried
> "Clear IDL" and .Reset, and .Full_reset. Same thing: once I recompile,
> run and kill the object tree, IDLGRFONT would still always be found by
> Heap_gc. It was not a fake, as its heap ID would be always higher each time.
> Frustrated, I quit IDL and restarted. What do you think? It stopped
> doing that. I swear the code is the same, because I went through every
> single line checking it, saved it, tried it, got a leak and quit IDL.
> But after restart IDLGRFONT stopped appearing in the heap.
> I have no idea what it was, but it certainly complicated my leak search.
> Does anybody have an explanation?
> Thanks,
> Pavel
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Ghost object [message #21317 is a reply to message #21316] |
Tue, 15 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
David Fanning wrote:
>
> Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
>
>> Etc.
>> Does anybody have an explanation?
>
> Yes, but I'm saving it for the IDL EPA exam. :-)
Geez, David, I thought you were supposed to *ask* questions, not to keep
*answers* to them, on that exam. Or are you being tested, too? Well, at
least let me know what it is after you are done torturing Ben.
Also, don't forget to ask "what do you do when the only color you get on
a plot is red?" :-)
Cheers,
Pavel
P.S. My own answer: "Introducing myself: I am IDL, I run here on this
danged overheated PPC for hours with no stopping. So what, I got
confused here for a while. I thought you wanted that object to be around
longer. I'd like to see how you'd do in my place running at 400 MHz, if
you think you are so perfect and you are not even letting me have a 5
minute break".
|
|
|
|
| Re: Ghost object [message #21318 is a reply to message #21317] |
Tue, 15 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
David Fanning wrote:
>
> One of the best parts of my training in IDL was being
> for some years a Technical Support Engineer. I learned
> not to even listen to the problem until the person had
> quit IDL and started over. That cleared up about 95%
> of my calls and made me a superstar among the brethren. :-)
Oh, but this implies that, *after* restarting IDL, someone *might*
actually listen? This is encouraging!
My point, actually, was that I thought .Full_reset_session was pretty
much the same as starting over. I guess it is not in those cases when
IDL gets a little upset.
Cheers,
Pavel
|
|
|
|
| Re: Ghost object [message #21319 is a reply to message #21318] |
Tue, 15 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
> Does anybody have an explanation?
One of the best parts of my training in IDL was being
for some years a Technical Support Engineer. I learned
not to even listen to the problem until the person had
quit IDL and started over. That cleared up about 95%
of my calls and made me a superstar among the brethren. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Ghost object [message #21320 is a reply to message #21319] |
Tue, 15 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
> I have just lost an hour and a half trying to find a heap leak in my
> code. It is a simple object graphics, universal replacement for PLOT but
> with zoom, edit etc. capabilities. Anyway, once I kill the plot window,
> a cleanup routine is called that does total sweep of the heap variables
> by looping through object fields and destroying objects and pointers.
> Once its done, I'd call our favorite Heap_gc to see if there was a leak.
> Sure enough, it was always finding and deleting an instance of
> IDLGRFONT. I tried everything I could: commented out the only line where
> IDLGRFONT was used, tried all sorts of explicit object destruction
> immediately after creation, etc. I felt it was not my fault, so I tried
> "Clear IDL" and .Reset, and .Full_reset. Same thing: once I recompile,
> run and kill the object tree, IDLGRFONT would still always be found by
> Heap_gc. It was not a fake, as its heap ID would be always higher each time.
> Frustrated, I quit IDL and restarted. What do you think? It stopped
> doing that. I swear the code is the same, because I went through every
> single line checking it, saved it, tried it, got a leak and quit IDL.
> But after restart IDLGRFONT stopped appearing in the heap.
> I have no idea what it was, but it certainly complicated my leak search.
Etc., etc., etc.
> Does anybody have an explanation?
Yes, but I'm saving it for the IDL EPA exam. :-)
Cheers,
David
P.S. Let's just say now would be a good time to put
on that Lauridsen Lux Aeterna CD and light a candle. :-)
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
