Title: Debugging bei Speicherzuweisung durch die APR
Die Zuweisungsmechanismen der APR verfügen über eine Reihe von Debug-Modi, die Sie bei der Suche nach Speicherzuweisungsproblemen unterstützen können. Im folgenden werden die verfügbaren Modi beschrieben und Anleitungen für ihre Aktivierung gegeben.
free() freigegebener Speicher und
ähnliche Fehler erkannt werden.Die Theorie ist einfach. Das FILL_BYTE
(0xa5) wird an alle mit malloc allokierten
Speicherpositionen geschrieben, wenn sie zugeweisen werden, und
es überschreibt alles, was mit der Funktion clear_pool()
freigegeben wird. Es wird überprüft, ob Blöcke aus der freien Liste
immer das FILL_BYTE enthalten, und es wird während
der Funktion palloc() überprüft, ob alle Bytes immer
noch das FILL_BYTE enthalten. Immer wenn Sie
fehlerhafte URLs oder ähnliches mit vielen 0xa5-Bytes
sehen, dann wissen Sie, dass Daten benutzt wurden, die freigegeben oder
nicht initialisiert wurden.
malloc() vorgenommen und dementsprechend mit
free() wieder freigegeben.Diese Option ist für die Verwendung zusammen mit Electric
Fence oder Purify gedacht, um Speicherprobleme erkennen zu können.
Wenn Sie Electric Fence benutzen, sollten Sie auch
ALLOC_DEBUG angeben, was allerdings nicht gilt, wenn Sie
Purify benutzen, weil ALLOC_DEBUG alle nicht initialisierten
Lesefehler verbergen würde, die Purify erkennen kann.
Insbesondere die
table_{set,add,merge}n-Routinen werden veranlasst, ihre
Argumente auf Sicherheit für die apr_table_t hin zu
überprüfen, in der sie platziert sind. Zur Zeit funktioniert sie nur mit dem
Multiprozessmodell von Unix, möglicherweise wird sie aber noch erweitert.
make_table()-Aufrufen, bei
denen möglicherweise die Tabellen zu klein geraten sind.Hierfür ist ein neueres gcc-Programm erforderlich, das die
Funktion __builtin_return_address() unterstützt. Die Ausgabe
von error_log sieht dann ungefähr so aus:
Mit l *0x804d874 finden Sie die entsprechende Quelle.
Sie zeigt an, dass eine mit einem Aufruf für diese Adresse
allokierte apr_table_t-Tabelle möglicherweise zu klein
initialisiert wurde.
Hierzu muss man wissen, wie alloc.c funktioniert.
Nicht alle aufgeführten Optionen können gleichzeitig aktiviert werden. Die folgende Tabelle zeigt die Kombinationsmöglichkeiten.
| ALLOC_DEBUG | ALLOC_USE_MALLOC | POOL_DEBUG | MAKE_TABLE_PROFILE | ALLOC_STATS | |
|---|---|---|---|---|---|
| ALLOC_DEBUG | - | Nein | Ja | Ja | Ja |
| ALLOC_USE_MALLOC | Nein | - | Nein | Nein | Nein |
| POOL_DEBUG | Ja | Nein | - | Ja | Ja |
| MAKE_TABLE_PROFILE | Ja | Nein | Ja | - | Ja |
| ALLOC_STATS | Ja | Nein | Ja | Ja | - |
Außerdem eignen sich die Debugging-Optionen nicht für Multithreading-Server. Wenn das Debugging mit diesen Optionen durchgeführt soll, muss der Server im Einzelprozessmodus gestartet werden.
Die verschiedenen Optionen für das Debugging des Speichers werden mit
der Header-Datei apr_general.h für die APR aktiviert.
Für die gewünschten Optionen muss in dieser Datei die Kennzeichnung als
Kommentar aufgehoben werden. Zur Zeit sieht der entsprechende Code
wie folgt aus (enthalten in srclib/apr/include/apr_pools.h):
#define ALLOC_DEBUG
#define POOL_DEBUG
#define ALLOC_USE_MALLOC
#define MAKE_TABLE_PROFILE
#define ALLOC_STATS
*/
typedef struct ap_pool_t {
union block_hdr *last;
struct cleanup *cleanups;
struct process_chain *subprocesses;
struct ap_pool_t *sub_pools;
struct ap_pool_t *sub_next;
struct ap_pool_t *sub_prev;
struct ap_pool_t *parent;
char *free_first_avail;
#ifdef POOL_DEBUG
struct datastruct *prog_data;
Um das Debugging für Speicherzuweisungen zu aktivieren, entfernen Sie einfach die Kommentarzeichen aus dem Code und bauen den Server neu auf.
Um die Optionen nutzen zu können muss der Server nach der Bearbeitung der Header-Datei neu kompiliert werden.
Die Dokumentation für Entwickler wurden noch nicht in allen Punkten der Wechsel von der Apache-Version 1.3 zur Version 2.0 berücksichtig. Bei Abweichungen oder Fehlern wenden Sie sich bitte an die Apache Mailing List: [email protected].
- Hilfen von Ian Holsman:
- Tutorials zur Modulentwicklung von Kevin O'Donnell
- Anmerkungen zur Entwicklung von Apache.Modulen von Ryan Bloom
Apache 2.0 verwendet Doxygen für die Dokumentation der APIs und der globalen Variablen im Code. Im folgenden werden die Grundlagen für das Dokumentieren mit Doxygen beschrieben.
Ein Dokumentationsblock beginnt mit den Zeichen /**
und endet mit den Zeichen */
Im Block werden mehere Tags verwendet:
@param Parametername Beschreibung
@return Beschreibung
@deffunc Signatur der Funktion
Das Tag deffunc ist nicht immer erforderlich. DoxyGen
besitzt keinen vollwertigen Parser, so dass jeder Prototyp, der ein Macro
in der Deklaration des Rückgabewertes enthält, zu komplex für Scandoc ist.
Diese Funktionen benötigen ein deffunc-Tag. Ein Beispiel
(mit > an Stelle von >):
* Rückgabe des letzten Elements von Pfadname
* @param Pfadname Der Pfad zum letzten Element von
* @return das letzte Element des Pfads
* @tip Beispiele:
* <pre>
* "/foo/bar/gum" -> "gum"
* "/foo/bar/gum/" -> ""
* "gum" -> "gum"
* "wi\\n32\\stuff" -> "stuff"
* </pre>
* @deffunc const char * ap_filename_of_pathname(const char *pathname)
*/
Fügen Sie am Anfang der Header-Datei immer folgendes ein:
* @package Name des Bibliotheks-Header
*/
Doxygen benutzt für jedes Paket eine neue HTML-Datei. Die HTML-Dateien
tragen die Bezeichnung {Name_des_Bibliotheks_Header}.html,
wählen Sie deshalb prägnante Namen.
Weitere Informationen zum Thema finden Sie auf der Doxygen-Website.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
