Symbian Developer Library

SYMBIAN OS V6.1 EDITION FOR C++

[Index] [Glossary] [Previous] [Next]



Window server panics


Overview

Panics from the window server may be raised by the W32 interface or by code in the window server itself.

The server runs continuously and brings the machine down if it crashes, so it cannot panic its own thread when it detects an error in one of its client’s requests. Instead it panics the client’s thread using RThread::Panic(). These panics have a category of WSERV.

W32 is a synchronous interface onto the window server that user code can include, link to and invoke instead of sending low level client-server requests to the window server. Some errors can be detected before they are sent to the server and are raised as panics from W32. Code in the W32 synchronous interface runs in the client’s thread, so it raises panics in situations it can understand on the current thread via User::Panic(). These panics have a category of W32.

To minimise strain on the system, W32 can cache several requests in order in a buffer and send them as a group to the server. This means that a panic might not be caused by a bug in the last client-side code to run, but by an earlier line that does not get its request serviced until later. To debug such a panic it is often useful to turn on auto flushing.

Note that some panics are raised in debug builds only.

[Top]


Window server synchronous interface (W32) panics

Panics whose category is W32 are raised by the synchronous interface onto the window server when it realises a client has attempted an action the interface can’t legally pass on to the window server thread. Because the interface is synchronous, the current thread is panicked, and the request is never sent to the window server.

These panics are defined in the enumeration TW32Panic of w32cmd.h.

1

An attempt was made to reconnect to the window server using RWsSession::Connect(). It is only possible to reconnect if the current session has been closed.

2

Not used.

3

Not used.

4

Not used.

5

TooManyPairsRaised by CWindowGc::MapColors() when more than 16 pairs of colours are declared in its aNumPairs argument.

6

introduced Version 6.0

A single string is too long to fit into the buffer.

[Top]


Window server panics

Panics with a category of WSERV are raised by the window server when it realises a client has requested something it can’t do. The requesting thread is panicked.

These panics are defined in the enumeration TClientPanic of w32cmd.h.

1

Out of range opcode.

The client has sent a request opcode that wasn’t recognised. Each server-side object can only handle some of the requests defined in the window server, and if the request isn’t recognised, this panic is raised.

Clients would normally only get this is if they bypass the normal W32 API.

2

Invalid command buffer.

A corrupt buffer of requests was discovered by the server. This is raised when the buffer itself is noticeably broken, and not when the commands in it are wrong.

3

Invalid handle.

The server couldn’t find the target object for a request in the handle index. This can be raised when a command is sent to the handle for a window that has been closed, for example.

4

A handle whose value was NULL was detected.

For example, when Constructing one of the subclasses of the client-side RWindowBase with a client handle argument of NULL.

On the server side, a TWsClCmdCreateWindow with a client handle field of NULL passed as argument to CWsClientWindow::ConstructL() will raise this error.

5

Not used.

6

Invalid window handle.

A handle which should have referred to a window of a particular type referred to a window of another type, or the object index didn’t recognise the handle.

On the server side, this panic is ultimately raised by CWsClient::HandleToWindow() and CWsClient::HandleToClientWindow() during handle conversions.

7

Invalid bitmap handle.

A corrupt bitmap handle was encountered. This is a common panic uncovered when a bitmap handle refers to nothing, or to a server-side object that isn’t a bitmap.

Also:

  • In response to an EWsGcOpUseBrushPattern request if the bitmap parameter couldn’t be used. On the client side, CWindowGc::UseBrushPattern() sends this request.

  • In response to an EWsSpriteOpAppendMember request when the bitmaps for the sprite member can't be created on the server side. On the client side, RWsSpriteBase::AppendMember() sends this request.

  • Any failed attempt to duplicate a supplied bitmap.

8

Event read already outstanding.

RWsSession::EventReady(), RWsSession::RedrawReady(), or RWsSession::PriorityKeyReady() was called again when an event read was already outstanding, i.e.. when an event was waiting to be delivered by the window server.

9

Attempted to use a non-active graphics context.

A drawing request was sent to a graphics context when the context was not active.

On the server side, this panic is raised by CWsGc::CommandL() on all requests received when the context isn’t active except EWsGcOpActivate, EWsGcOpDeactivate, EWsGcOpFree, and EWsGcOpTestInvariant.

10

Attempted to activate an already active graphics context.

On the server side, this is raised by CWsGc::Activate() as a response to a EWsGcOpActivate request.

The request is sent by the client-side method CWindowGc::Activate().

11

Window already active.

An attempt was made to reactivate an active window. The request is sent by the client-side method RWindowBase::Activate().

