Symbian debugging technology

Symbian debugging technology

• = The simulator does not display panic details =

If a Panic occurs, the simulator does not display the details of the panic unless there is a file named "errrd" in the specified position. This makes it hard to know what caused panic.

Before SDK 3rd, the errrd file must be manually created. However, after SDK 3rd, this file can be created in the "C: /Symbian/9.2/s60_3rd_fp1/epoc32/winscw/C/resource. With errrd, the output when a Panic occurs is as follows:

''Tip: If the errrd file cannot be found even if SDK 3rd is used, start the simulator, select Tools> preferences'', and check extended panic code file.

• = Use assertions to detect bugs =

Use assertion to detect the assumption that "the code is correct", such as the object status, expected function parameters, and returned values. Symbian OS defines two asserted macros: _ assert_always and _ assert_debug. The difference between them is that _ assert_debug does not affect the product code while _ assert_always does.

Here is an example of how to use the _ assert_debug macro:

View plaincopy to clipboardprint?

1. VoidTestvalue (tint avalue)
2. {
3. _ Partition (kpaniccategory, "testvalue ");
4. _ Assert_debug (avalue> = 0), user: panic (kpaniccategory, 99 ));
5. // Do something with avalue
6. //...
7. }

void TestValue(TInt aValue){  _LIT(KPanicCategory, "TestValue");  __ASSERT_DEBUG((aValue >= 0), User::Panic(KPanicCategory, 99));  // Do something with aValue  // ...}

In the preceding example, if avalue is smaller than 0, "panic-99" is thrown ".

''Note: The asserted macro does not throw a panic by default. You can decide the process to call when the asserted fails. However, in this case, you should always throw a panic instead of returning an error or leave. ''

In the preceding example, the _ assert_debug macro is used to detect avalue only during debug compilation. If it is necessary to detect parameters in the product code, use _ assert_always.

When you do not want external callers to track panic, use an alternative of _ assert_debug: assert macro. Assert is like an assertion macro, except that it does not require you to provide a panic category or descriptor.

Here is the definition of the macro, from e32def. h file:

View plaincopy to clipboardprint?

1. # Define assert (x) _ assert_debug (x, user: invariant ())

#define ASSERT(x) __ASSERT_DEBUG(x, User::Invariant())

Here is an example of how to use the assert macro:

View plaincopy to clipboardprint?

1. VoidTestvalue (tint avalue)
2. {
3. Assert (avalue> = 0 );
4. // Do something with avalue
5. //...
6. }

void TestValue(TInt aValue){  ASSERT(aValue >= 0);  // Do something with aValue  // ...}

• = Use the _ uheap_mark and _ uheap_markend macros to detect memory leaks =

One possibility of detecting that your code correctly manages heap memory (in other words, it does not leak memory) is to use the _ uheap_mark and _ uheap_markend macros.

View plaincopy to clipboardprint?

1. Gldef_c tint e32main ()
2. {
3. // Start checking memory leaks
4. _ Uheap_mark;
6. // Create a fixed-length, flat array, which contains 10 Integers
7. Carrayfixflat <tint> * fixflatarray;
8. Fixflatarray =New(Eleave) carrayfixflat <tint> (10 );
9. // Array is not deleted, so memory will leak
11. // Stop checking memory leaks and cause a panic if there is a leak
12. _ Uheap_markend;
14. ReturnKerrnone;
15. }

GLDEF_C TInt E32Main(){  // Start checking memory leaks  __UHEAP_MARK;  // Create a fixed-length, flat array, which contains 10 integers  CArrayFixFlat<TInt>* fixFlatArray;  fixFlatArray = new(ELeave) CArrayFixFlat<TInt>(10);  // Array is not deleted, so memory will leak  // Stop checking memory leaks and cause a panic if there is a leak  __UHEAP_MARKEND;  return KErrNone;}

Since the data has not been deleted and the Memory Leak Detection macro, the previous sample code will cause a panic when the application is closed, as shown in:

It is worth mentioning that the heap detection macro is only compiled into the debug version, so it can be safely stored in the product code without affecting the code size or speed.

• = Object immutability macro =

There are two macros that allow you to check the object status: _ declare_test and _ test_invariant. In practice, they are used to enable programmers to create an immutable test function first, and then call it at the beginning and end of the function to detect the object state. This is a typical practice.

View plaincopy to clipboardprint?

1. ClassClivingperson:PublicCbase
2. {
3. Public:
4. EnumTgender {emale, efemale };
5. Public:
6. Clivingperson (tgender agender );
7. ~ Clivingperson ();
8. Public:
9. VoidSetage (ConstTint Aage );
10. Private:
11. Tgender igender;
12. Tint iageinyears;
13. _ Declare_test; // object invariance Testing
14. };
16. Clivingperson: clivingperson (tgender agender): igender (agender ){}
17. Clivingperson ::~ Clivingperson (){}
19. VoidClivingperson: setage (ConstTint Aage)
20. {
21. // Set age and check object Invariance
22. _ Test_invariant;
23. Iageinyears = Aage;
24. _ Test_invariant;
25. }
27. VoidClivingperson ::__ dbgtestinvariant ()Const
28. {
29. # Ifdef _ debug // built into debug Code only
30. // Person shoshould be either male or female
31. Assert (igender = emale) | (igender = efemale ));
33. // Person's age shouldn't be negative
34. Assert (iageinyears> = 0 );
35. # Endif
36. }

class CLivingPerson : public CBase{public:  enum TGender {EMale, EFemale};public:  CLivingPerson(TGender aGender);  ~CLivingPerson();public:  void SetAge(const TInt aAge);private:  TGender iGender;  TInt iAgeInYears;  __DECLARE_TEST;  // Object invariance testing};CLivingPerson::CLivingPerson(TGender aGender) : iGender(aGender) {}CLivingPerson::~CLivingPerson() {}void CLivingPerson::SetAge(const TInt aAge){  // Set age and check object invariance  __TEST_INVARIANT;  iAgeInYears = aAge;  __TEST_INVARIANT;}void CLivingPerson::__DbgTestInvariant() const{  #ifdef _DEBUG  // Built into debug code only  // Person should be either male or female  ASSERT((iGender == EMale) || (iGender == EFemale));    // Person's age shouldn't be negative  ASSERT(iAgeInYears >= 0);  #endif}

Because the assert macro is used in the preceding example, if the object status is incorrect, a "user 0" panic is thrown.

• = Use the expected pop-up item to check whether the stack is correctly cleared =

Clear the objects in the stack and pop up when the leave is no longer an orphan. Therefore, the pop-up usually happens just before the object is deleted. Popanddestroy is generally used to replace the pop function, because it ensures that the object is deleted as soon as it pops up, avoiding the possibility of Memory leakage. Cleanupstack: Pop and cleanupstack: popanddestroy both have an overloaded version. The caller is allowed to declare "Expected pop-up items", indicating that the item should pop up from the stack. The "E32USER-CBase 90" painc will be thrown when the expected pop-up item does not match the pop-up item. We recommend that you use these two overloaded versions because they help detect improper use of stack clearing.

View plaincopy to clipboardprint?

1. CClass * OBJ =New(Eleave) cClass;
2. Cleanupstack: pushl (OBJ );
3. //...
4. Cleanupstack: popanddestroy (OBJ); // panics if 'obj 'not on top

CClass* obj = new(ELeave) CClass;CleanupStack::PushL(obj);// ...CleanupStack::PopAndDestroy(obj);  // Panics if ‘obj’ not on top

''Note: During release compilation, it is expected that the detection of the pop-up items will be disabled, so using them will not affect the compilation of the release version in terms of binary size and efficiency. ''

• = Related link =

1. Debugging techniques
2. Debugging technology

Tip: http://wiki.forum.nokia.com/index.php/%E8%B0%83%E8%AF%95%E6%8A%80%E6%9C%AF