2012-01-09 16 views
12

Abbiamo creato un'applicazione che utilizza pacchetti e componenti. Quando eseguiamo il debug dell'applicazione, il "Registro eventi" nell'IDE mostra spesso che i nostri BPL vengono caricati senza informazioni di debug ("Nessuna informazione di debug"). Questo non ha senso perché tutti i nostri pacchetti ed EXE sono costruiti con il debug.L'app Delphi ha "Nessuna informazione di debug" durante il debug

_(each project) | Options | Compiling_ 
[ x ] Assertions 
[ x ] Debug information 
[ x ] Local symbols 
Symbol reference info = "Reference info" 
[ ] Use debug .dcus 
[ x ] Use imported data references 

_(each project) | Options | Linking_ 
[ x ] Debug information 
Map file = Detailed 

abbiamo 4 progetti, tutti costruiti con pacakges runtime:

  1. Core.bpl
  2. Components.bpl
  3. Plugin.bpl (utilizza sia # 1 & # 2)
  4. MainApp.exe (utilizza # 1)

problemi osservati

1) Molte volte quando si esegue il debug, la Components.bpl è caricato con informazioni di debug, ma tutti i valori nella finestra "Variabili locali" sono vuoti. Se si posiziona il puntatore del mouse su una variabile nel codice, non vi è alcun popup e la finestra di valutazione mostra anche nulla (il riquadro "Risultato" è sempre vuoto).

2) A volte il registro eventi mostra "Nessuna informazione di debug" per vari BPL. Ad esempio, se attiviamo il progetto Plugin.bpl e impostiamo su Esegui | L'applicazione host del parametro deve essere MainApp.exe, quindi premere F9, tutti i moduli sembrano caricarsi con "Has Debug Info" ad eccezione del modulo Plugin.bpl. Quando viene caricato, il registro eventi mostra "Nessuna informazione di debug". Tuttavia, se chiudiamo l'app e preme immediatamente F9, verrà eseguito di nuovo senza ricompilare nulla e questa volta Plugin.bpl è caricato con debug ("Has Debug Info").

Domande

1) Che cosa potrebbe causare la finestra "variabili locali" per non visualizzare i valori?

2) Perché a volte i BPL vengono caricati senza informazioni di debug quando la BPL è stata rispettata con il debug e tutti i file di debug (dcu, map, ecc.) Sono disponibili?

risposta

2

Per la nostra situazione particolare, siamo stati in grado di risolvere il problema combinando Core.pbl e Components.bpl in una singola BPL. Ora tutti i moduli sono caricati con informazioni di debug e il problema occasionale in cui la finestra Locals non visualizza i valori per le variabili viene risolto.

+2

Combinare i BPL per sbarazzarsi del problema non è una buona soluzione. Immagina di avere centinaia di pacchetti dinamici, impossibile combinarli in un'unica BPL. –

+0

@ChauCheeYang - Abbiamo dozzine di altri BPL. Era solo la separazione di questi due a causare il problema. Nel nostro caso, la combinazione di questi due è stata accettabile - lasciando le altre dozzine separate ... Potrebbe aver avuto qualcosa a che fare con Components.bpl dipendeva molto da Core.bpl. –

+0

Hai usato il riferimento optset per entrambe le configurazioni 'debug' e' release'? –

2

Devi costruire i tuoi pacchetti separati con le informazioni di debug, e alla fine vorrai costruirli anche senza debug - quindi avrai entrambi in 2 punti. Quindi vuoi costruire il tuo progetto di app con le informazioni di debug. Controlla i tuoi percorsi per assicurarti di includere l'origine del pacchetto abilitato per il debug nelle build del tuo progetto di debug. Sembra che potresti includere pacchetti che sono stati creati senza debug perché stai includendo dalla fonte sbagliata. Devi assicurarti di non avere entrambi i percorsi inclusi, lasciando a Delphi la scelta di includere se trova lo stesso pacchetto in due punti.

+0

Tutti i nostri progetti sono creati con debug e sia DEBUG che RELEASE utilizzano le stesse cartelle di output. Quindi non è un problema con i pacchetti che vengono creati senza DEBUG o che il debugger sta trovando le versioni RELEASE di uno qualsiasi dei pacchetti ... Verificheremo i percorsi per essere sicuri che le DCU di debug siano state trovate correttamente. Grazie per i suggerimenti. –

