[7.8] Pixmap - a primitive has failed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[7.8] Pixmap - a primitive has failed

Boris Popov, DeepCove Labs (SNN)

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
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] Pixmap - a primitive has failed

Ralf Propach
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
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] Pixmap - a primitive has failed

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] Pixmap - a primitive has failed

Ralf Propach
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
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] Pixmap - a primitive has failed

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] Pixmap - a primitive has failed

Ulli Wenk
Hi Boris,

excuse me, please, answering so late ( I was out of business).

06.07.2011 16:06, Boris Popov, DeepCove Labs, wrote:
Ralf,

That makes sense, thanks. It's only this one user at the moment
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.
, and only started happening in 7.8-based images
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.
, 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 as

      
base is concerned?

As a side note, the SupportWeb FTP doesn't appear to be working as far

      
as VisualWorks resolutions are concerned,Ralf

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc