1 |
This panic is raised by the CAsyncCallBack::Set() function, if this active object is already active when the function
is called. |
2 |
This panic is raised in debug builds only. This panic is raised by the CAsyncOneShot::Call() function, if the active object has not already been added to the
active scheduler. |
3 |
This panic is raised during construction of a dynamic buffer
(a CBufFlat or a CBufSeg ) when
the value of the granularity passed to the constructors is negative. |
4 |
This panic is raised when reading from a dynamic buffer
(a CBufFlat or a CBufSeg ) using
the Read() member function. It is caused by attempting
to read beyond the end of the buffer. |
5 |
This panic is raised when writing to a dynamic buffer (a CBufFlat or a CBufSeg ) using the Write() member function. It is caused by attempting to write
beyond the end of the buffer. |
6 |
This panic is raised when reading from a dynamic buffer
(a CBufFlat or a CBufSeg ) using
the Read() member function. It is caused by specifying
a negative length for the amount of data to be read |
7 |
This panic is raised when writing to a dynamic buffer (a CBufFlat or a CBufSeg ) using the Write() member function. It is caused by specifying a negative
length for the amount of data to be written. |
8 |
This panic is raised when inserting data into a dynamic
buffer (a CBufFlat or a CBufSeg ) using the InsertL() member function or when inserting
an uninitialized region into the dynamic buffer using the ExpandL() member function. It is caused by passing a negative
length value to these functions. |
9 |
This panic is raised when inserting data into a dynamic
buffer (a CBufFlat or a CBufSeg ) using the InsertL() member function. It is caused
when the variant of InsertL() which takes a pointer
to TAny , is passed a NULL pointer value. |
10 |
This panic is raised when specifying the minimum amount
of space which a flat dynamic buffer (a CBufFlat ) should occupy using the SetReserveL() member function.
It is caused when the size value passed to the function is negative. |
11 |
This panic is raised when specifying the minimum amount
of space which a flat dynamic buffer (a CBufFlat ) should occupy using the SetReserveL() member function.
It is caused when the size value passed to the function is less than
the current size of the buffer. |
12 |
This panic is raised by the Delete() , Ptr() , BackPtr() member functions of a
flat dynamic buffer (a CBufFlat ) ; the panic can
also be raised by InsertL() and ExpandL() . It is caused when the position value passed to these functions
is either negative or represents a position beyond the end of the
current buffer. |
13 |
This panic is raised by the Delete() member
function of a flat dynamic buffer (a CBufFlat )
. It is caused when the combination of position and length values
passed to the function implies an attempt to delete data beyond the
end of the flat buffer. |
14 |
This panic is raised by the Delete() , Ptr() , BackPtr() member functions of a
segmented dynamic buffer (a CBufSeg ) ; the panic
can also be raised by InsertL() and ExpandL() . It is caused when the position value passed to these functions
is either negative or represents a position beyond the end of the
current buffer. |
15 |
This panic is raised by the Delete() member
function of a segmented dynamic buffer (a CBufSeg ) . It is caused when the combination of position and length values
passed to the function implies an attempt to delete data beyond the
end of the segmented buffer. |
16 |
This panic is raised in debug builds only. This panic is raised by the InsertL() , Delete() , Ptr() and BackPtr() member functions as implemented for segmented buffers (CBufSeg ) , when the offset within a segment, where data
is to be inserted or removed, is greater than the buffer granularity. |
17 |
This panic is raised by the constructors of arrays of fixed
length objects as represented, for example, by the classes CArrayFixFlat , CArrayFixSeg and CArrayFixFlat<TAny> . It is caused when the record length
is either negative or zero. The record length is either explicitly
specified as in the case of the CArrayFixFlat<TAny> class or is implied by the length of the template class as in the
case of the CArrayFixFlat class. |
18 |
This panic is raised by the constructors of arrays of fixed
length objects as represented, for example, by the classes: CArrayFixFlat and CArrayFixSeg . It is
caused when the granularity passed to the constructors is either negative
or zero. |
19 |
This panic is raised by the constructors of arrays of variable
length objects as represented, for example, by the classes: CArrayVarFlat and CArrayVarSeg . It is
caused when the granularity passed to the constructors is either negative
or zero. |
20 |
This panic is raised by the constructors of packed arrays
as represented, for example, by the class CArrayPakFlat . It is caused when the granularity passed to the constructors is
either negative or zero. |
21 |
This panic is raised by any operation which accesses an
element of an array by explicit reference to an index number, for
example, the Delete() , InsertL() and At() member functions or the operator Operator[] . It is caused by specifying an index value which
is either negative or is greater than or equal to the number of objects
currently within the array. |
22 |
This panic is raised when deleting contiguous elements from
an array of fixed length objects (derived from CArrayFixBase ) using the Delete() member function. It is caused
by specifying the number of contiguous elements as a zero or negative
value. |
23 |
This panic is raised when inserting contiguous elements
into an array of fixed length objects (derived from CArrayFixBase ) using the InsertL() member function. It is caused
by specifying the number of contiguous elements as a zero or negative
value. |
24 |
This panic is raised when resizing an array of fixed length
objects (derived from CArrayFixBase ) using the ResizeL() member function. It is caused by specifying the
number of contiguous elements as a zero or negative value. |
25 |
This panic is raised when deleting contiguous elements from
an array of variable length objects (derived from CArrayVarBase ) using the Delete() member function. It is caused
by specifying the number of contiguous elements as a zero or negative
value. |
26 |
This panic is raised when deleting contiguous elements from
a packed array (derived from CArrayPakBase ) using
the Delete() member function. It is caused by specifying
the number of contiguous elements as a zero or negative value. |
27 |
This panic is raised when reserving space in flat arrays
of fixed length objects, (the CArrayFixFlat ,CArrayFixFlat<TAny> and CArrayPtrFlat classes ) using the SetReserveL() member function.
It is caused by specifying the number of elements, for which space
is to be reserved, as less than the current number of elements in
the array. |
28 |
This panic is raised when inserting or appending replicated
elements to the arrays of fixed length objects CArrayFixFlat and CArrayFixSeg using the InsertL() or AppendL() functions. It is caused by specifying
the number of replicas as negative or zero. |
29 |
This panic is raised when deleting elements from a fixed
length, variable length or packed array (derived from CArrayFixBase , CArrayVarBase and CArrayPakBase ) using the Delete() function. It is caused when
the specification of the position of the first element to be deleted
and the number of contiguous elements to be deleted refers to elements
which are outside the bounds of the array. |
30 |
This panic is raised when inserting into, appending onto,
expanding or extending a variable length array or a packed array (i.e.
arrays derived from CArrayVar or CArrayPak ) using the InsertL() , AppendL() , ExpandL() or ExtendL() functions
respectively. It is caused by specifying the length of the element
as a negative value. |
33 |
This panic is raised by the destructor of a CObject . It is caused, if an attempt is made to delete the CObject when the reference count is not zero. |
34 |
This panic is raised by the Close() member
function of a CObject . It is caused, if the reference
count is negative. |
35 |
This panic is raised by the Remove() member
function of an object container, a CObjectCon .
It is caused when the CObject to be removed from
the container is not contained by the container. |
36 |
This panic is raised by the Remove() member
function of a container index, a CObjectConIx .
It is caused when the object container, a CObjectCon , to be removed from the index is not contained by the index. |
37 |
This panic is raised by the Remove() member
function of an object index, a CObjectIx . It is
caused when the handle passed to the Remove() function
does not represent a CObject known to the object
index. |
38 |
This panic is raised by the At() , FindByName() and FindByFullName() member
functions of an object container, a CObjectCon .
It is caused when the unique ID as derived from the handle is not
the same as the unique ID held by the object container. |
39 |
This panic is raised by the At() member
function of an object container, a CObjectCon .
It is caused when the index represented by the handle is outside the
permitted range. In effect, the handle is bad. |
40 |
This panic is raised by the destructor of an active object,
a CActive . It is caused by an attempt to delete
the active object while it still has a request outstanding. |
41 |
This panic is raised by the Add() member
function of an active scheduler, a CActiveScheduler . It is caused by an attempt to add an active object to the active
scheduler when it has already been added to the active scheduler |
42 |
This panic is raised by the SetActive() member function of an active object, a CActive . It is caused by an attempt to flag the active object as active
when it is already active, i.e. a request is still outstanding. |
43 |
This panic is raised by the Install() member
function of an active scheduler, a CActiveScheduler . It is caused by attempting to install this active scheduler as
the current active scheduler when there is already a current active
scheduler; i.e. an active scheduler has already been installed. |
44 |
This panic is raised by the Start() , Stop() and Add() member functions of an
active scheduler, a CActiveScheduler . It is raised
when the thread has no attached active scheduler |
45 |
This panic is raised by the Stop() member
function of an active scheduler, a CActiveScheduler . Calling Stop() terminates the wait loop started
by the most recent call to Start() . The panic is
caused by a call to Stop() which is not matched by
a corresponding call to Start() . |
46 |
This panic is raised by an active scheduler, a CActiveScheduler . It is caused by a stray signal. |
47 |
This panic is raised by the Error() virtual
member function of an active scheduler, a CActiveScheduler . This function is called when an active object’s RunL() function leaves. Applications always replace the Error() function in a class derived from CActiveScheduler ; the default behaviour provided by CActiveScheduler raises this panic. |
48 |
This panic is raised by the Add() member
function of an active scheduler, a CActiveScheduler , when a NULL pointer is passed to the function. |
49 |
This panic is raised by the SetActive() and Deque() member functions of an active object,
a CActive . It is raised if the active object has
not been added to the active scheduler. |
50 |
This panic is raised by the SetPriority() member function of an active object, a CActive . It is caused by an attempt to change the priority of the active
object while it is active, i.e. while a request is outstanding). |
51 |
This panic is raised by the At() , After() and Lock() member functions of
the CTimer active object. It is caused by an attempt
to request a timer event when the CTimer active object
has not been added to the active scheduler. |
52 |
This panic is raised by the Start() member
function of the periodic timer active object, a CPeriodic , when a negative time interval is passed to the function. |
53 |
This panic is raised by the Start() member
function of the periodic timer active object, a CPeriodic , when a negative delay time interval is passed to the function. |
54 |
This panic is raised by the RunL() member
function of the CServer active object base class
responsible for handling asynchronous requests from a client thread
when the client passes a negative function code in RMessage. The only negative values permitted are RMessage::EConnect and RMessage::EDisConnect. |
55 |
This panic is raised by the Start() member
function of the CServer active object base class
responsible for handling asynchronous requests from a client thread.
It is caused by the server having no name. |
56 |
This panic is raised by the New() and NewL() member functions of CBitMapAllocator when a negative or zero size is passed to them. |
57 |
This panic is raised by the Free(TInt aPos) member function of CBitMapAllocator when a position
value is passed which is out of bounds. |
58 |
This panic is raised by the IsFree(TInt aPos) member function of CBitMapAllocator when a position
value is passed which is out of bounds. |
59 |
This panic is raised by the AllocFromTopFrom(TInt
aPos) member function of CBitMapAllocator when a position value is passed which is out of bounds. |
62 |
This panic is raised by the AllocAt() member
function of CBitMapAllocator when the implied position
has already been allocated. |
63 |
This panic is raised as a result of a call to the Pop() and PopAndDestroy() static member
functions of the CleanupStack class. The panic
occurs when TRAPs have been nested and an attempt is made to pop too
many items from the cleanup stack for the current nest level. |
64 |
This panic is raised as a result of a call to the Pop() and PopAndDestroy() static member
functions of the CleanupStack class. The panic
occurs when attempt is made to pop more items from the cleanup stack
than are on the cleanup stack. |
65 |
The panic is raised as a result of a call to the Pop() and PopAndDestroy() static member
functions of the CleanupStack class. The panic occurs
when an attempt is made to pop more items from the cleanup stack than
are on the cleanup stack. |
66 |
This panic is raised if an attempt is being made to insert
a cleanup item into a position on the cleanup stack reserved for marking
the current TRAP nest level. In practice this error
occurs if the call to CleanupStack::PushL() happens
when there has been no call to TRAP() . |
67 |
This panic is raised when building a TCleanupStackItem which is to be added to the cleanup stack. The building of the TCleanupStackItem needs a TCleanupItem and this has been constructed with a NULL cleanup operation (a TCleanupOperation). |
68 |
This panic is raised if there are no free slots available
on the cleanup stack to insert a cleanup item |
69 |
This panic is raised if no trap handler has been installed.
In practice, this occurs if CTrapCleanup ::New() has not been called before using the cleanup stack. |
70 |
This panic is raised as a result of a call to the versions
of the Pop() and PopAndDestroy() static member functions of the CleanupStack class
which take an explicit count of the items to be popped. The panic
is caused by passing a negative value for the number of items to be
popped. |
71 |
This panic is raised when TRAP s have
been nested and an attempt is made to exit from a TRAP nest level before all the cleanup items belonging to that level
have been popped off the cleanup stack. There must be the
same number of items on the cleanup stack on entering a TRAP harness as there is on exiting. In other words, anything that is
pushed onto the cleanup stack inside a TRAP harness
must be popped off before leaving the harness. For example,
the following code avoids this panic when FooLC() does not leave, by explicitly popping pointer before
the end of the harness: TRAPD(error, pointer = FooLC(); CleanupStack::Pop(pointer)); See also How to use TRAP. |
72 |
This panic is raised by the constructor of the circular
buffer base class, a CCirBufBase , when the size
value passed is zero or negative. |
73 |
This panic is raised by a call to the SetLengthL() member function of of the circular buffer base class, a CCirBufBase , by passing a length value which is zero or
negative. |
74 |
This panic is raised by a call to the Add() member function of a circular buffer, a CCirBuf when the pointer to the item to be added is NULL. |
75 |
This panic is raised by a call to the Add() member function of a circular buffer, a CCirBuf when the number of items to be added is zero or negative |
76 |
This panic is raised by a call to the Remove() member function of a circular buffer, a CCirBuf when the number of items to be removed is zero or negative. |
89 |
Introduced in 6.0: This panic is raised by call to the Replace() member function of CActiveScheduler when the replacement active scheduler is the same as the existing
active scheduler. |
90 |
Introduced in 6.0: The panic is raised as a result of a
call to the Pop() and PopAndDestroy() static member functions of the CleanupStack class.
The panic occurs when an the item to be popped is not the expected
item. |
91 |
This panic is raised by CActiveSchedulerWait::Start() when the CActiveSchedulerWait object has already
been started. |
92 |
This panic is raised by CActiveSchedulerWait::AsyncStop() and CActiveSchedulerWait::CanStopNow() when the CActiveSchedulerWait object has not been started. |
93 |
This panic is raised during construction of a CAsyncOneShot if the attempt to open a handle to the current thread fails. |
94 |
Not used. |
95 |
This panic is raised on calls to the default implementations
of functions: CPolicyServer::CustomSecurityCheckL() and CPolicyServer::CustomFailureActionL() . The class CPolicyServer is intended to be
derived from, and these functions in particular need to be re-implemented
in a derived class. This panic is a symptom of a failure to provide
a derived class. |
96 |
This panic is raised in debug builds only. It is raised by the protected CPolicyServer constructor, if the first element pointed to by the iRanges member of the TPolicy aPolicy parameter does not have a value of 0; i.e. if aPolicy 's TPolicy::iRanges [0] is not
0. |
97 |
This panic is raised in debug builds only. It is raised by the protected CPolicyServer constructor, if the value of each element of the iRanges member of the TPolicy aPolicy parameter is not greater than the value of the previous element. See also TPolicy::iRanges. |
98 |
This panic is raised in debug builds only. It is raised by the protected CPolicyServer constructor, if the value of every element in the iElementsIndex member of the TPolicy aPolicy parameter is not valid. Elements of iElementsIndex are invalid if their values are either: or See also TPolicy::iElementsIndex and CPolicyServer::TSpecialCase . |
99 |
This panic is raised in debug builds only. It is raised by the protected CPolicyServer constructor, if the value of the iOnConnect member
of the TPolicy aPolicy parameter
is not valid. The iOnConnect member is invalid
if its value is either: or See also TPolicy::iOnConnect and CPolicyServer::TSpecialCase . |
100 |
This panic is raised if CPolicyServer::iPolicy is found to be invalid for some unknown reason. If you run
the server in debug mode, it is likely that the server will panic
with one of the panic codes in the range 96 to 99 inclusive. These
are described above. See CPolicyServer for
information about what constitutes a valid policy. |
101 |
This panic is raised when the value returned by the CPolicyServer::CustomSecurityCheckL() and CPolicyServer::CustomFailureActionL() functions is invalid. The CPolicyServer::TCustomResult enum defines the valid set of return values. |
102 |
This panic is raised in debug builds only. It is raised by the protected CPolicyServer constructor, if the value of the iRangeCount member
of the TPolicy aPolicy parameter
is not greater than 0. A value of 0 implies that no policies have
been passed to the policy server. It is a requirement that at least
one policy be passed to the policy server. |
103 |
This panic is raised by the policy server framework if a
message fails a policy check, whether custom or not. |
104 |
This panic is raised in debug builds only. It is raised by a number of CObjectIx member
functions if the object's data becomes inconsistent. |
105 |
This panic is raised when a local or global semaphore is
created using the RSemaphore member functions: CreateLocal() and CreateGlobal(), and
the value for the initial semaphore count is negative. |
106 |
This panic is raised when a semaphore is signaled using
the Signal(TInt aCount) member function and the
count value is negative. |