From Forum Nokia Wiki

Contents 1 is this example correct? 2 Memory Leaking Issue 3 Memory Leaking Issue 4 Memory Leaking Issue and Cell ID Issue 5 Memory Leaking Issue and Cell ID Issue

is this example correct?

I tried it and it works, but I figure this is by accident. Let me explain :

GetNetworkParameters() makes a CNetworkApp() instance, then Contructs()s it then Destroys it.

Construct() starts the scheduler which then calls RunL() when the info is ready. However, since RunL() is run asynchronously to GetNetworkParameters(), the CNetworkApp() instance could already have been Destroyed before RunL() is called. I think it's only by chance that RunL() completes before GetNetworkParemeters() has Destroyed it.

What do you think?

Response:

The key is the call to CActiveScheduler::Start(). This starts off a new wait loop in the scheduler, and Start() will not return until a matching call to CActiveScheduler::Stop().

Davidmaxwaterman 07:24, 30 May 2007 (UTC)

Hi,

I have tried this and it works but only to a point. If for example you were to do this:

case ECommand2: { TUint CellId;

       TBuf<30> NetworkId;
       TBuf<30> CountryId;
       TBuf<30> OperatorLongName;        
       
       for(test_length = 0; test_length < 1000; test_length++)
       {
CNetworkApp::GetNetworkParameters(CellId,NetworkId,CountryId,OperatorLongName);
       User::After(1000000);
       }
        
       TBuf<160> iDisplayString;
       iDisplayString.Format(
               _L( "CellId-%d\nNetworkID-%S\nCountryID-%S\nNETWORK-%S" ),
                CellId, &NetworkId, &CountryId, &OperatorLongName );

       CAknInformationNote* informationNote = new ( ELeave )
               CAknInformationNote;
       informationNote->ExecuteLD(iDisplayString);

}

The program will run out of memory after a few minutes (around 3 minutes). Now I know that a person will not be refreshing this information as quickly as the above code but it still leaves a problem where, after the user has refreshed >200 times the program will crash and will need to be restarted.

Regards, Seamus

Memory Leaking Issue

Very useful example, but have some problems on it.Appreciated if someone can give hints on it.

I encounter the sample problem as Seamus, after try to get Call CNetworkApp::GetNetworkParameters around 200 times, i got the out of memory error.

Seamus, is there any updates on this issue?

And i got another issue, sometimes i get the cell id value "0" with the above method, but the rest of informations(network provider,country code..) are all correct.Anyone have ideal on this?

I also have a question on the sample code given. In the ConstructL, the line CActiveScheduler::Add(this); will add active object itself to the current ActiveScheduler. As every call to CNetworkApp::GetNetworkParameters will create a new instance of CNetworkApp, thus a new reference will be added to ActiveScheduler, i never see the reference was removed from ActiveScheduler. I think we should call Deque() in the method RunL() to remove the current active object from Scheduler.

caowei

Memory Leaking Issue

Hi caowei,

I have been working on this but as yet, i have not managed to fix the problem. You are correct in saying that objects are being added and not removed correctly as I have tracked the memory usage on my N91 as I run the program and memory is constantly being eaten up until the memory full error message.

And I suspect you are correct that it is to do with the active scheduler but i am not fully up on the ins and outs of the Active scheduler so im still trying to find the solution.

May i suggest that both of us work together to fix the problem?

On your cell Id problem, I have a problem where I get the incorrect value a lot of the time and I have found out that There is an extra value for the hex value of the cell id and I had to code in a check to make sure it only used the 4 least significant bits to calculate the true cell id all of the time.

newCellId_1 = CellId & 0xFFFF;

Seamus

Memory Leaking Issue and Cell ID Issue

Hi Seamus

Thanks for your reply.

The Memory leaking issue has been resolved already,the issue is because we didn't clean up the pointer "CTelephony* iTelephony" in the sample code. After i added a de-constructor i didn't encounter memory full issue anymore.

---

CNetworkApp::~CNetworkApp() { if(iTelephony) { iTelephony->CancelEstablishDataCall(); iTelephony->CancelReceiveDataCall(); delete iTelephony; iTelephony = NULL; } }

---

For the cell id issue, could you explain more on the problem you encountered before? My issue only happens while i'm using 3G network, everytime i can get the correct CELL ID when i'm using GSM netwrok. You mentioned that you find the special bit for the Hex cell id value, could you suggest how to display the this original Hex format value? Is is possible to return CELL ID's original format without format using "d%"?

As most of times i still can get the correct cell id, now my interim solution is to warp the original method "CNetworkApp::GetNetworkParameters", write a loop , if i get the cell id "0", i invoke the GetNetworkParameters again until i get the correct cell id.

I suspect this is a Symbian bug, any hints on this?

BTW, i'm contable at cn.caowei@gmail.com for further discussion. I'm knowing we are doing the same thing. Write a Symbian App runing on some port,and using J2ME app query the cell id via socket.

Regards cn.caowei@gmail.com

Memory Leaking Issue and Cell ID Issue

Hi caowei,

Thanks for the fix :D im testing it as i type lol

The problem I encountered with the Cell id was that on the mobile operator network I am testing on in Ireland, they were adding data to the transmitted cell id sometimes and sometimes they were not.

For example, in one cell the values would be as follows:

23170 hex = 143728 decimal

but the real cell value should have been

3170 hex = 12656 decimal, which is the correct cell id in decimal.

When I went through the values using the on-device debugger the value was showing up as 0x00023170 as above. I contacted the mobile network operator and they were able to do traces and help me find out the problem and then i programmed around it. It appears the person i was talking to was not sure what the extra value was for but it only happened from certain base stations.

Anyway, so what I had to do was the line of code I showed above:

   //Get the 4 LSB for the Cell ID
   newCellId_1 = CellId & 0xFFFF;

What this does is just puts zeros in the 4 most significant bits of the hex value. So 0x00023170 becomes 0x00003170.

I am testing on a 3G network but then again, i have not fully checked that up and it could be a 2.5G network as im pretty sure that 3 are the only network in Ireland with a proper 3G network and im not using them but as I said, Im not fully sure what their network specs are.

As regards Symbian bugs and Cell Informations, It could be that as I would of thought that my work around that I needed to do for my cell id problem should not of been needed and it should of checked only for the 4 LSB itself without me checking for it.

I have found it other parts of the OS, it ignores zeros when it should not and hence gets the incorrect end value too.

Do you have Carbide Developer or Professional Version? You can step through all the values and see their hex value or decimal value while the app is running if you do.

If not, what you could do to see the hex value is:

TBuf<10> Hex_Value_CellId;

Hex_Value_CellId.Num(CellId, Hex);

And print it out to a log or something.

Seamus