Se vogliamo produrre un'alta qualità del nostro Oracle BRM software, dobbiamo soddisfare alcuni requisiti relativi al nostro processo di sviluppo. È particolarmente importante incorporare buone tecniche di test e di debug nel nostro processo di sviluppo.
Il test è un processo di ricerca di bug o errori in un prodotto software che viene eseguito manualmente da un tester o può essere automatizzato.
Debug è il processo di individuazione e risoluzione di difetti o problemi all'interno di un programma informatico che impediscono il corretto funzionamento del software o di un sistema. Si tratta fondamentalmente di un processo di correzione dei bug trovati nella fase di test. Il programmatore o lo sviluppatore è responsabile del debug e non può essere automatizzato.
Indice dei contenuti
Debug del codice personalizzato degli opcode della politica Oracle BRM
Quando si personalizzano gli opcode dei criteri in Oracle BRM spesso è necessario eseguire il debug di alcuni codici per trovare potenziali bug o analizzare il comportamento del codice. Alcune analisi di base possono essere effettuate registrando alcuni messaggi di debug e analizzando i registri, ma un metodo molto più avanzato e potente consiste nell'utilizzare uno strumento separato - il debugger. In questo articolo vedremo come utilizzare il debugger open-source GDB per eseguire il debug di un processo Oracle BRM cm che esegue anche del codice personalizzato (vedere l'immagine sottostante).
GDB è un debugger open-source che fornisce molti strumenti avanzati e potenti per analizzare e debuggare il nostro codice. Alcune delle funzioni di base di GDB sono i punti di interruzione (condizionali/incondizionali), gli orologi, le tracce indietro e l'esecuzione incrementale del codice. Naturalmente, può anche visualizzare e modificare i valori delle variabili e chiamare varie funzioni. Ora vediamo come utilizzare GDB con il processo cm nella pratica.
Il debug in pratica
Per prima cosa, dobbiamo ottenere un PID del nostro processo CM:
ps x
Trova il PID del processo CM e lo usa per collegarsi a quel processo con GDB:
gdb cm
Ora si apre la shell GDB, dove possiamo eseguire vari comandi supportati da GDB. Ogni nuova connessione che viene stabilita al CM provoca la nascita di un nuovo processo CM figlio dal CM padre. Vogliamo che GDB tenga traccia anche di questi processi figli. Eseguire il seguente comando nella shell GDB:
(gdb) impostare follow-fork-mode child
A seconda delle sue esigenze, potrebbe anche voler esplorare i comandi set detach-on-fork e attach. Ora impostiamo un punto di interruzione su un'implementazione di un opcode di politica, come nell'esempio seguente:
(gdb) interrompere fm_act_pol_post_reauthorize.c:192
Quando ora attiviamo l'esecuzione dell'opcode della policy, questa verrà interrotta dal punto di interruzione (o anche prima, ci informerà che è stato generato un nuovo bambino). Possiamo quindi seguire il flusso del codice passo dopo passo, utilizzando i comandi next (abbr. n) o step. Se ci interessa il valore di una variabile, possiamo stamparlo utilizzando i comandi next (abbr. n) o step:
stampa
Abbiamo a disposizione anche molte altre funzioni avanzate e potenti, che sono descritte in dettaglio nella documentazione di GDB e nell'aiuto integrato. La invitiamo a ricercarle per vedere come possono aiutarla.
