[delphi] DLL debuggen loopt helemaal in de soep

[_Thanatos_]

Ik heb in Delphi 7.01 een DLL die ik wil debuggen met een extern programma (dat in VC++ geschreven is). Als ik Delphi net opgestart heb, dan werkt dat allemaal prima naar behoren. Echter als ik een paar wijzigingen heb gemaakt, dan gebeurt er iets vreemds.

Ik doe een full rebuild, en de blauwe bolletjes links van m'n source-regels kloppen netjes. Als ik dan de DLL run (met dat programma als host application), kloppen de bolletjes opeens niet meer. What's more: de dingen die uitgevoerd worden, kloppen ook totaal niet! Met natuurlijk de vaagste crashes en exceptions als gevolg

Dus ik sluit Delphi af, start em weer op, doe onmiddelijk een rebuild, en het werkt weer.

Hoe kan dat

[NMe]

Ruimt die DLL al zijn objecten en dergelijke netjes op? Misschien heb je ergens een memory leak ofzo? Het klinkt iig erg vaag.

[Verwijderd]

wis even de DLL, en wis ook alle .dcu's uit je map.

Heb je in je search pad misschien nog een (oude) compiled versie van je DLL staan?

Zoek anders via start --> zoeken even alle compiled dlls en eventueel .dcu's op, en wis deze.

//edit
je gebruikt wel netjes de juiste var's, bv. PCHAR etc?

//edit2

reboot ook even je computer. Het zou de eerste keer niet zijn dat windows een verkeerde DLL nog in het geheugen heeft zitten

[ Voor 45% gewijzigd door Verwijderd op 10-07-2004 23:15 ]

[_Thanatos_]

de DLL overal vandaan verwijderen en alle DCU en andere gecompileerde dingen verwijderen helpt niet. Search pad staat verder goed. Hij kan em ook niet nog in het geheugen hebben staan, omdat ie em anders niet kan compileren (dan is ie nog in gebruik).

Ohja, en ik gebruik natuurlijk PChar enzo. De DLL geeft alles netjes vrij, maar wat ie aan de applicatie teruggeeft, das altijd een vaag verhaal wie dat vrij moet geven
Anyway, als het proces afgesloten is, geeft windows toch wel alles vrij, daar hoort de debugger geen last van te hebben...

[ Voor 40% gewijzigd door _Thanatos_ op 11-07-2004 00:54 ]

[Verwijderd]

Dat kan hij dus wel degelijk wel, maar blijkbaar is dat je probleem niet.

Kan er verder weinig zinnigs over zeggen, daarvoor zul je toch echt code moeten laten zien..

[_Thanatos_]

Ok, hier is je code

Delphi:

library DLLetje;

uses SysUtils;

function DoeIets: Integer; stdcall;
begin
end;

exports
   DoeIets;

end.

Beetje stripped down he
Maar met zo'n triviaal iets gaat het al de mist in. Het heeft echt niets met de code te maken.

[ Voor 7% gewijzigd door _Thanatos_ op 11-07-2004 00:57 ]

[Verwijderd]

_Thanatos_ schreef op 11 juli 2004 @ 00:56:
Ok, hier is je code

Delphi:

library DLLetje;

uses SysUtils;

function DoeIets: Integer; stdcall;
begin
end;

exports
   DoeIets;

end.

Beetje stripped down he
Maar met zo'n triviaal iets gaat het al de mist in. Het heeft echt niets met de code te maken.

De functie DoeIets geeft nu een waarde terug die toevallig op die desbetreffende plaats in het geheugen staat..

Edit: Grote kans dat het gewoon een bug in je programma is.

[ Voor 7% gewijzigd door Verwijderd op 11-07-2004 01:06 ]

[Verwijderd]

_Thanatos_ schreef op 11 juli 2004 @ 00:56:
Ok, hier is je code
Beetje stripped down he
Maar met zo'n triviaal iets gaat het al de mist in. Het heeft echt niets met de code te maken.

Vind het een beetje flauwe reactie. Als je gaat testen, zul je zien dat zo'n triviale DLL het wel doet. Hier iig. wel.

Gebruik je strings?

Important note about DLL memory management: ShareMem must be the
first unit in your library's USES clause AND your project's (select
Project-View Source) USES clause if your DLL exports any procedures or
functions that pass strings as parameters or function results. This
applies to all strings passed to and from your DLL--even those that
are nested in records and classes. ShareMem is the interface unit to
the BORLNDMM.DLL shared memory manager, which must be deployed along
with your DLL. To avoid using BORLNDMM.DLL, pass string information
using PChar or ShortString parameters.

//edit
maar het feit dat je omschrijft dat tijdens debuggen de regels niet kloppen (voert andere code uit dan in je project zit) wijst er toch echt eerder op dat hij een oude/andere versie van die .dll gebruikt.

Windows laadt Dlls en geeft ze pas weer vrij als er geen applicaties geregistreerd staan die ze gebruiken.

Als je windows reboot, is het dan ook opgelost?

[ Voor 17% gewijzigd door Verwijderd op 11-07-2004 01:15 ]

[NMe]

Verwijderd schreef op 11 juli 2004 @ 01:14:
Als je windows reboot, is het dan ook opgelost?

Als het probleem bij een reboot van Delphi al opgelost is, dan lijkt het me dat een reboot van Windows al helemaal een oplossing is.

[_Thanatos_]

Nou, opeens doet ie het weer... je moet zeker Delphi 100x gestart hebben voordat ie het doet (want zoveel keer was het wel).

Delpi's wegen zijn soms ondoorgrondbaar... nou weten we dus nog niet hoe dit kwam en, belangrijker, hoe ik het opgelost heb

[ Voor 35% gewijzigd door _Thanatos_ op 11-07-2004 02:39 ]

[Verwijderd]

_Thanatos_ schreef op 11 juli 2004 @ 02:38:
Nou, opeens doet ie het weer... je moet zeker Delphi 100x gestart hebben voordat ie het doet (want zoveel keer was het wel).

Delpi's wegen zijn soms ondoorgrondbaar... nou weten we dus nog niet hoe dit kwam en, belangrijker, hoe ik het opgelost heb

Soms blijft er een delphi instantie hangen (zie je alleen in task manager terug), die de boel loopt te narren, misschien dat dat het was?