Carbide.vs emulator hangs when debugging

[jyrkiettila]

Hi,

I am using S60 3rd MR, Microsoft Visual Studio .NET 2003 and Carbide.vs 2.0.1.

Most of the times the EPOC emulator (winscw udeb) hangs, when I am trying to start to debug my application on the emulator. The crash happens while the emulator loads the system libraries before I am able to start my application on the emulator.

Sometimes the emulator starts OK in the debug mode and I am able to do the actual debugging.

If the crash happens, then I have found to be wise to completely exit from Visual Studio and start it again. (Visual Studio does not hang, so I click "stop debugging", which shuts down the emulator, and then I exit from the Visual Studio and try again.)

Has anybody experienced the same? Any suggestions, how to get the emulator more reliable during startup?

(I have a Windows XP Pro SP2 with English US regional settings. The setup should be compatible with the SDK specs, but the computer is old and it has lots of stuff installed. However, I had more troubles with a clean brand new computer and CodeWarrior development environment.)

The following are some extracts of the last lines of epocwind.out, when the emulator hangup has occurred. The place, where the crash happens, seems to be random. I don't see any similarity in the different epocwind.out listings.

    30.160	CDosServer::CurrentFreeDiskSpaceRequest()
    30.160	CDosServer::SetCurrentFreeDiskSpaceRequest()
    30.225	FontProvider: Category=1, TextPane Height=14; mapped request=12; typeface=Series 60 Sans SemiBold, actual range=14(a,d,exa,exd=10 2 1 1)

    33.515	Starter:Start Exe: z:\sys\bin\systemams.exe -boot
    33.515	Starter:Executable path: z:\sys\bin\systemams.exe
    33.515	Starter:Arguments: -boot
    33.565	Starter:StartExeL: RProcess::Create returns: -1

    41.670	Thread FLOGSVR.EXE::Main created @ 0xa11808 - Win32 Thread ID 0x1414
    41.675	SIPProfile: Process created
    41.690	SIPProfile: SecureBackup, subscribing backup event
    41.690	SIPProfile: SecureBackup, subscribing backup event, complete
    42.020	Thread SipServer.EXE::Main created @ 0xa13d8c - Win32 Thread ID 0xe9c
    42.025	Starter:RunL
    42.025	Starter:RunL.EStartApplications
    42.025	Starter:LaunchNextItem:exeType=20,delay=2000000
    42.025	Starter:LaunchItem:monitor=0

  151.780	CDirWatcher::RunL ->
   151.780	c:\private\101f51f2\rdb\f
   151.780	-3
   151.780	CDirWatcher::RunL <-
   151.805	RDRMRightsClient::StartServer(): 0
   151.805	RDRMRightsClient::Connect(): Create a new session
   151.830	CDRMRightsServer::NewSessionL
   151.830	CDRMRightsServer::NewSessionL: Creating a new session
   151.830	RDRMRightsClient::Connect(): Result: 0
   151.835	CProcWatcher::CProcWatcher ->
   151.835	CProcWatcher::CProcWatcher <-
   151.835	CProcWatcher::ConstructL <-
   151.835	CProcWatcher::ConstructL ->
   151.835	CProcWatcher::StartWatching ->
   151.835	*RightsServer*
   151.835	rightsserver.exe[101f51f2]0001
   151.835	Active 
   151.835	CProcWatcher::StartWatching <-
   152.880	content size: 12.0000x12.0000
   152.890	content size: 12.0000x12.0000
   152.895	content size: 12.0000x12.0000
   152.950	FontProvider: Category=3, TextPane Height=24; mapped request=20; typeface=Series 60 Sans TitleSmBd, actual range=21(a,d,exa,exd=15 5 3 -2)
   152.960	AKNSKINS: (Error) "CAknsAppSkinInstance::GetLayoutBitmap Srv update failed -1"
   154.795	Constructing HCTL Bcsp

Any suggestions or comments greatly appreciated.

- Jyrki

[jyrkiettila]

Replying to myself:

I copied the file C:\Symbian\9.1\S60_3rd_MR\Epoc32\data\epoc.ini into configuration.ini

and now I have managed to start the emulator debugger five times consequtively without problems!

(The file configuration.ini was missing from my directory and I am pretty sure I hadn't deleted it. Strange that one missing file caused so unpredictable behaviour: sometimes the debugger worked, usually not.)

Now I am happy again.

- Jyrki

[jyrkiettila]

Correction to my previous post:

Now I am not sure at all, whether the configuration.ini file has anything to do with the case. The EPOC emulator under the VS.NET debugger has still hanged twice after my experimental copying epoc.ini into configuration.ini.

I got the idea for trying to copy the file, because sometimes during the emulator crash the last message in the VS.NET output window had been "reading configuration.ini" (or something similar) and that file was missing from my hard disk. But I have managed to debug the emulator with and without that file and also sometimes the emulator crashes in both cases, so that was not a working fix.

Well, if the emulator works about every other time, it can be used. This is a good day, because today it has worked about 50% of starts :)

