NewLC - Common mis-use and abuse of Symbian OS - Comments

Re: Common mis-use and abuse of Symbian OS

sameer.chaudhari — Tue, 08 Jul 2008 08:50:37 +0200

Why I need to call Cancel() from Destructor of my own ActiveObject.

According to sdk documentation.
CActive::~CActive :
"Specifically, it removes this active object from the active scheduler's list of active objects."

CActive::Deque()
"Removes the active object from the active scheduler's list of active objects.
Before being removed from the active scheduler's list, the function cancels any outstanding request."

Now , According to this statement
What I assume ,
If I dnt call CActive::Cancel() from my Active object Destructor . It will call internally at the time of removing this active object.

Re: Common mis-use and abuse of Symbian OS

Numpty Alert — Fri, 04 Apr 2008 00:45:55 +0200

As mentioned RunL() returns void so how could it return a value? And if it wasn't void where do you want the value returned to? - RunL() is never called directly, it is always called by the active scheduler so you would be returning a value to the active scheduler. So if your question is asking if you can get a value from RunL() to somewhere, where is that somewhere?

Re: Common mis-use and abuse of Symbian OS

Andreas — Thu, 03 Apr 2008 01:28:49 +0200

Since the thread's mostly into Active objects.. i'd like to ask if returning some value from the runL () method is possible?

No, RunL returns void so you cannot return any value. Brush up your programming skills and read the documentation, please.

Re: Common mis-use and abuse of Symbian OS

rocker — Wed, 02 Apr 2008 15:06:42 +0200

Since the thread's mostly into Active objects.. i'd like to ask if returning some value from the runL () method is possible??

Re: Common mis-use and abuse of Symbian OS

Eric.Pen — Thu, 27 Mar 2008 10:08:52 +0100

cheerful for this nice summary ! And we should always refer to SDK carfully !

Re: Common mis-use and abuse of Symbian OS

Numpty Alert — Thu, 20 Mar 2008 17:21:44 +0100

Number 15
---------------

"I'm getting an undefined symbol error when I compile even though I have included the header file"

i.e. Undefined symbol: 'int CFeatureDiscovery::IsFeatureSupportedL(int) (?IsFeatureSupportedL@CFeatureDiscovery@@SAHH@Z)'"

Including the header file isn't enough, you need to include the appripriate .lib within your .mmp file.

Re: Common mis-use and abuse of Symbian OS

zhangzhq — Tue, 04 Dec 2007 06:43:25 +0100

Nice Summary

Re: Common mis-use and abuse of Symbian OS

Numpty Alert — Mon, 03 Dec 2007 21:24:48 +0100

Number 14 - Unnecessarily Cancelling within active objects
-----------------------------------------------------------------------------------

A lot of people write code within an active such as this:

void CMyActiveObject::StartProcessingL( )
{
// Cancel any outstanding request just in case
if ( IsActive() )
{
Cancel();
}

DoSomeStuff ....

}

CActive::Cancel() itself checks if the object is active or not, so wrapping Cancel() in an if statement in general is pointless.

"Cancel any outstanding request just in case" just in case what? If you're cancelling 'just in case' then you are admitting that the logic of your active oject is crap or it is being misused by a caller and you might get into a situation where an asynchronous request is going to be made when there is already an outstanding one. Don't put code in "just in case", design your object properly so this can't happen. If a client of your active object is calling StartProcessingL() twice then its probably a bug, so consider putting at least an ASSERT_DEBUG checking to see if the object is already active.

Re: Common mis-use and abuse of Symbian OS

william_j — Wed, 31 Oct 2007 14:02:04 +0100

Very common error while installing sis signed with devcert is wrong time defined on device. Devcerts has limited time and this leads to errors if time on devices exceeds this interval.

Re: Common mis-use and abuse of Symbian OS

Numpty Alert — Wed, 10 Oct 2007 01:37:10 +0200

Number 13
----------------

Why are you using threads? You don't use threads in Symbian unless you need to, instead you use active objects.

When you need to use threads in Symbian is when you *need* pre-emptive multitasking, if you don't know what pre-emptive multitasking is then you probably don't need a thread.

Re: Common mis-use and abuse of Symbian OS

NumptyAlert — Fri, 25 Aug 2006 01:59:52 +0200