On the server side, this panic is raised by CWsClientWindow::Activate() in response to an EWsWinOpActivate request.

12

Already inside a begin/end redraw pair.

A begin-redraw window request was made when the window had already begun redrawing. Begin-redraw messages are paired with end-redraw messages, and ordering is important. Invoking RWindow::BeginRedraw(), then RWindow::BeginRedraw() again before the corresponding RWindow::EndRedraw() raises this panic.

On the server side, this panic is raised if an EWsWinOpBeginRedraw request is sent twice before the closing EWsWinOpEndRedraw.

13

Invalid font handle.

On the client-side is raised if CWindowGc::UseFont() is called with an invalid font handle.

On the server side, CWsGc::SetGcAttribute() raises this error in response to an EWsGcOpUseFont request.

14

Printing with no active font.

A command to draw text to a window was sent to a graphics context when no font was set. Any of the overloads of CWindowGc::DrawTextVertical() or CWindowGc::DrawText() might cause the panic to be raised; the font should be set using CWindowGc::UseFont() first.

On the server side, this panic is raised by CWsGc::DoDrawCommand() in response to any of the requests to display text defined in TWsGcOpcodes.

15

Attempted to set invalid text cursor type.

An invalid cursor type was passed to the window server. Valid types are defined in the TTextCursor struct in w32std.h.

This panic is raised in response to a call to RWsTextCursor::Set().

The exact set of valid text cursor types may increase with time.

16

A drawing command was sent to a graphics context active on a group window.

17

Not used.

18

Not used.

19

Attempted to use a patterned brush when the pattern bitmap has not yet been set — UseBrushPattern().

20

Not used.

21

Attempted to do a client destroy function on an illegal handle.

A client tried to destroy or cancel a server-side object by its handle on an unrecognised handle, or on a handle of the wrong type for the operation.

This panic may be caused by the RWindowGroup::CancelCaptureKeyUpAndDowns() or RWindowGroup::CancelCaptureKey() methods. These correspond to the EWsWinOpCancelCaptureKeyUpsAndDowns and EWsWinOpCancelCaptureKey server requests. In this case, the panic means that there is no such capture key object in existence in the target window group.

22

Panic from the Anim DLL.

An animation DLL tried either changing its default or next timing interval when its timing mode was set to ESyncNone, or activating a graphics context when the context was already activated.

There are a variety of other reasons why this panic might be raised, all which are Anim DLL related. The Animation writer can also cause functions raise this panic.

23

Invalid Anim object handle.

A null animation handle was detected in the server on receipt of an animation command, possibly because the relevant animation has been deleted. This panic may be raised by a subclass of RAnim calling RAnim::Command() or RAnim::CommandReply().

On the server side, the EWsAnimDllOpCommandReply and EWsAnimDllOpCommand requests can raise this panic in CWsAnimDll.

24

Leave from a non-leaving animation function.

Code in an animated DLL called by the server invoked Leave(). Animated DLL code is provided by the client and run by the server, so unhandled leaves are trapped and the notification is passed on as a client panic.

25

Not used.

26

Not used.

27

Not used.

28

Inconsistent polygon or polyline data was supplied. For example when restarting without finishing an old polygon.

29

A client attempted to set a negative shadow height.

This panic is caused by a call to RWindowBase::SetShadowHeight() with a negative argument.

On the server side, CWsClientWindow::CommandL() raises the panic in response to an invalid EWsWinOpSetShadowHeight request.

30

Not used.

31

The client tried to construct a window with an invalid redraw type. The valid redraw types defined in the enumeration TWinTypes of w32cmd.h.

On the server side, this panic is raised by CWsClientWindow::ConstructL() in response to an initialisation message containing an invalid redraw type.

32

A server-side redraw region is almost certainly corrupt.

This panic is raised when an EWsWinOpGetInvalidRegion is received by a CWsRedrawMsgWindow with a TInt parameter of zero or less.

33

The client failed to provide a reply buffer to a server-side function when one was needed.

All server-side functions that need more space for their reply than a TInt use the client’s reply buffer. If the client fails to provide space for such replies, this panic will be emitted.

This panic is raised by CWsClient::ReplyBuf() when CWsClient’s reply buffer is null.

34

Not used.

35

A client passed an invalid or unrecognised corner type or flag.

This panic is raised in response to a client call to RWindowBase::SetCornerType() when specifying inconsistent or non-existent flags.

Valid flags are masked by ECornerTypeMask, and recognised types are defined in TCornerType. These are all defined in w32std.h.

