Pixmap primitive failed problems.
Locked
Pixmap primitive failed problems.
 
|
RE: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
Re: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
Re: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
In reply to this post by Ian Upright-2
Terry,
The WindowManager’s windows collection is empty – not even the debugger client window is in it (anymore). I’ve attached the reference path to one of two DoubleBufferingWindowDisplayPolicy instances that were not gc’d. The windowManager at entry #6 was empty.
I’d got into this situation by running the code in the workspace in my previous message. When the error notifier was shown I pressed Debug and changed the #retainedMediumToRepair: method as shown in entry 15 in the reference path, i.e. to return a 1x1 Pixmap if the real one was too big: pixmap := [Pixmap extent: windowExtent] on: Error do: [:ex | ex return: (Pixmap extent: 1@1)]. This change let the rest of the 100 windows be opened. I then did a gc and looked at the DoubleBufferingWindowDisplayPolicy instances. There were 100 as expected (the windows were still open). I then closed the windows and gc’d again, and two instances were left.
I could close all inspectors etc. and do “ObjectMemory globalGarbageCollect” as many times as I liked, but these two instances were still hanging around. Doing Debug | Open Process Monitor and closing it without doing anything, plus one last gc, was enough to make sure they got collected. Looks like opening and closing Process Monitor is enough to clear up the WindowManager registry so the empty WindowManager holding the #debugger ProcessEnvironment key is removed.
In this case the culprit was thus just the #debugger key (and whatever left the empty WindowManager): finalization probably still worked, and the two instances were correctly not gc’d, since there was a path to them. In other cases, even when ReferencePathCollector shows no paths, the instances are not gc’d until Process Monitor is opened (and maybe a process is debugged and run).
HTH, Steve
-----Original Message-----
Steve
I don’t see how this happens.
In the DebuggerClient>>postOpenWith: the debugger client is put into the process environmental variable #debugger. However, the process window manager should have only one window, the debugger client window. When the debugger exits this window should close and the process should be GC’d. It would be quite easy to remove the #debugger var in the #noticeOfWindowClose: method but this should not be necessary, so if it is needed then I think something else is wrong.
If you see this again please look to see if the window manager associated with the debugger client is controlling more than just the debugger client window.
Thanks. Terry From: Steven Kelly
[mailto:[hidden email]]
I just tried opening 100 double-buffering 1000x850 Workbooks, and got a primitiveFailed at number 77. After closing them all they refused to be garbage collected, even by a global gc.
Once again it was WindowManager ManagerRegistry that was holding on to them via the ProcessEnvironment #debugger entry. I promised Terry to return to that problem if I could cause it again, and have been putting it off, despite seeing it in my dev image about once a week. The debugger should remove its #debugger entry in the ProcessEnvironment when closing down.
Even after that, a global gc won’t remove the DoubleBufferingWindowDisplayPolicy instances. Inspecting the Reference Path for them shows that there is no such path. I can do global gcs till I’m blue in the face, but they won’t disappear. Doing the Process Monitor trick below gets rid of them 100%.
Would it be possible to address those two bugs? (And maybe the third: add code to release DoubleBufferingWindowDisplayPolicy pixmaps when the window is closed)
Cheers, Steve
-----Original Message-----
We used to hit a similar problem in VW 3 on Windows 95/98. A request for a Pixmap larger than 16MB (x * y * byteDepth) would fail. The problem was exacerbated back then because VW reported the screen bit depth incorrectly on some platforms. There was no double-buffering then: we saw the problem when allocating larger-than-screen Pixmaps for drawing print previews on.
From VW 5i.2 to 7.4 we’ve used GF/ST, which uses double buffering for its display pane – mostly larger than 740x577. We don’t use double buffering for windows (other than when resizing a pane, when VW temporarily changes to use double buffering). We sometimes use a batch process that will open 50-100 GF/ST windows sequentially, but I’ve never seen this problem.
I wonder if perhaps your window double buffering pixmaps are not being released? A quick look doesn’t reveal anywhere that explicitly releases them (hope I’m wrong on that!), but they should presumably be released when the Pixmap is garbage collected and finalized.
However, we constantly find that the finalization mechanism breaks, and objects are not finalized despite attempts to hurry things along by ObjectMemory globalGarbageCollect or leaving everything idle for a while. One trick always seems to work to get finalization going again: Debug | Open Process Monitor, select a process, debug it, choose Run to resume it and close the debugger, close the Process Monitor, do ObjectMemory globalGarbageCollect.
In any case, even if VW’s gc/finalization wasn’t broken, I wouldn’t rely on it for something as scarce and easily consumed as OS Pixmaps. Try releasing the pixmaps more explicitly, e.g. by making ScheduledWindow>>release send damageRepairPolicy release, and having DoubleBufferingWindowDisplayPolicy>>release send “pixmap close” (or whatever is the appropriate way to release a pixmap). Do let us know if that helps or not!
HTH, Steve
-----Original Message-----
Hello, I’ve patched my image to have a method like this:
extent: aPoint on: aGraphicsDevice initialize: doInitialize "Answer a new instance with the specified extent that can be displayed on aGraphicsDevice. If doInitialize is true, initialize the contents by clearing the receiver to the default background color; otherwise, the initial contents are undefined."
| surface | [ surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice extent: aPoint]. ] on: Error do:[ :ex | Transcript nextPutAll: 'Pixmap failed size: ', aPoint printString; cr. surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice extent: 800@300]. ]. surface changeExtent: aPoint. doInitialize ifTrue: [surface clear]. ^surface
After a while, throughout our application, our Transcript starts getting filled with these messages.. It seems smaller Pixmap allocations are fine, like 800@300, or 500@500, but allocations of size 740@577, for example, fail. I can allocate loads of bitmaps at the size of 800@300, when slightly larger sizes fail. That’s why the patch above mostly works, although as you can imagine there are serious display problems and parts of the screen are cut off when this problem happens. This problem is prevalent and exhibits itself wherever any window is using double buffering. We experience this on a variety of Windows XP boxes, using a variety of different video drivers. We haven’t found too many machines where this problem doesn’t happen. It may be this problem only exists with 24/32 bit color depth.
As you can imagine, it’s quite annoying, and has been plaguing us for years.. I believe this problem exists from 5i through 7.4, but never existed on VW 3. Can anyone shed some light onto this problem? We may be faced with debugging the VM sources to see what is happening, but wondered if others have seen this before.
Thanks, Ian
|
referencepath1.txt (6K)
RE: Pixmap primitive failed problems.
|
|
In reply to this post by Ian Upright-2
If anyone else wants to try the basic problem of running out of OS Pixmaps, there’s a workspace attached.
The funny thing is, whenever I try to neaten things up so they can be executed in a workspace like this, I don’t see the #debugger or finalization dying problems anymore. Maybe those are caused by operations in the debugger, while I try to change the messages that create Pixmaps so that I can continue in an image that has just run out of OS resources?
Steve
-----Original Message-----
I just tried opening 100 double-buffering 1000x850 Workbooks, and got a primitiveFailed at number 77. After closing them all they refused to be garbage collected, even by a global gc.
Once again it was WindowManager ManagerRegistry that was holding on to them via the ProcessEnvironment #debugger entry. I promised Terry to return to that problem if I could cause it again, and have been putting it off, despite seeing it in my dev image about once a week. The debugger should remove its #debugger entry in the ProcessEnvironment when closing down.
Even after that, a global gc won’t remove the DoubleBufferingWindowDisplayPolicy instances. Inspecting the Reference Path for them shows that there is no such path. I can do global gcs till I’m blue in the face, but they won’t disappear. Doing the Process Monitor trick below gets rid of them 100%.
Would it be possible to address those two bugs? (And maybe the third: add code to release DoubleBufferingWindowDisplayPolicy pixmaps when the window is closed)
Cheers, Steve
-----Original Message-----
We used to hit a similar problem in VW 3 on Windows 95/98. A request for a Pixmap larger than 16MB (x * y * byteDepth) would fail. The problem was exacerbated back then because VW reported the screen bit depth incorrectly on some platforms. There was no double-buffering then: we saw the problem when allocating larger-than-screen Pixmaps for drawing print previews on.
From VW 5i.2 to 7.4 we’ve used GF/ST, which uses double buffering for its display pane – mostly larger than 740x577. We don’t use double buffering for windows (other than when resizing a pane, when VW temporarily changes to use double buffering). We sometimes use a batch process that will open 50-100 GF/ST windows sequentially, but I’ve never seen this problem.
I wonder if perhaps your window double buffering pixmaps are not being released? A quick look doesn’t reveal anywhere that explicitly releases them (hope I’m wrong on that!), but they should presumably be released when the Pixmap is garbage collected and finalized.
However, we constantly find that the finalization mechanism breaks, and objects are not finalized despite attempts to hurry things along by ObjectMemory globalGarbageCollect or leaving everything idle for a while. One trick always seems to work to get finalization going again: Debug | Open Process Monitor, select a process, debug it, choose Run to resume it and close the debugger, close the Process Monitor, do ObjectMemory globalGarbageCollect.
In any case, even if VW’s gc/finalization wasn’t broken, I wouldn’t rely on it for something as scarce and easily consumed as OS Pixmaps. Try releasing the pixmaps more explicitly, e.g. by making ScheduledWindow>>release send damageRepairPolicy release, and having DoubleBufferingWindowDisplayPolicy>>release send “pixmap close” (or whatever is the appropriate way to release a pixmap). Do let us know if that helps or not!
HTH, Steve
-----Original Message-----
Hello, I’ve patched my image to have a method like this:
extent: aPoint on: aGraphicsDevice initialize: doInitialize "Answer a new instance with the specified extent that can be displayed on aGraphicsDevice. If doInitialize is true, initialize the contents by clearing the receiver to the default background color; otherwise, the initial contents are undefined."
| surface | [ surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice extent: aPoint]. ] on: Error do:[ :ex | Transcript nextPutAll: 'Pixmap failed size: ', aPoint printString; cr. surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice extent: 800@300]. ]. surface changeExtent: aPoint. doInitialize ifTrue: [surface clear]. ^surface
After a while, throughout our application, our Transcript starts getting filled with these messages.. It seems smaller Pixmap allocations are fine, like 800@300, or 500@500, but allocations of size 740@577, for example, fail. I can allocate loads of bitmaps at the size of 800@300, when slightly larger sizes fail. That’s why the patch above mostly works, although as you can imagine there are serious display problems and parts of the screen are cut off when this problem happens. This problem is prevalent and exhibits itself wherever any window is using double buffering. We experience this on a variety of Windows XP boxes, using a variety of different video drivers. We haven’t found too many machines where this problem doesn’t happen. It may be this problem only exists with 24/32 bit color depth.
As you can imagine, it’s quite annoying, and has been plaguing us for years.. I believe this problem exists from 5i through 7.4, but never existed on VW 3. Can anyone shed some light onto this problem? We may be faced with debugging the VM sources to see what is happening, but wondered if others have seen this before.
Thanks, Ian
|
RE: Pixmap primitive failed problems.
|
|
RE: Pixmap primitive failed problems.
|
|
In reply to this post by Steven Kelly
Hurray!!! Thanks for the test code Steve. The attached fileIn fixes the bug in my
image. Let me know if it works for you. It may also fix a few other
problems related to invalid WindowManagers. But then again it may introduce a new bug.
J Terry From: Steven Kelly
[mailto:[hidden email]] If anyone else wants to try the basic problem of running out
of OS Pixmaps, there’s a workspace attached. The funny thing is, whenever I try to neaten things up so
they can be executed in a workspace like this, I don’t see the #debugger or
finalization dying problems anymore. Maybe those are caused by operations in
the debugger, while I try to change the messages that create Pixmaps so that I
can continue in an image that has just run out of OS resources? Steve -----Original Message----- I just tried opening 100 double-buffering 1000x850 Workbooks,
and got a primitiveFailed at number 77. After closing them all they refused to
be garbage collected, even by a global gc. Once again it was WindowManager ManagerRegistry that was
holding on to them via the ProcessEnvironment #debugger entry. I promised Terry
to return to that problem if I could cause it again, and have been putting it
off, despite seeing it in my dev image about once a week. The debugger should
remove its #debugger entry in the ProcessEnvironment when closing down. Even after that, a global gc won’t remove the
DoubleBufferingWindowDisplayPolicy instances. Inspecting the Reference Path for
them shows that there is no such path. I can do global gcs till I’m blue
in the face, but they won’t disappear. Doing the Process Monitor trick
below gets rid of them 100%. Would it be possible to address those two bugs? (And maybe
the third: add code to release DoubleBufferingWindowDisplayPolicy pixmaps when
the window is closed) Cheers, Steve -----Original Message----- We used to hit a similar problem in VW 3 on Windows 95/98. A
request for a Pixmap larger than 16MB (x * y * byteDepth) would fail. The
problem was exacerbated back then because VW reported the screen bit depth
incorrectly on some platforms. There was no double-buffering then: we saw the
problem when allocating larger-than-screen Pixmaps for drawing print previews
on. From VW 5i.2 to 7.4 we’ve used GF/ST, which uses
double buffering for its display pane – mostly larger than 740x577. We
don’t use double buffering for windows (other than when resizing a pane,
when VW temporarily changes to use double buffering). We sometimes use a batch
process that will open 50-100 GF/ST windows sequentially, but I’ve never
seen this problem. I wonder if perhaps your window double buffering pixmaps are
not being released? A quick look doesn’t reveal anywhere that explicitly
releases them (hope I’m wrong on that!), but they should presumably be
released when the Pixmap is garbage collected and finalized. However, we constantly find that the finalization mechanism
breaks, and objects are not finalized despite attempts to hurry things along by
ObjectMemory globalGarbageCollect or leaving everything idle for a while. One
trick always seems to work to get finalization going again: Debug | Open
Process Monitor, select a process, debug it, choose Run to resume it and close
the debugger, close the Process Monitor, do ObjectMemory globalGarbageCollect. In any case, even if VW’s gc/finalization wasn’t
broken, I wouldn’t rely on it for something as scarce and easily consumed
as OS Pixmaps. Try releasing the pixmaps more explicitly, e.g. by making
ScheduledWindow>>release send damageRepairPolicy release, and having
DoubleBufferingWindowDisplayPolicy>>release send “pixmap
close” (or whatever is the appropriate way to release a pixmap). Do let
us know if that helps or not! HTH, Steve -----Original Message----- Hello, I’ve patched my image to have a method like
this: extent: aPoint on: aGraphicsDevice initialize: doInitialize
"Answer a new instance with the specified extent that can be displayed on
aGraphicsDevice. If doInitialize is true, initialize the contents by clearing
the
receiver to the default background color; otherwise, the initial contents are
undefined."
| surface |
[
surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice
extent: aPoint].
] on: Error do:[ :ex |
Transcript nextPutAll: 'Pixmap failed size: ', aPoint printString; cr.
surface := super new handleValue: [self allocateHandleOn: aGraphicsDevice
extent: 800@300].
].
surface changeExtent: aPoint.
doInitialize ifTrue: [surface clear].
^surface After a while, throughout our application, our Transcript
starts getting filled with these messages.. It seems smaller Pixmap
allocations are fine, like 800@300, or 500@500, but allocations of size
740@577, for example, fail. I can allocate loads of bitmaps at the size
of 800@300, when slightly larger sizes fail. That’s why the
patch above mostly works, although as you can imagine there are serious display
problems and parts of the screen are cut off when this problem happens.
This problem is prevalent and exhibits itself wherever any window is using
double buffering. We experience this on a variety of Windows
XP boxes, using a variety of different video drivers. We haven’t
found too many machines where this problem doesn’t happen. It may
be this problem only exists with 24/32 bit color depth. As you can imagine, it’s quite annoying, and has been
plaguing us for years.. I believe this problem exists from 5i through 7.4, but
never existed on VW 3. Can anyone shed some light onto this
problem? We may be faced with debugging the VM sources to see what is
happening, but wondered if others have seen this before. Thanks, Ian |
| Free forum by Nabble | Edit this page |