+0

+1 per il tuo suggerimento di controllare i percorsi. Questo mi ha portato ad aprire la finestra Debug Modules, che mostra dove vengono caricati i simboli di debug. Questo mi ha portato all'idea che ha risolto il problema (vedi risposta sotto). –

4

Abbiamo riscontrato un problema simile nel nostro progetto. Purtroppo abbiamo dozzine di bpl quindi non possiamo unirle in una. Questo problema si è verificato dopo la migrazione a XE2 e la struttura delle cartelle del nostro target di compilazione. Mentre è difficile dire se le nuove versioni di Delphi hanno introdotto il problema oppure no, potremmo risolvere il problema aggiungendo la cartella in cui sono stati compilati i bpl nella variabile di ambiente path. Utilizzando la funzione di override del percorso dell'IDE.Questo tipo di configurazione non era necessario in Delphi 2010 ...

4

Descriverei il mio problema con esso.

Carico dinamicamente il pacchetto utilizzando la funzione LoadPackage.

È possibile vedere in SysInternals.com Process Monitor che packagename.DCP è stato aperto e letto correttamente dopo lo LoadPackage elaborato: nessun I/O di file non è riuscito, nessun tentativo di trovarlo nei posti sbagliati, niente di sospetto. Quindi forse c'è qualche costrutto in DCP che rende il debugger IDE impazzito. Ho nostalgia dei momenti in cui Turbo Debugger era disponibile per Delphi.

BTW, lo stesso vale per packagename.RSM è uno crea tale.

Quindi (durante la pausa al punto di interruzione o Step Trace) apro Visualizza/Debug Windows/Moduli e vedo l'ultimo modulo è mio - e ha una cella vuota "informazioni sui simboli". Faccio clic con il pulsante destro del mouse, scegli "Ricarichi simboli" azione - ed eccolo, d'ora in poi posso eseguire il debug.

PS. Non so se questo mi aiuterebbe a eseguire il debug delle sezioni di inizializzazione però - si spera che la voce di menu "break on load" funzioni anche con chiamate dinamiche LoadPackage ...

PPS. Funziona davvero, anche attraverso riavvii IDE. Così ora sono allertato al caricamento BPL con CPU View, io colpisco CTRL+ALT+M, scorri verso il basso per trovare la mia BPL, r-clic su Reload Symbols, premi Invio, quindi chiudi Modules e CPU Visualizzazioni e colpisci F9 (Run). Dopo che le sezioni initialization sono state completate, sono stato nuovamente avvisato da CPU View - solo pochi JMP s prima dell'uscita da LoadPackage - quindi chiudo CPU View e il numero F9 ancora una volta. Piuttosto noioso, ma ancora meglio del riavvio di IDE.

+0

Non risponde * perché * mancano le informazioni di debug, ma +1 per l'utile soluzione alternativa. È molto meglio che riavviare Delphi e provare ancora e ancora fino a quando finalmente funziona. –

+0

non manca, è presente in BPL - CFF Explorer lo mostra. il fatto è che IDE non lo usa, usa invece il file DCP. E se ci sono diversi file DCP, allora fallisce. Tuttavia, perché a volte fallisce anche quando l'unico DCP è presente e legge chiaramente quel file ok - questo è un mistero. Nel mio caso ho trovato le unità con lo stesso nome EXE: Path1 \ name e BPL1: Path2 \ name - tuttavia BPL1 e BPL2 loadokay e solo BPL3 con caricamento dinamico erano interessate. Comunque, l'unità SysInit dovrebbe essere clonata in tutti i file EXE/DLL/BPL in modo da non confondere il debugfer IDE. Mistery. PS thx 2u per la visualizzazione dei moduli –

+0

Prego, ma non ho mai provato a fare clic con il pulsante destro del mouse per indicare "ricarica simboli". È un bel trucco nuovo. –

2

Questo problema potrebbe essere releated a QC#109291:

Quando Delphi Iniziamo introdurre .dproj di file e costruire configurazione con set di opzioni, è migliorare la gestione del progetto di rilascio molto.

