One of our users is reporting frequent occurrences of the below on a 7.8-based version of our RTP’ed application, has anyone else run into issues with DoubleBufferingWindowDisplayPolicy that ultimately fails due to inability to allocate new pixmaps? ==2011/7/5==9:28:00==BEGIN RUNTIME DIAGNOSTIC DUMP Note: this file stored in VisualWorks #source (UTF-8) encoding Cause of Dump: Unhandled exception: a primitive has failed Image Identification: 'Image created July 4, 2011 1:32:24 PM' Smalltalk Version: 'VisualWorks®, 7.8 of March 30, 2011' Object Memory versionId: #[70 47 70 128 78 0 0 0 70 47 70 128] Class creating this dump: RuntimeFullDumper ------------------------------------------------------------ Active Process Process named: 'Raven v9064' Process priority: 50 Process identity hash: 5883 Context Stack: [1] HandleRegistry>>evaluateWithFullProtection: [2] HandleRegistry>>registerValueOf: [3] Pixmap class(OSHandle class)>>registerValueOf: [4] optimized [] in DisplaySurface>>handleValue: [5] BlockClosure>>ifCurtailed: [6] Pixmap(DisplaySurface)>>handleValue: [7] Pixmap class(UnmappableSurface class)>>extent:on:initialize: [8] Pixmap class(UnmappableSurface class)>>extent:on: [9] Pixmap class(UnmappableSurface class)>>extent: [10] DoubleBufferingWindowDisplayPolicy>>retainedMediumToRepair: [11] DoubleBufferingWindowDisplayPolicy>>displayDamageList:in: [12] ScheduledWindow>>displayDamageEvent: [13] ScheduledWindow>>checkForEvents [14] optimized [] in [] in WindowManager>>repairDamagesExcept: [15] OrderedCollection>>do: [16] optimized [] in WindowManager>>repairDamagesExcept: [17] BlockClosure>>on:do: [18] WindowManager>>repairDamagesExcept: [19] WindowManager>>repairDamages [20] WindowManager>>processNextEvent [21] optimized [] in [] in WindowManager>>newProcess [22] BlockClosure>>on:do: [23] optimized [] in WindowManager>>newProcess [24] BlockClosure>>on:do: [25] optimized [] in Process class>>forBlock:priority: ------------------------------------------------------------ Unhandled Exception: class: UnhandledException creator: UnhandledException errorString: Unhandled exception: a primitive has failed parameter: an Error ------------------------------------------------------------ Initial Context Stack Arguments: [1] HandleRegistry>>evaluateWithFullProtection: Receiver: (id=16293) a HandleRegistry protected by a RecursionLock with (17->a Pixmap 18->a Mask 2... Arg1: (id=9749) BlockClosure [] in HandleRegistry>>registerValueOf: [2] HandleRegistry>>registerValueOf: Receiver: (id=16293) a HandleRegistry protected by a RecursionLock with (17->a Pixmap 18->a Mask 2... Arg1: (id=3490) BlockClosure [] in [] in DisplaySurface>>handleValue: [3] Pixmap class(OSHandle class)>>registerValueOf: Receiver: (id=1965) Pixmap Arg1: (id=3490) BlockClosure [] in [] in DisplaySurface>>handleValue: [5] BlockClosure>>ifCurtailed: Receiver: (id=13615) BlockClosure [] in DisplaySurface>>handleValue: Arg1: (id=7356) BlockClosure [] in DisplaySurface>>handleValue: [6] Pixmap(DisplaySurface)>>handleValue: Receiver: (id=1097) a Pixmap Arg1: (id=11222) BlockClosure [] in UnmappableSurface class>>extent:on:initialize: [7] Pixmap class(UnmappableSurface class)>>extent:on:initialize: Receiver: (id=1965) Pixmap Arg1: (id=4963) 2048 @ 1152 Arg2: (id=15088) a Screen Arg3: (id=3) true [8] Pixmap class(UnmappableSurface class)>>extent:on: Receiver: (id=1965) Pixmap Arg1: (id=4963) 2048 @ 1152 Arg2: (id=15088) a Screen [9] Pixmap class(UnmappableSurface class)>>extent: Receiver: (id=1965) Pixmap Arg1: (id=4963) 2048 @ 1152 [10] DoubleBufferingWindowDisplayPolicy>>retainedMediumToRepair: Receiver: (id=8829) a DoubleBufferingWindowDisplayPolicy Arg1: (id=2570) a ScheduledWindow 39 [11] DoubleBufferingWindowDisplayPolicy>>displayDamageList:in: Receiver: (id=8829) a DoubleBufferingWindowDisplayPolicy Arg1: (id=12695) #(522 @ 170 corner: 542 @ 190 544 @ 170 corner: 721 @ 191 1736 @ 170 corner: ... Arg2: (id=2570) a ScheduledWindow 39 [12] ScheduledWindow>>displayDamageEvent: Receiver: (id=2570) a ScheduledWindow 39 Arg1: (id=12695) #(522 @ 170 corner: 542 @ 190 544 @ 170 corner: 721 @ 191 1736 @ 170 corner: ... [13] ScheduledWindow>>checkForEvents Receiver: (id=2570) a ScheduledWindow 39 [15] OrderedCollection>>do: Receiver: (id=6436) OrderedCollection (a ScheduledWindow 39) Arg1: (id=177) BlockClosure [] in [] in WindowManager>>repairDamagesExcept: [17] BlockClosure>>on:do: Receiver: (id=10302) BlockClosure [] in WindowManager>>repairDamagesExcept: Arg1: (id=12339) ClosedWindowNotification Arg2: (id=4512) BlockClosure [] in WindowManager>>repairDamagesExcept: [18] WindowManager>>repairDamagesExcept: Receiver: (id=4043) a WindowManager Arg1: (id=1) nil [19] WindowManager>>repairDamages Receiver: (id=4043) a WindowManager [20] WindowManager>>processNextEvent Receiver: (id=4043) a WindowManager [22] BlockClosure>>on:do: Receiver: (id=14168) BlockClosure [] in [] in WindowManager>>newProcess Arg1: (id=3873) TerminateException Arg2: (id=7909) BlockClosure [] in [] in WindowManager>>newProcess [24] BlockClosure>>on:do: Receiver: (id=1650) BlockClosure [] in WindowManager>>newProcess Arg1: (id=3873) TerminateException Arg2: (id=9271) BlockClosure [] in [] in Process class>>forBlock:priority: ------------------------------------------------------------ Quiescent Processes Process named: 'IdleLoopProcess' Process priority: 10 Process identity hash: 11775 Context Stack: [1] Semaphore>>wait [2] ObjectMemory class>>idleLoop [3] optimized [] in ObjectMemory class>>installIdleLoopProcess [4] BlockClosure>>on:do: [5] optimized [] in Process class>>forBlock:priority: ------------------------------------------------------------ Suspended Processes Process named: 'TimerProcess' Process priority: 100 Process identity hash: 5516 Context Stack: [1] Semaphore>>wait [2] optimized [] in ClassicTimerSupport class>>timingLoop [3] BlockClosure>>repeat [4] ClassicTimerSupport class>>timingLoop [5] optimized [] in ClassicTimerSupport class>>configureTimerSystem [6] BlockClosure>>on:do: [7] optimized [] in Process class>>forBlock:priority: Process named: 'ForeignCallbackProcess' Process priority: 85 Process identity hash: 15641 Context Stack: [1] Semaphore>>wait [2] optimized [] in CCallback class>>installForeignCallbackProcess [3] BlockClosure>>on:do: [4] optimized [] in Process class>>forBlock:priority: Process named: 'InputStateIOProcess' Process priority: 90 Process identity hash: 9382 Context Stack: [1] Semaphore>>wait [2] InputState>>run [3] optimized [] in InputState class>>install [4] BlockClosure>>on:do: [5] optimized [] in Process class>>forBlock:priority: Process named: 'FinalizationProcess' Process priority: 98 Process identity hash: 3123 Context Stack: [1] Semaphore>>wait [2] WeakArray class>>outerFinalizationLoop [3] optimized [] in WeakArray class>>installFinalizationMechanism [4] BlockClosure>>on:do: [5] optimized [] in Process class>>forBlock:priority: Process named: 'CallbackProcess' Process priority: 89 Process identity hash: 13248 Context Stack: [1] Semaphore>>wait [2] optimized [] in [] in [] in CCallback class>>installCallbackProcess [3] BlockClosure>>on:do: [4] optimized [] in [] in CCallback class>>installCallbackProcess [5] BlockClosure>>on:do: [6] optimized [] in CCallback class>>installCallbackProcess [7] BlockClosure>>on:do: [8] optimized [] in Process class>>forBlock:priority: Process named: 'ForeignCallbackProcess' Process priority: 85 Process identity hash: 6989 Context Stack: [1] Semaphore>>wait [2] optimized [] in CCallback class>>installForeignCallbackProcess [3] BlockClosure>>on:do: [4] optimized [] in Process class>>forBlock:priority: Process named: 'LowSpaceProcess' Process priority: 95 Process identity hash: 730 Context Stack: [1] Semaphore>>wait [2] ObjectMemory class>>lowSpaceLoop [3] optimized [] in ObjectMemory class>>installLowSpaceProcess [4] BlockClosure>>on:do: [5] optimized [] in Process class>>forBlock:priority: Process named: 'IdleLoopProcess' Process priority: 10 Process identity hash: 11775 Context Stack: [1] Semaphore>>wait [2] ObjectMemory class>>idleLoop [3] optimized [] in ObjectMemory class>>installIdleLoopProcess [4] BlockClosure>>on:do: [5] optimized [] in Process class>>forBlock:priority: Process named: 'ScavengeProcess' Process priority: 90 Process identity hash: 10855 Context Stack: [1] Semaphore>>wait [2] optimized [] in ObjectMemory class>>installScavengeNotification [3] BlockClosure>>on:do: [4] optimized [] in Process class>>forBlock:priority: Process named: 'TimerActionProcess' Process priority: 70 Process identity hash: 4596 Context Stack: [1] Semaphore>>waitIfCurtailedSignal [2] SharedQueue>>next [3] ClassicTimerSupport class>>actionLoop [4] optimized [] in ClassicTimerSupport class>>configureTimerSystem [5] BlockClosure>>on:do: [6] optimized [] in Process class>>forBlock:priority: ------------------------------------------------------------ Transcript: <<<BEGIN TRANSCRIPT>>> <<<END TRANSCRIPT>>> ------------------------------------------------------------ External Database Connections (all instances): an ODBCConnection'( hdbc = 37A1A20 ) hash: 14721 state: #xactNo username: nil environment: nil an ODBCConnection( hdbc = 37A1A20 ) hash: 8462 state: #xactNo username: nil environment: '<emptied>' External Database Sessions (all instances): an ODBCSession'( hstmt = 37A2A60 ) state: #prepared connection hash: 8462 query: nil an ODBCSession( hstmt = 37A2A60 ) state: #prepared connection hash: 8462 query: '<emptied>' ------------------------------------------------------------ Scheduled Windows: a ScheduledWindow 39 label: 'System - Raven v9064' model class: SuperModule 40 @ 36 displayContents: '<emptied>' 620 @ 199 displayContents: '<emptied>' 620 @ 231 displayContents: '<emptied>' 620 @ 263 displayContents: '<emptied>' 620 @ 295 displayContents: '' 620 @ 343 displayContents: '8/25/04 10:02:00 AM' 620 @ 375 displayContents: '' 620 @ 407 displayContents: '' 10 @ 168 selection: Text for '<emptied>' ==2011/7/5==9:28:00==END RUNTIME DIAGNOSTIC DUMP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Boris Popov, DeepCove Labs wrote:
> One of our users is reporting frequent occurrences of the below on a > 7.8-based version of our RTP'ed application, has anyone else run into > issues with DoubleBufferingWindowDisplayPolicy that ultimately fails due > to inability to allocate new pixmaps? > > > Hi Boris, yes, others have also reported such a problem. You could try Resolution 99883 as a work-around. Regards, Ralf -- Ralf Propach, [hidden email] Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 Georg Heeg eK (Dortmund) Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Ralf,
I'd asked support for a copy, are you surprised it's listed as a fix for 7.7, so presumably it's not an integrate-able resolution as far as base is concerned? As a side note, the SupportWeb FTP doesn't appear to be working as far as VisualWorks resolutions are concerned, Resolving host name "198.8.67.4" ... Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 23525 ) Connected (198.8.67.4:23525) <<< MLSD >>> 150 Accepted data connection FIN received Data connection closed >>> 226-Options: -a -l >>> 226 11 matches total <<< CWD /support/ >>> 250 OK. Current directory is /support <<< PASV >>> 227 Entering Passive Mode (198,8,67,4,131,70) Resolving host name "198.8.67.4" ... Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 33606 ) Connected (198.8.67.4:33606) <<< MLSD >>> 150 Accepted data connection FIN received Data connection closed >>> 226-Options: -a -l >>> 226 31 matches total <<< CWD /support/VisualWorks/ >>> 550 Can't change directory to /support/VisualWorks/: Permission denied -Boris -----Original Message----- From: Ralf Propach [mailto:[hidden email]] Sent: Wednesday, July 06, 2011 3:39 AM To: Boris Popov, DeepCove Labs Cc: [hidden email] Subject: Re: [vwnc] [7.8] Pixmap - a primitive has failed Boris Popov, DeepCove Labs wrote: > One of our users is reporting frequent occurrences of the below on a > 7.8-based version of our RTP'ed application, has anyone else run into > issues with DoubleBufferingWindowDisplayPolicy that ultimately fails > due to inability to allocate new pixmaps? > > > Hi Boris, yes, others have also reported such a problem. You could try Resolution 99883 as a work-around. Regards, Ralf -- Ralf Propach, [hidden email] Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 Georg Heeg eK (Dortmund) Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Boris,
I am not surprised. It is really only a work-around. Whenever the DoubleBufferingWindowDisplayPolicy fails to allocate the pixmap it uses as a buffer, it falls back to non-doubleBuffered displaying. Ralf Boris Popov, DeepCove Labs wrote: > Ralf, > > I'd asked support for a copy, are you surprised it's listed as a fix for > 7.7, so presumably it's not an integrate-able resolution as far as base > is concerned? > > As a side note, the SupportWeb FTP doesn't appear to be working as far > as VisualWorks resolutions are concerned, > > Resolving host name "198.8.67.4" ... > Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 23525 ) > Connected (198.8.67.4:23525) > <<< MLSD >>>>150 Accepted data connection > FIN received > Data connection closed >>>>226-Options: -a -l >>>>226 11 matches total > <<< CWD /support/ >>>>250 OK. Current directory is /support > <<< PASV >>>>227 Entering Passive Mode (198,8,67,4,131,70) > Resolving host name "198.8.67.4" ... > Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 33606 ) > Connected (198.8.67.4:33606) > <<< MLSD >>>>150 Accepted data connection > FIN received > Data connection closed >>>>226-Options: -a -l >>>>226 31 matches total > <<< CWD /support/VisualWorks/ >>>>550 Can't change directory to /support/VisualWorks/: Permission > denied > > -Boris > > -----Original Message----- > From: Ralf Propach [mailto:[hidden email]] > Sent: Wednesday, July 06, 2011 3:39 AM > To: Boris Popov, DeepCove Labs > Cc: [hidden email] > Subject: Re: [vwnc] [7.8] Pixmap - a primitive has failed > > Boris Popov, DeepCove Labs wrote: >>One of our users is reporting frequent occurrences of the below on a >>7.8-based version of our RTP'ed application, has anyone else run into >>issues with DoubleBufferingWindowDisplayPolicy that ultimately fails >>due to inability to allocate new pixmaps? >> >> >> > Hi Boris, > > yes, others have also reported such a problem. You could try Resolution > 99883 as a work-around. > > Regards, > > Ralf > > -- > Ralf Propach, [hidden email] > Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 > Georg Heeg eK (Dortmund) > Handelsregister: Amtsgericht Dortmund A 12812 > > -- Ralf Propach, [hidden email] Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 Georg Heeg eK (Dortmund) Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Ralf,
That makes sense, thanks. It's only this one user at the moment, and only started happening in 7.8-based images, but it could be that something else is consuming the pixmaps on that machine... We'll keep an eye on it once we get the resolution from support. -Boris -----Original Message----- From: Ralf Propach [mailto:[hidden email]] Sent: Wednesday, July 06, 2011 10:05 AM To: Boris Popov, DeepCove Labs Cc: [hidden email] Subject: Re: [vwnc] [7.8] Pixmap - a primitive has failed Hi Boris, I am not surprised. It is really only a work-around. Whenever the DoubleBufferingWindowDisplayPolicy fails to allocate the pixmap it uses as a buffer, it falls back to non-doubleBuffered displaying. Ralf Boris Popov, DeepCove Labs wrote: > Ralf, > > I'd asked support for a copy, are you surprised it's listed as a fix > for 7.7, so presumably it's not an integrate-able resolution as far as > base is concerned? > > As a side note, the SupportWeb FTP doesn't appear to be working as far > as VisualWorks resolutions are concerned, > > Resolving host name "198.8.67.4" ... > Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 23525 ) > Connected (198.8.67.4:23525) <<< MLSD >>>>150 Accepted data connection > FIN received > Data connection closed >>>>226-Options: -a -l >>>>226 11 matches total > <<< CWD /support/ >>>>250 OK. Current directory is /support > <<< PASV >>>>227 Entering Passive Mode (198,8,67,4,131,70) > Resolving host name "198.8.67.4" ... > Opening data connection ( 198.8.67.4 => ip: 198.8.67.4, port: 33606 ) > Connected (198.8.67.4:33606) <<< MLSD >>>>150 Accepted data connection > FIN received > Data connection closed >>>>226-Options: -a -l >>>>226 31 matches total > <<< CWD /support/VisualWorks/ >>>>550 Can't change directory to /support/VisualWorks/: Permission > denied > > -Boris > > -----Original Message----- > From: Ralf Propach [mailto:[hidden email]] > Sent: Wednesday, July 06, 2011 3:39 AM > To: Boris Popov, DeepCove Labs > Cc: [hidden email] > Subject: Re: [vwnc] [7.8] Pixmap - a primitive has failed > > Boris Popov, DeepCove Labs wrote: >>One of our users is reporting frequent occurrences of the below on a >>7.8-based version of our RTP'ed application, has anyone else run into >>issues with DoubleBufferingWindowDisplayPolicy that ultimately fails >>due to inability to allocate new pixmaps? >> >> >> > Hi Boris, > > yes, others have also reported such a problem. You could try > Resolution > 99883 as a work-around. > > Regards, > > Ralf > > -- > Ralf Propach, [hidden email] > Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 > Georg Heeg eK (Dortmund) > Handelsregister: Amtsgericht Dortmund A 12812 > > -- Ralf Propach, [hidden email] Tel: +49 231 975 99 38 Fax: +49 231 975 99 20 Georg Heeg eK (Dortmund) Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
excuse me, please, answering so late ( I was out of business). 06.07.2011 16:06, Boris Popov, DeepCove Labs, wrote: No, we have had this error daily for some of our customers, too. After repairing it by using non-doubleBuffered displaying we have back the other problems: flickering of the GUIs. We and our customers are not very amused by this behavior. For more details, please ask Ralf, who is supporting us in that case.Ralf, That makes sense, thanks. It's only this one user at the moment No, our support case 424343 was created in November 2010 with VW 7.7 (VM and software). We did not consider the flickering in VW 7.6 even with the VM7.7., and only started happening in 7.8-based images , but it could be that something else is consuming the pixmaps on that machine... We'll keep an eye on it once we get the resolution from support. -Boris -----Original Message----- From: Ralf Propach [[hidden email]] Sent: Wednesday, July 06, 2011 10:05 AM To: Boris Popov, DeepCove Labs Cc: [hidden email] Subject: Re: [vwnc] [7.8] Pixmap - a primitive has failed Hi Boris, I am not surprised. It is really only a work-around. Whenever the DoubleBufferingWindowDisplayPolicy fails to allocate the pixmap it uses as a buffer, it falls back to non-doubleBuffered displaying. Ralf Boris Popov, DeepCove Labs wrote:Ralf, I'd asked support for a copy, are you surprised it's listed as a fix for 7.7, so presumably it's not an integrate-able resolution as far asbase is concerned? As a side note, the SupportWeb FTP doesn't appear to be working as faras VisualWorks resolutions are concerned,Ralf _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |