Flaky, very flaky

Trying to crunch through all the robustness and stability testing necessary for Symbian signed I’m becoming sick and tired of the quality of the platform we are supposed to use. I have wasted countless hours with the following problems:

  • CodeWarrior crashes regularly when debugging. Several times a day, mostly with on-device debugging but now and then also on the emulator. I’ve sent the crash dumps to Nokia who we’ve paid quite a bit for the licenses, but nothing so far.
  • CodeWarrior keeps hidden references to projects, so after an MMP change I can’t reload the XML without restarting the whole IDE.
  • We have both Finnish and English resource files. Compiling the resources CodeWarrior generates the same output for both variants (Finnish). Resources have to be recompiled on the command line.
  • The N80 hangs with on-device-debugging _all the f*cking time_. I don’t know if the problem is with the App TRK, the USB implementation or the physical connection, but I can basically count on having to take out the battery after each debugging session (it does seem to be a problem with the physical connector on the phone).
  • The Symbian Signed criteria states that we should handle out-of-disk-space situations gracefully. Never mind that the platform doesn’t: App TRK sometimes hangs when filling disk space, and the application manager often fails to remove an application from a full disk without any explanation (no error display whatsoever, the uninstall just doesn’t happen). And Leaving with KErrDiskFull from a document’s ConstructL normally produces no user-visible feedback, you have to implement that yourself.
  • Even tho LOWMEM testing is waived for 9.1, we’ve been doing it on the emulator to find bugs in error handling and destructor code. Leaving from an AppUi’s ConstructL leaks memory, since the AppUi is not destructed by the framework in that case (and cannot safely be destructed manually).
  • The Bluetooth stack on the N80 seems to be almost as bad as back in the days of the 7650. Using it as a modem with my laptop or transferring files starts failing after a few times, and necessitates me to go to the phone and switch the bluetooth off and on to recover. Trying to transfer data from my older phone via bluetooth gives btnotifappserver -44. On an E70 you get the classic BTServer crashes.
  • To be able to step into code or set breakpoints in CodeWarrior, the project’s target has to be set to the active debugging target. This means that switching debugging between the emulator and the device requires you to switch the target in all your projects, for us in about 30. Remains to be scripted.
  • The scripts that generate CodeWarrior project import XML files are broken in multiple ways (some of which we’ve fixed by now, some that await fixing), for example: if you have no DEF file and specify EXPORTUNFROZEN, an imaginary base DEF file is still put to the linker command line, which then fails.
  • Trying to install a SIS file over bluetooth with PC Suite just gives ‘Operation failed’.
  • Giving the following backup_registration.xml to the phone makes the phone backup engine crash: a sbengine USER 130 panic. This would of course fail signing. Without the public_backup bit the backup engine doesn’t crash, but our files are not backed up because the application is not closed before the ‘Full backup’ stage, which is after public file backup.
    <?xml version="1.0" standalone="yes"?>
            <restore requires_reboot = "no"/>
  • An application running out of memory (exceeding maximum heap size) makes the phone reboot (yes, we’ve now both tuned the memory usage and upped the heap limit)
This entry was posted in Symbian. Bookmark the permalink.