Number 12 - descriptors as function arguments
------------------------------------------------------------

1) If a function takes a descriptor as an input paramter you should declare it as const TDesC&

Whatever you do don't forget the &, if you do it will compile but you won't pass any data to the function.

Also don't forget the const either.

2) If the function takes an in-out parameter pass it as TDes&.

Again, whatever you do, don't forget the &.
This time, don't add the const by mistake.

Summary:
Do do const TDesC&
Do do TDes&
Don't do const TDesC
Don't do const TDes
Don't do TDesC&
Don't do const TDes&
Don't do TDes

Re: Common mis-use and abuse of Symbian OS

NumptyAlert — Fri, 25 Aug 2006 01:40:19 +0200

Number 11 - reasons why your SIS file may not install
--------------------------------------------------------------------

(These apply specifially to Symbian OS9.x/nokia 3.x. Some will apply to earlier versions, but many won't).

1) Your SIS might not be signed when it has to be. It might not be signed with the correct capabilites. It may not be signed with the correct certificate (Lots of rules here, see above for some of them).

2) Your certificate may have expired. Your device's date may not be correctly set so the device thinks the certificate has expired.

3) Your certificate may have been revoked.

4) You might be installing onto a test device and it doesn't have any root certificates installed.

5) If your SIS is signed with a developer certificate:
- are you installing to a device specified by the dev cert - they are for particular devices only?
- have you signed it with more than one dev cert?

6) Does your certificate contain the capabilites that the programs you are trying to install uses?

7) The format of SIS files has changed with Symbian OS9.x / Nokia 3.x. You might have built it using an old SDK and thus its format is out of date.

8 ) Your sis file contains exes and dlls built for the emulator and not for the device.

9) Your .pkg may contain typos in the names of installtion paths etc.

10) Your program uses Dlls etc. which aren't also in the SIS or on the device

11) There might not be enough memory or disk space to install the stuff.

12) The stuff in the SIS may already be installed on the device (there are rules about what can or can't be replaced)

13) You might be attempting to install to a forbidden directory.
- You shouldn't attempt to write to /sys/
- You should write your executables to /sys/bin/
- You shouldn't write to a private folder that isn't yours,Â unless its to its import directory provided that it previously exists
- You should put things like .ini files, .mbs, data files in yourÂ private folder
- You should put things like resources & bitmaps in /resource/

A private folder is /private/0x1234565789/, where 0x123456789 is the SID or 3rd UID of the program.
An import folder is /private/0x1234565789/import

14) Does your SIS have an SID (or 3rd uid) in the protected range (or a VID in the protected range. If you don't know what a VID is then you don't need to know). If it does it needs to be signed with an appropriate certificate.
For SIDs the protected range is 0-0x7fffffff and the unprotected range is 0x80000000-0xffffffff . For VIDs, the protected range is 0x00000001-0xffffffff and the unprotected range is 0x00000000.

15) Does your SIS file contain an exe with an SID (or 3rd UID) which is already being used on the device.

Re: Common mis-use and abuse of Symbian OS

NumptyAlert — Thu, 24 Aug 2006 23:44:38 +0200

Number 10 - stuff about signing and capabilites
--------------------------------------------------------------

There's loads that could be written about this, here's a little to begin with, it could do with tidying, editing, adding much more but it'll do for a start:

Quotes taken a thread discussion on capabilites and its replies.

Quote

This method requires 'Network Services" capability which I have got with the developer certificate.

Quote

im giving the capabilities which you can get it free through developer certificate:

You don't get capabilites from a certificate. From a certificate you get the ability to sign and thus install software which uses a certain set of capabilites. It doesn't matter what the capabilites are in a certificate if the correct capabilites aren't in your code in the first place.

The capabilities are specified in the .mmp file. If you run your code on the emulator and look in the epocwind.out file you will be able to see if you have got the correct capabilites specified in your .mmp file or not as you will get an error message saying what capability is missing for a particular dll to be loaded or for a particular function to be called.

The certificate comes into play when installing the SIS onto the device. If you have some powerful capabilites in your .mmp file then you will need a certificate endorsing those powerful capabilites before you are able to install the software. And don't confuse a developer certificate with a real certificate. A developer certificate is an aid when you are developing your software, to release your software to the world you need a real certificate. Developer Certificates are issued for a particular device or small number of specified devices, if an attempt is made to install to any other device installation will fail.