Tuttavia, ha anche un effetto collaterale che è difficile da riprodurre e catturare e ho pensato che fosse un errore in IDE. Il problema dovrebbe sempre confondere gli utenti in cui alcuni progetti non sono in grado di eseguire il debug nel debugger IDE. Anche controlliamo tutte le impostazioni correlate del compilatore e le opzioni di collegamento nel progetto, il debugger non si attiverà sul progetto. Alcuni progetti funzionano e alcuni progetti no. Riteniamo persino che sia un problema di memoria o di CPU.

Ho notato che il problema è dovuto all'impostazione del file .dproj e non memorizza le informazioni corrette. Se il file .dproj correlato ha qualcosa di simile:

<PropertyGroup Condition="'$(Config)'=='Release' or '$(Cfg_1)'!=''"> 
    <Cfg_1>true</Cfg_1> 
    <CfgParent>Base</CfgParent> 
    <Base>true</Base> 
</PropertyGroup> 
<PropertyGroup Condition="'$(Config)'=='Debug' or '$(Cfg_2)'!=''"> 
    <Cfg_2>true</Cfg_2> 
    <CfgParent>Base</CfgParent> 
    <Base>true</Base> 
</PropertyGroup> 

<Import Project="Release.optset" Condition="'$(Cfg_2)'!='' And Exists('Release.optset')"/> 
<PropertyGroup Condition="'$(Cfg_1)'!=''"> 
    <CfgDependentOn>Release.optset</CfgDependentOn> 
</PropertyGroup> 
<Import Project="Debug.optset" Condition="'$(Cfg_1)'!='' And Exists('Debug.optset')"/> 
<PropertyGroup Condition="'$(Cfg_2)'!=''"> 
    <CfgDependentOn>Debug.optset</CfgDependentOn> 
</PropertyGroup> 

La Release.optset legano a Cfg_2 e Debug.optset legano a Cfg_1 ma la configurazione Release sta usando Cfg_1 e la configurazione Debug sta usando Cfg_2.

Quando si crea il progetto, le informazioni di debug non generano nella configurazione di debug ma generano nella configurazione di rilascio.

Una soluzione alternativa è aperta.dproj con qualsiasi editor di testo, ma non Delphi IDE e aggiornamento:

<Import Project="Release.optset" Condition="'$(Cfg_1)'!='' And Exists('Release.optset')"/> 
<PropertyGroup Condition="'$(Cfg_1)'!=''"> 
    <CfgDependentOn>Release.optset</CfgDependentOn> 
</PropertyGroup> 
<Import Project="Debug.optset" Condition="'$(Cfg_2)'!='' And Exists('Debug.optset')"/> 
<PropertyGroup Condition="'$(Cfg_2)'!=''"> 
    <CfgDependentOn>Debug.optset</CfgDependentOn> 
</PropertyGroup> 
+0

Questo sembra promettente, ma non potrò testarlo fino a quando non mi imbatterò in una situazione in cui mancano le informazioni di debug. Grazie per aver condiviso la tua esperienza. –

+0

Vero. Ho risolto molti problemi eliminando il file dproj e lasciando che Delphi lo rigenerasse. Uno dei tanti esempi: http://stackoverflow.com/questions/21958575/access-violation-when-i-drop-a-tidsmtp-on-a-form – Ampere

0

ho trovato nel file .dprj una riga nel Cfg_2 dettagli con Debugger_LoadAllSymbols valore che è stato impostato su false. L'ho impostato su true. Problema risolto. Forse non è simile al tuo caso, ma potrebbe aiutarti.

<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''"> 
... 
    <Debugger_LoadAllSymbols>true</Debugger_LoadAllSymbols> 
... 
</PropertyGroup> 
4

Questo non-official tool corregge molti problemi con Delphi. Ha corretto il caricamento del modulo senza informazioni di debug per me. Tutti i crediti per magicandre1981.

+0

Ho avuto problemi con il debug di pacchetti di progettazione in Delfi XE6, IDE non voleva caricare le informazioni di debug. Questo strumento ha aiutato, grazie! –

+0

Avevo anche eseguito il tab "CPU" ogni volta che veniva colpito un breakpoint -> my bpl e app sono stati caricati senza Debug Info. Ho installato questo strumento e ha funzionato. Grazie! – santiagoIT

Problemi correlati