20 Responses to Flaky, very flaky

  1. Sorry for you, Mika.

    As for the debugging part, utilizing more of test driven development and automated unit/module/acceptance testing in general can significantly reduce the need for debugging.

    Though, the OutOfResource trials should still be attempted on the real phone at least once.

  2. Riho says:

    It’s good to know that I’m not the only one thinking dark thouths about Symbian and Nokia :)

    Just to add something – we made a MTM to handle some file manipulations from Galler. The ** system insists to copy the file to C:\Mail folder even when we tell him that we don’t want attachments. This causes “out of space” error from Gallery with big video files from memory card.

  3. tanzim says:

    1.CodeWarrior keeps hidden references to projects, so after an MMP change I can’t reload the XML without restarting the whole IDE.

    Ever tried: Project->Re-Import Symbian Project XXX in CW?

    2. We have both Finnish and English resource files. Compiling the resources CodeWarrior generates the same output for both variants (Finnish). Resources have to be recompiled on the command line.

    CTRL+- or Project->Remove Object Code in CW and rebuild

    3. Giving the following backup_registration.xml to the phone makes the phone backup engine crash: a sbengine USER 130 panic.




    4. An application running out of memory (exceeding maximum heap size) makes the phone reboot (yes, we’ve now both tuned the memory usage and upped the heap limit)

    Yeah, it would, I do have a feeling that one of your thread/process is marked system critical!

    I do sympathize with your observations though, Symbian OS has a long way to go to make life easier for developers…

  4. tanzim says:

    Now I’m pissed on wordpress!

    3 should read:


    <public_backup> <include_directory>\Data\Context\</include_directory> </public_backup>


    <public_backup> <include_directory name=”\Data\Context”/></public_backup>

  5. Mika says:

    Hmm. I’m not saying these just out of contrariness, but so that we can actually try to understand potential solutions.

    1. We are using the XML files created with abld makefile cw_ide, because the MMP import doesn’t handle c-preprocessor directives correctly (actually, it does on import, but not on re-import). For each project we only have one MMP file, in which we include a header that defines the SDK version and then use conditionals to vary the MMP.

    2. That might have helped, although I doubt it: the resource definition file generated by abld makefile had the same language code twice.

    3. I’ll try that out, thanks.

    4. It wasn’t a system app (which is not the same thing as a system process/thread, which it wasn’t either), and crashing with any other kind of PANIC does not cause the phone to reboot.

    Thanks for the comments tanzim.

  6. Mil says:

    Why dont you try using Carbide.C++? Its much better than the CodeWarrior.

  7. Mika says:

    Two reasons:

    • haven’t had time yet, since we need to get some actual development done too
    • point 1 above: it doesn’t support our MMP files, so we’d need a different setup for the whole project

    So how easy is it to manipulate projects programmatically in it? Currently the only saving grace of CodeWarrior is the COM automation interface. Carbide.C++ is eclipse-based, so it should be automatable?

  8. Symbiatch says:

    You mention exceeding the heap size as one cause for the phone to reboot itself. I’ve had lots of problems when trying to get an app to run on 3rd eds. On my N93 it runs fine, lots of memory free (since I can alloc more when using the app) etc. Install on N80, phone reboots. Install on N73, phone reboots. And it boots before any of my code is run (tried to put the app to exit on AppUI, still reboot).

    Just wondering if you’ve run into any other situations where this happens since I’m not convinced it would be because of the memory situation in this case :P

  9. Mika says:

    Hmm. You are right: it doesn’t sound like running out of (heap) memory. What about stack size (increase it some to be sure – I don’t quite know how it is handled, but it seems that the object code contains some info on how much stack it needs and if the stack size is less, it won’t even start)? And ‘install on N80, phone reboots’ I assume you mean ‘install, _run_, phone reboot’? What is the heap size in your MMP?

    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 :-).

  10. Symbiatch says:

    Yes, I meant “install, run, reboot.” I tried different stack sizes (8k, 32k etc) but that didn’t help. I don’t know if there are differences in the libraries that are available in these phones but surely Symbian can’t be that bad that it reboots if a library is not available or is different…

    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.

  11. You’re lucky, I can’t even get the S60 v3 MR Helloworldbasic to debug on Nokia E61. I have a connection, but when I try debug I get plugin error “Failed to load the specified program to the target”. How helpful is that? I guess that maybe the SIS file isn’t being created – but since I can’t work out where it should be created, not easy to confirm or deny.

    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?

  12. Mika says:

    Hamish: do make sure you have all the settings correct for SIS installation:

    * 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).

  13. Mika says:

    Symbiantch: do add some RFileLogger output to your application initialization: E32Main, NewApplication, CreateDocumentL, AppUi’s ConstructL, to see if any of them are hit.

    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).

  14. Symbiatch says:

    I must try RFileLoggers if I get a hold of some of those devices again, E61 should arrive some day, maybe that’ll not work too :)

    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.

  15. Mika says:

    If you are seriously considering to distribute your app widely, you do need access to almost all handsets to test with. Times different firmwares (you must at least have the first couple of firmwares, and the different region-variants (EMEA, APAC, Arabic-Hebrew) if you want to support them).

    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.

  16. Hi Mika

    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.


  17. Hi Mika

    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.


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

  18. Rainer Burgstaller says:

    I can fully back the initial blog post having made similar experiences.
    @automatic testing: I got a few comments to that having tried that myself a couple of times.
    a) It is extremely laborous to do automatic testing in C++ especially on symbian as most of the frameworks dont support active objects properly.
    b) maintaining the tests then is even worse as it makes refactoring very difficult and laborous.
    c) automatic unit testing works best for stateless systems. Complex applications although (especially graphically rich ones) do use state which makes unit testing just so much harder. It takes LOTS of boilerplate code in order to instanciate and setup test objects, not to mention all the different combinations of cases.

    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.

    - Rainer