Quote

Have you modified .mmp file ? Try to add following line in .mmp:
CAPABILITY ALL -tcb

You shouldn't just add capabilites in the blind hope that you will be able to access APIs.

If you have All -TCB then go along to the certificate provider and say excuse me can I have a certificate that will allow me to install my app on the device with All - TCB capabilities please? they're not too likely to say "Yes of course you can have AllFiles which will allow your program to erase the entire contents of the device, no problemo. Yes you can have PowerMgmt so you can kill all the running processes or shut down and start up the phone at random to irritate the user. We don't mind giving you a certificate with these capabilites at all as you can't do much damage to the phone having All-TCB".Â

The more powerful the set of capabilites you request, then in theory, the more stringent the controls and checking there should be before you will be granted them in a certificate (real certificate, not developer certificate). And you might not be granted some powerful ones at all. Certianly nobody would be granted TCB.Â

Capabilites are divided into two sets - user and system.Â If your code only uses user certificates then you may be allowed to install it onto the device without any certificate depending upon how the phone manufacturer/phone operator has configured the device. However I think Nokia has configured all their devices to require signing even if you are only using user capabilites, though getting a certificate with just user certificates ought to be easier than if it contains system capabilites.

The standard set of user capabilities is:

UserServices
NetworkService
UserEnvironment
ReadUserData
WriteUserData
Location

(However a device manufacturer can customise this list if they wish to though this is unlikly).

If you are installing software which uses any system capabilites then it MUST be signed with a certificate which endorses those capabilites (i.e. allows the software signed with that certificate to be installable).

P.S.
Top tip when changing the capabilities in a .mmp file. Delete everything you can find associated with your project, dlls, exes, directories in epoc32's build folder. Delete everything.
There seems to be a problem with residual information lying around which isn't tidied up by regenerating your project files from the updated .mmp or by doing abld clean or reallyclean or bldmake clean. So you may find you add a new capability to a .mmp, regenerate the project file, re-build everything but the code still behaves as if it hasn't got the new capability. If this happens to you make sure you have a totally clean environment and try again.

reply : regarding stack/heap

himsymbian — Thu, 10 Aug 2006 11:30:02 +0200

Hi. Thanks for the post/thread. Actually i was also wondering about the stack / heap allocation regarding desc
types. Actually it follows the C++ convention only local var's on stack & class members on heap.

Re: Common mis-use and abuse of Symbian OS

NumptyAlert — Sat, 05 Aug 2006 00:39:22 +0200

Number 9 - Misunderstanding about the stack and the heap in relation to descriptors

A lot of people seem to get confused between the stack and the heap when it comes to descriptors. A main reason for the confusion is actually from documentation (including from Symbian themselves) that isn't clear or is misleading.

For example documentation that says TBuf descriptors go on the stack is incorrect.
Also documentation that says the data pointed to by a HBufC* goes on the heap but the HBufC pointer goes on the stack is also incorrect.

The above two statements are correct IF the TBuf and HBufC pointer are local variables i.e.

void Function()
{
TBuf<20> buf;
TPtr ptr;
HBufC* hBuf = HBufC::NewL(...)
}

buf, ptr and hBuf are all on the stack, while the data pointed to by hBuf is on the heap, however in this code:

class CClass : public CBase
{
...
TBuf<20> ibuf;
TPtr iptr;
HBufC* ihBuf;
}

CClass *class = CClass::NewLC();

Then ibuf, iptr, ihBuf and the data pointed to by hBuf are all on the heap.

Avoid putting large descriptors on the stack:

void Function()
{
TBuf<1000000> buf;
}

This will go on the stack and is too large so will cause stack overflow or the infamous __chkstk compiler warning.

So instead if you do this:

void Function()
{
TBuf<1000000>* buf = new(ELeave) TBuf<10000000>;
}

Now it will go on the heap but you should probably use RBuf or HBuf instead, (or for data this large look at CBufFlat or preferably CBugSeg).

In this example, the data is also on the heap:

class CClass : public CBase
{
...
TBuf<10000000) iBuf;
}

CClass* class = CClass::NewLC();

Common mis-use and abuse of Symbian OS

NumptyAlert — Tue, 28 Mar 2006 18:56:24 +0200