- Jyrki

[mitts]

If you have a problem, what happens when you just run the app without any debug, ie. do you see issues if you just start the emulator from the Windows program menu?

[jyrkiettila]

I had an opportunity to test the scenario you described twice today. Both times the emulator worked without problems from the Windows program menu.

Details below.

First test:
Emulator failed three times under the debugger.
Then it started OK from Windows program menu.

2nd test:
Emulator failed first under the debugger but then started OK.

3rd test:
Emulator failed once under the debugger.
Then it started OK from Windows program menu.

Emulator has also worked today under the debugger. The problem happens only now and then, usually at the busiest moment, as the Murphy's law says.

I'll continue testing this during the following days.

[jyrkiettila]

I have now collected some statistics and it seems that the emulator hanging problem is related to my MS VS.NET 2003 debugger.

I have started emulator alone directly from the Windows program menu ten times since Friday and every time it has worked without problems.

In addition, I have started the emulator 12 times under the VS debugger. From these launches, 6 failed and 6 succeeded.

So from now on (unless I find a fix), I am going to use the debugger only when necessary and otherwise I test my application directly under the emulator without the VS debugger. Starting the emulator directly is somewhat faster too.

- Jyrki

[mitts]

Thanks for the info. A couple of questions:

- How have you created the project - template or import?
- Does "Start without Debugging" in VS produce the same problem?
- Is it possible that you have some libraries or other stuff in your app that have been compiled under CodeWarrior?
- In the offending project, what is the value of the WINSCW config Properties -> Debugging -> Command?

[jyrkiettila]

- How have you created the project - template or import?

import

- Does "Start without Debugging" in VS produce the same problem?

Works better. (Tried 12 times, 2 failed starts.)
Last lines of the epocwind.out of the 2nd failure below:

    17.255	Thread siprsvsrv.EXE::Main created @ 0xa18194 - Win32 Thread ID 0x169c
    17.275	Thread EcmtCore.exe::W32SelectThread created @ 0xa18504 - Win32 Thread ID 0x12e0
    17.285	RAknUiServer::ConnectAknServer(), handle 0, Securitynotifierappserver
    17.285	RAknUiServer::ConnectAknServer() end
    17.285	RAknUiServer::ConnectAknServer(), handle 0, btnotifappserver
    17.285	RAknUiServer::ConnectAknServer() end
    17.285	RAknUiServer::ConnectAknServer(), handle 0, CTSecDlgAppServer
    17.285	RAknUiServer::ConnectAknServer() end
    17.285	RAknUiServer::ConnectAknServer(), handle 0, SyncMLNotifierAppServer
    17.285	RAknUiServer::ConnectAknServer() end
    17.290	Thread Watcher.exe::WatcherMainThread created @ 0xa191e8 - Win32 Thread ID 0x168
    17.305	RAknUiServer::ConnectAknServer(), handle 0, SysAp
    17.305	RAknUiServer::ConnectAknServer() end
    17.305	RAknUiServer::ConnectAknServer(), handle 0, Menu
    17.305	RAknUiServer::ConnectAknServer() end
    17.310	AKNSKINS: (Error) "CAknsAppSkinInstance::GetLayoutBitmap Srv update failed -1"
    17.325	viewbox is defined: 352.0000x288.0000
    17.455	viewbox is defined: 352.0000x288.0000
    17.470	AKNSKINS: (Error) "CAknsAppSkinInstance::GetLayoutBitmap Srv update failed -1"
    17.490	RAknUiServer::ConnectAknServer(), handle 0, cconndlgappserver
    17.490	RAknUiServer::ConnectAknServer() end
    17.620	Thread msexe.exe::Main created @ 0xa1b1d0 - Win32 Thread ID 0xfc4
    17.620	SIP Client Resolver: Plug-in with 'default_data': 101F9515
    17.620	SIP Client Resolver: Plug-in status: 0
    17.620	SIP Client Resolver: ROM-based plug-ins count: 1
    17.630	SIP Client Resolver: All plug-ins count: 1

- Is it possible that you have some libraries or other stuff in your app that have been compiled under CodeWarrior?

No, unless the SDK or Carbide.vs contains such libraries.

- In the offending project, what is the value of the WINSCW config Properties -> Debugging -> Command?

