CCamera::Reserve(), KErrAccessDenied failure on Symbian^3

[MKechlibar]

Hi all,

it seems that the Camera API is somehow broken on Symbian^3. The standard reserve code which used to work on previous devices is dysfunctional on Symbian^3. The graveness of the problem varies with the firmware release.

We use camera to collect high-quality entropy from physical sources. That is quite important in cryptography, so I would welcome any hints.

Most of the time, a call to CCamera::Reserve will fail with code -21 (KErrAccessDenied), although the system camera application isn't running at that time. Sometimes, the entire phone just freezes dead and battery needs to be removed.

Tried on:
- C7 (by far the worst behavior when it comes to freezing, never works),
- E7 (works rarely),
- N701 (never works, but does not freeze)

The capability UserEnvironment is set.

Changing the priority of the client during CCamera::New2L from 0 to 30 did not help.

I wonder whether the problem may be caused by insufficient memory... but firmware updates have consistently worsened the behavior. In fact, the same code used to work smoothly half a year ago.

I am loath to rewrite the code to use CameraWrapper from Symbian OS examples, because the work is extensive and results uncertain.

[symbianyucca]

Can you sent me a smallest possible example that illustrates the problem, then I could see whether I could find any reason for the behaviour.

[janza]

Are you using excessive amounts of graphics memory? On these devices the graphics memory is shared with camera. Typically if there is not enough memory you could get access denied on camera.

[MKechlibar]

So ... after two days and nights of intense hacking, the situation is as follows:

1. Memory consumption is probably at the root of the problem. I have already noticed that C7-00 and E7-00 have bigger problems than N701, and really: the former models do have 32 MB of dedicated graphical memory, while N701 has 128 MB. We'll definitely try to reduce consumption of graphical memory by our application (it is a hog, as it frequently paints huge SVGs).

2. This seems to be confirmed by further experiments: accessing the front camera, used for video-chats mainly, isn't problematic. This front camera has much lower resolution than the main camera, and thus probably lower memory footprint. I can already use the front camera on all devices I have at my disposal.

3. If the Reserve() failure occurs, for example, when accessing the main camera on C7-00, it does not occur immediately. Instead, the appropriate failure event is only thrown after some 10 seconds, which is a bit strange, and uncomfortable from the user's point of view.

4. Once you experience the Reserve() failure on C7-00, you may (but by no means will - the exact logic of appearance of this problem isn't clear to me) experience further problems regarding access to the CCamera API, up to entire bricking of the phone, when it becomes unresponsive until you take the battery out. I haven't dared reproducing this on E7-00, where the battery cover isn't removable...!

Consider this simple piece of code, which just accesses all cameras on the device, asks them for their camera info, and possibly stores the info for future use:

		DestroyCameraObject();
		TInt i, cameraCount = CCamera::CamerasAvailable();
		for (i=0; i< cameraCount; i++)
			{
			TBool camCreated = AllocateCameraObjectL(i);
			if (camCreated)
				{
				TCameraInfo info;
                                                // Access the camera info.
				iCamera->CameraInfo(info);
                                                // Store the information for future use.
				iCameraInfo.Append(info);
                                                // Get rid of the camera object again.
				DestroyCameraObject();
				}
			}

where the AllocateCameraObjectL method looks like this:

TBool 	CCamera2EntropySource::AllocateCameraObjectL(TInt aIndex)
	{
	TRAPD(err, iCamera = CCamera::New2L(*this, index, KDefaultCameraPriority));
	if (err != KErrNone)
		{
		return EFalse;
		}
	return (iCamera != NULL);
	}

and the DestroyCameraObject() looks like that:

void CCameraSymbianEntropySource::DestroyCameraObject()
	{
	if (iCamera)
		{
		delete iCamera;
		iCamera = NULL;
		}
	}

Now, if something messes up in the camera API on C7-00, your application, and probably the entire phone, will sometimes hang on the line

iCamera = CCamera::New2L(*this, index, KDefaultCameraPriority);

regardless of presence of the TRAP, and you'll have to take the battery out to revive it again. This can be proven by introducing a text log file and flushing line after line, so that nothing stays in the disk cache.

I have a suspicion that something triggers an infinite loop in the system code, as this is how infinite loops usually demonstrate themselves (a plain mutex-based deadlock won't prevent other threads from execution).

The constant KDefaultCameraPriority is currently defined to 30, but I have experimented with values from 0 to 100, and they do not seem to influence the behavior at all.

[janza]

We'll definitely try to reduce consumption of graphical memory by our application (it is a hog, as it frequently paints huge SVGs).

I think this is the problem. The non-camera specific part of your application will use up all the graphics memory in the system and there is no change for the camera to run. The delay you are experiencing before you get the "access denied" error is most likely caused by the fact that system will try to clear enough room from gfx memory to start the camera. This will take time and in your case also fails most of the time.

[MKechlibar]

OK. After experiments with memory optimization, C7-00 seems OK now, as far as collection of view-finder frames goes.

Nevertheless, another problem has emerged.

Originally, the code collected N frames of the view finder, and, upon processing the N-th frame, straightly from the ViewFinder-callback method, issued StopViewFinder(), PowerOff(), Release(). This works with the API 1, but causes KERN-EXEC 3 in API 2 - not immediately, but a few seconds down the road.

[MKechlibar]

Yet another question ... what is the correct reaction to arrival of event "Camera No Longer Reserved"? Should I invoke StopViewFinder()? PowerOff()? Release()? Or some subset of them, or nothing? The documentation is a bit unclear on this.

[janza]

There is nothing you should (or can) do after receiving "camera no longer reserved" event. At that point the camera resource is controlled by some other application.