My personal opinion is that I would love to do automatic testing but I havent figured out an efficient way to do this in Symbian C++. I am a huge fan of unit testing in java but C++ just seems inappropriate. If someone has a good hint on how to do automatic unit testing please let me know.

Regards
- Rainer

I already sent you this, but for anyone else reading – if you get this error:
Error: 0×20 Unspecified general OS-related error
Then there is a very good chance its related to Platform security.

To confirm this, create the application, SIS and sign it, then install the application outside of codewarrior. In my case (above) the problem was that my DevCert had expired. However any of the platsec errors might cause this – for example setting the time of the phone to before the DevCert was created.

Also note that I’ve found it is possible to debug into the server-side – simply by putting your breakpoint on the server rendezvous. However you can’t debug both sides of a client-server on-device simultaneously because you can only view one process at a time. For debugging you might try running your server in the same process to get around this – and if your architecure allows it.

Regards
H

PS Mika, thank you for your help on this. Stirling.

Re your answer http://mikie.iki.fi/wordpress/?p=33#comment-6299 this was very helpful.

Was able to verify that if I pre-created the SIS file it would install/debug. Couldn’t get existing PKG to generate SIS so used the wizard to create a new one – it all then just worked out of the box to debug on N73.

Unfortunately the same project gives “Unable to create process” on E61. Which just goes to show that your “Flaky, very Flaky” heading is sadly true.

Thanks very much for the help.

Regards
H

In the beginning, Jaiku was mainly developed on N80, E70 and N73. We had nasty surprises with the N93 (transparency working differently and left-softkeys layout), E61 (early firmware gives a KERN-EXEC 3 when deriving from CAknTitlePane, and problems with repeated GPRS connection attempts), APAC variants (different font baseline) and now with the N95 (crashes in CPbk classes, CFormattedCellListbox incompatibility).

Drop me a line if you have a version you want tested on an N80.

I don’t have UIDs in the names but the names won’t clash. I don’t think there was mif in the package, reg file I could try to change.

But it’s so difficult when it’s working on the device I own personally, must try to get other phones to test more. And now I’m working on a newer version with a different architecture, but it would be nice to get that version out to testers even if it’s going to be replaced with a newer one some day.

Do your EXE and DLL names include the application UID? (so that they don’t clash with anything).

Since it’s an app, what about replacing the mif and _reg.rsc files with known working ones (with the UIDs fixed, of course).

* add the pkg file to your CW project
* In the Symbian Installation panel, set:
** output filename to your package name with extension SIS
** output location to the dir your package is in
** Check Sign SIS file
** set Signed File Name to X.SIS
** certificate and key to your devcert and key
* In Remote Debugging, set
** Remote download path to DRIVE:\sys\bin
* In the Symbian TRK Debugging, set
** Check Use SIS installation process
** Set host path for SIS file to the correct path and name for X.SIS
** Set Installation drive as DRIVE
** Timeout high enough to transfer and install the file, e.g. 30 (s)
** Target path as e.g. ‘C:\install.SIS’ – somewhere you can write, with extension SIS
** Uncheck ‘Download files in the remote download panel’
** You can uncheck ‘Install for each debug session’
* Check that the Installation settings on your E61 allow ‘All’ installs, rather than ‘Signed only’

(you can leave the pkg out of the project. In that case manually create the signed SIS file, and set the correct path in host path for SIS file.)

In the IDE preferences, Check ‘Log communication Data to Log Window’ in the Symbian MetroTrk, so that you can see what the debugger tries to do.

The important bits are:
* You must use the SIS installation method on secured platforms, as you can’t directly place files in \sys\bin. In that case the files in ‘Remote Download’ panel are not actually copied.
* The debugger will try to launch your process from the file: ‘Remote Debugging|Remote download path’ . ‘Symbian Linker|Output file’.
* The SIS file is first send to the device, then installed. The installer won’t do any prompts and won’t honor FILERUN directives, and won’t do a normal Remove of the previous version, it just replaces files (e.g., FILENULL files are not removed, FILERUN, RUNREMOVE are not run)

For your second question: I have not found a reasonable way to debug several processes. You might want to do a debug build where the servers are launched as threads from your main process instead (like you normally do on WINS).

In any case, do you happen to know whether the TRK will allow simultaneous debugging across different processes? Specifically, if it will allow me to debug across a client server boundary? If so, what special configuration is required. If not, is the only option to debug each half of the server separately?

I don’t know for sure that none of my code runs but if I can’t Exit() or Leave() from the AppUi’s ConstructL() (probably not a nice thing to do anyway) before it reboots, I’m betting it doesn’t run any of my code. If I had those devices now, I could try to use a debugger, didn’t have one available at the time and only had the devices for an hour. Also tried to create a file etc, nothing happened.

The compilation was done with S60 3rd ed SDK and also MR, same thing with both. Default options (i.e. no optimization) and the SIS was about 200k, so not that big (no other files in the SIS, just the app).

It’s so nice when you’re supposed to have a test version of your app for the users to test and then this happens. Fortunately they understood that it’s not my fault.

What are you compiling with and with what optimization options? How large is the application?

How do you know that none of your code runs? Do you have some RFileLogger prints in your E32Main (In my experience the debugger can not be trusted, and of course RFileLogger doesn’t work on the N93)?

I haven’t seen anything quite like what you describe – the only reboots I get are from actual running code – passing broken parameters to ETEL is a favorite way :-).