--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/PDK/Source/GUID-0AC0CBBA-87AD-5F94-8F0D-D13654ABB631.dita Fri Jan 22 18:26:19 2010 +0000
@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept xml:lang="en" id="GUID-0AC0CBBA-87AD-5F94-8F0D-D13654ABB631"><title>Software Behaviour in a Debug Environment</title><abstract><shortdesc>To aid debugging the Comms software is designed to behave differently for release and debug binary files if certain configuration parameters are set. </shortdesc> <p>The following is a list of some of the behavioural changes: </p> </abstract><prolog><metadata><keywords/></metadata></prolog><conbody><ul><li id="GUID-03213A90-9140-53FC-9CD5-89A4279047C2"><p> <b>Errors may panic in debug builds</b> - Release builds do not panic for most error conditions since panicking results in the loss of the service due to thread termination. If the thread is a SystemCritical the device reboots when the thread is panicked. Debug builds often panic when an error is detected. For example, if the debug version of the software detects an error in a configuration file it panics the thread to draw attention to the mismatched configuration. In a release build the software uses a default configuration to work around the problem. Other such events include failed internal consistency checks, failed internal connections between components, and cleanup failures. </p> </li> <li id="GUID-94F65C60-C228-514A-A35F-98934085BAD6"><p> <b>TestMode parameter controls thread panic behaviour</b> - The <codeph>TestMode</codeph> parameter is available in the <codeph>c32start.ini</codeph> file located in <codeph><drive>\private\101f7988</codeph>. If the parameter is absent or set to 0, the Rootserver does nothing. If the parameter is set to 1 (<codeph>TestMode=1</codeph>), the Rootserver overrides and disables the SystemCritical setting for its threads. As a result, when any Rootserver thread terminates, it does not cause the device to reboot. This parameter was designed to be used during testing of cases which involve shutting down the Comms servers. The SystemCritical setting is configured in the CMI files, for more information see <xref href="GUID-FEB6F717-C86C-54A5-B8D1-B2D882C5AC55.dita">CMI files - thread configuration</xref>. </p> </li> <li id="GUID-1C260CF4-390E-5D6C-B587-FB551C5864BD"><p> <b>Servers can be shutdown to help detect memory leaks</b> - For more information see <xref href="GUID-0AC0CBBA-87AD-5F94-8F0D-D13654ABB631.dita#GUID-0AC0CBBA-87AD-5F94-8F0D-D13654ABB631/GUID-B8A8B315-8C46-551A-B8F6-29BD24F45435">Detecting Memory Leaks</xref> </p> </li> <li id="GUID-AD2E73D1-0BCE-565B-9F66-BB901CCEDEE1"><p> <b>Serial ports may require further configuration</b> - The process of testing, debugging and logging may require extra serial ports, so existing serial-port clients such as Bluetooth and C32 clients might be affected if there is contention. For more information about configuring comms serial ports see <xref href="GUID-B93D6BAE-B9B9-5118-92DF-5E566E5BE8EB.dita">Configuring Comms</xref>. For more information on configuring the RDebug port see <xref href="GUID-F3272004-B899-58A3-A654-27E47362D21A.dita">Writing trace code using RDebug::Print</xref>. </p> </li> <li id="GUID-8199B221-7C35-5FA4-AAD5-3C16FBAAF85A"><p> <b>Commdb/Commsdat</b> - The Comms Database contains the largest number of parameters to configure the Comms system. For more information see <xref href="GUID-BD971173-E009-58DA-AF9C-F4AAFF77B138.dita">Comms Database</xref>. </p> <p> <b>Note:</b> Check the Comms Database configuration used to ensure that there are no mistaked in the configuration. </p> </li> </ul> <section id="GUID-B8A8B315-8C46-551A-B8F6-29BD24F45435"><title>Detecting Comms memory leaks</title> <p>The multi-threaded nature of much of the Comms software complicates the detection of memory leaks. This is because for some of the Comms software memory leaks can only be detected once all the handles are closed, a condition usually only reached during shutdown. As most Comms servers never shutdown, because doing so would reboot the device, the leaks in Comms software and plug-in software such as CSYs and NIFs can go unnoticed. Detecting these leaks requires a special shutdown command for the Comms servers in association with the <codeph>TestMode</codeph> parameter and then the inspection of the logged output for any leak information. </p> <p>During shutdown, memory leaks are logged using the "<codeph>LOG RSModule
+ Leak</codeph> " CDU tags so make sure these are enabled before shutdown. </p> <p>When a potential memory leak is found the separate Hooklogger tool, which runs on MS Windows™, is used to track the memory leak. The process is as follows: </p> <ul><li id="GUID-24109F28-62A5-5F1E-87C5-DEAD9E4690D7"><p>Setup the Hooklogger application and attach its hooks to the kernel binary files </p> </li> <li id="GUID-12FAE5EE-0E75-5C1B-91DB-4BFF17481AD6"><p>Start the Hooklogger application and instruct it to capture memory allocations </p> </li> <li id="GUID-025613F9-EBBE-5B91-BA14-DEAA0F48D36E"><p>Performing the server shutdown and wait for it to complete </p> </li> <li id="GUID-E1A8D430-D5AB-5581-B290-439310B78BBB"><p>Find the addresses of the leaked memory cells in the log file by checking all logging which was tagged with "<codeph>RSModule</codeph> " </p> </li> <li id="GUID-7D8394CE-7CEB-5963-AB40-6F1986F1D173"><p>Search the Hooklogger captured data for each leaked cell </p> </li> <li id="GUID-BD619424-8D30-5295-A009-F29433FC2B57"><p>Hooklogger's data will indicate where the leaked cell was allocated in the source code </p> </li> </ul> <p>For more information on Hooklogger, see the separate topic <xref href="GUID-6A6A6648-6573-5EE4-A191-32B3C207305B.dita">Memory leak detection</xref>. </p> <p>For more information about ESock's shutdown procedure see section <i>6.3 Unloading ESOCK</i> of <i>ESOCK "How-to"</i>. </p> <p>For more information about the use of heap checking to detect and debug memory leaks within the server and its plug-in <keyword>CSY</keyword> s see the <i>C32 Heap Check Migration Document</i>. There is no document which describes shutting down the C32 Serial Server, but C32's shutdown was modelled on ESock's shutdown so the principles are the same and the scripts are named <codeph>te_c32_test_unloadc32*.script</codeph> in the folder <codeph>..\ser-comms\c32\Test\TE_C32\util\scriptfiles\</codeph>. </p> </section> </conbody></concept>
\ No newline at end of file