C:\Symbian\9.1\S60_3rd_MR\\Epoc32\release\winscw\udeb\epoc.exe

[mitts]

Somehow it seems that the more resources you "have in use" when you start the emulator, the higher the likelihood that there is a problem..

Could it be that your PC is resource-constrained in some area? Now I am no expert on PC tuning, but somehow the totally random nature of where the buck stops would suggest that it could be due to your PC running out of some critical resource which would then happen at some random point in time dependign of what other apps and stuff is running?

Otherwise it seems that you are pretty well set up in all aspects?

[Starchaser]

The S60V3 emulator is too slow. It takes ages to boot up and I also have the same problem: for me 1 in 3 attempts to start debugging end in a hang. If at all possible I use the S60V2 (or even S60V1) emulators to do development work because of this.

I think something must be timing out during startup as the impression I get is that there are fewer hangs when I use my notebook on mains power. On battery power everything is even slower and the hangs can be really, really annoying.


There are two other issues I have with the S60V3 emulator:

1. What's with all the "Microsoft Exception" debug messages? Is there a way to turn these off? It's ridiculous and pointless that the emulator is printing this out hundreds of times while it is booting.

2. If I get a Kern-Exec 3 in my code the debugger catches it but there is no call stack! How am I supposed to debug a Kern-Exec 3 on S60V3!? Of course in some cases I can simply go back and use the S60 V2 emulator to debug the problem, but that's hardly ideal.


Is the solution to all of this to use Carbide.c++ instead? I'd heard that you don't need to re-start the emulator all the time: you can just re-build your application while the emulator is running?

[jyrkiettila]

Mitts:

Thank you for your fast response!

Yes, I agree your analysis. More resources are in use, the bigger is the failure propability. (Or could it be put this way: the longer the emulator startup phase takes, more chances for a timing error or glitch to happen? Some network or SIP stack problem?)

It is an old laptop with lots of stuff installed (Bluetooth USB dongle, many Nokia SDKs, PC Suites, mRouter, Connectivity Framework etc.). Everything works except some Nokia utilities on the System Tray and this emulator/debugger.

12 GB hard disk space free, 768 MB of RAM, of which 358 MB available (260 MB available while debugging) AMD Athlon XP 2000+ CPU ???? MHz. The hard disk is probably slow and fragmented.

I have thought, that I should get a faster development computer for Symbian development.

Still the S60 SDK 2.1 and S80 2.0 SDK have worked without problems (regarding the VS.NET 2003 debugger) in the same machine. (Only suffivcient patience was needed :)

If it is the problem of my resource-constrained PC only, I can get a new computer some day (and use couple of days to install everything into it).

Until that, I use the debugger only when necessary. Otherwise the development environment works.

Thanks for your support!

[mitts]

1. What's with all the "Microsoft Exception" debug messages? Is there a way to turn these off? It's ridiculous and pointless that the emulator is printing this out hundreds of times while it is booting.

AFAIK this is due to mod's done by Symbian in how the emulator leaves are handled. Earlier apparently there was some code to handle them but now they are converted into Windows exceptions, which then are not handled... As a result some Windows code somewhere generates the messages. So unfortunately from Carbide.vs there is nothing we can do to disable them.. :-(

2. If I get a Kern-Exec 3 in my code the debugger catches it but there is no call stack! How am I supposed to debug a Kern-Exec 3 on S60V3!? Of course in some cases I can simply go back and use the S60 V2 emulator to debug the problem, but that's hardly ideal.

Is this just for this one error or in general? I'm not aware of any changes in this area?

Is the solution to all of this to use Carbide.c++ instead? I'd heard that you don't need to re-start the emulator all the time: you can just re-build your application while the emulator is running?

Well, in general, the best overall development experience is being developed for Carbide.c++. Things like on-device debug etc will only appear on Carbide.c++ and also other new developer features will be introduced in Carbide.c++.

At this time, Express does not allow you to rebuild "in the background", this was something that could happen in Carbide.c++ Dev/Pro but not sure what the status it with respect to that..

[Starchaser]

I think it's just any panic, but I'm not sure. It's the Kern-Exec 3's that bother me the most though as they are the ones that happen fairly often when you are developing new code.

If the developer version of Carbide.c++ has both on target debugging and "rebuild in the background" then it will be worth the wait. Is the release date still "September 2006"?

[Giller]

Any decision of the first post problem has been found?

[albinoneto]

Hi All,

when I run my project in debug mode my icon (application) is not loaded in the simulator. Other important point is that the carbide insert a attention symbol to represent my breakpoint.

Is necessary a special configuration for debug mode works on simulator?

thanks,
albino