The server raises this panic as a response to EWsWinOpSetCornerType request with an undefined corner type or an unrecognised flag in its parameters.

36

The server was asked to update a region of a backed-up window which has not had MaintainBackup called on it.

A client-side call to either form of RBackedUpWindow::UpdateScreen() may raise this panic.

On the server side, the panic is raised in response to an EWsWinOpUpdateScreenRegion or EWsWinOpUpdateScreen request when not maintaining a full backup of a backed-up window.

37

Panic raised when it was not possible to read or write data to the client thread. The data is usually contained in a descriptor.

38

The client attempted to access a sprite after the sprite's window was destroyed. Note that pointer cursors are implemented as sprites.

39

A client requested event data without having received an event telling it that the data was ready.

40

The mask for a sprite is smaller than the sprite’s bitmap. A mask is permitted to be larger than its bitmap.

41

Bad sprite handle.

A null sprite handle was encountered, or a handle which was supposed to refer to a sprite referred to something else.

The client-side methods RWindowTreeNode::SetCustomPointerCursor() and RWsSession::SetSystemPointerCursor(), amongst others, can cause this panic to be raised; they correspond to the server requests EWsWinOpSetCustomPointerCursor and EWsClOpSetSystemPointerCursor.

42

A client attempted to set or clear a system pointer cursor without first owning the list of system pointer cursors.

RWsSession::SetSystemPointerCursor() and RWsSession::ClearSystemPointerCursor() can raise this panic. See also RWsSession::ClaimSystemPointerCursorList() and RWsSession::FreeSystemPointerCursorList().

The server requests which can raise this panic are EWsClOpSetSystemPointerCursor and EWsClOpClearSystemPointerCursor.

43

A client attempted to enable a pointer move buffer when none was allocated.

RWindowBase::EnablePointerMoveBuffer() can cause this panic to be emitted; the corresponding server request is EWsWinOpEnablePointerMoveBuffer.

44

Raised in response to commands that send a string, when the string has been incorrectly stored in the command buffer.

45

Not used.

46

An invalid call or request parameter was detected by CWsPassword. This can be caused:

  • By RWindowBase::PasswordWindow() sending an EWsWinOpPasswordWindow server request whose password mode parameter is not recognised.

  • By an attempt to cancel the password window by a client which doesn’t own the window.

  • By RWsSession::PasswordEntered() sending a EWsClOpPasswordEntered server request when no password window has been set, or when the client does not own the password window.

Valid password modes are defined in TPasswordMode of w32std.h.

47

An invalid compute mode was sent to the window server. On the client side, RWsSession::ComputeMode() can do this, the window server request is EWsClOpComputeMode. Valid compute modes are defined in the enumeration RWsSession::TComputeMode, which is declared in w32std.h.

48

A client attempted to set the display mode of a backed-up window. This can be done with RWindowBase::SetRequiredDisplayMode() or the EWsWinOpRequiredDisplayMode server request.

49

A client attempted to get a message when has not been signalled in the server.

This panic can be raised on a client thread calling RWindowGroup::FetchMessage() or sending the EWsWinOpGetMessageSize or EWsWinOpGetMessage messages.

50

A client tried to send a second initialisation message, i.e. to call RWsSession::Connect() twice.

51

A client attempted to send a message without specifying a target window.

This can be raised, for example, in response to RWsSession::RequestOffEvents()

52

A client attempted to perform and operation on a window that has had its parent or ancestor deleted. An operation which might raise this panic could be setting the window size, position or extent.

Panic introduced in version 5.1

53

A client attempted to reset a window group’s default owning window. For example, by calling the function RWindowGroup::DefaultOwningWindow() twice on the same window group.

This is only raised in debug builds.

54

A client attempted to perform an operation on an invalid screen mode.

For example, if the client called the functions CWsScreenDevice::GetScreenModeSizeAndRotation() or CWsScreenDevice::SetScreenMode() with an illegal index.

Panic introduced in version 5.1

55

A client attempted to set an invalid screen enforcement mode.

The valid screen mode enforcement modes are defined in TScreenModeEnforcement.

Panic introduced in version 5.1

56

A client specified an event type which was not a pointer event, when this is what was required by the operation. e.g. RWindowGroup::SimulatePointerEvent().

Panic introduced in version 5.1

57

A client attempted to specify a screen rotation or orientation that is not allowed. Each screen size mode has a list of allowed rotations.

Panic introduced in version 5.1

58

A client attempted to call a function that can only be called on a top level client window on a lower level window. A top level client window is a window with a window group as a parent, e.g. RWindowBase::MoveToGroup().

Panic introduced in version 6.0