Autor Téma: ladění v Turbo Delphi  (Přečteno 3785 krát)

Offline frankee

  • Příspěvků: 16
  • Karma: 3
ladění v Turbo Delphi
« kdy: 21-06-2012, 08:32:16 »
ahoj,
dělám program, který má chybu a padá..  Je to chyba, že je nutno restartnout celý komp s win64, takže paráda,
ještě lepší je, že program se kousne po cca hodině a půl provozu a Turbo Delphi mě hodí ne někam do kódu, ale
vyhodí okno "CPU" kde ať dělám co dělám, nic nezjistím...

A) Je ladění v Delphi XE lepší ? (mám koupené delphi XE a zatím jsem se nedokopal k tomu abych celou tu VĚC přepsal) 
B) ví někdo jak lépe odhalovat zhroucení programu ? (používám logování výjimek do souboru, zkoušel jsem GP profiler. Ten vyhodí nějaká dvě čísla u kterých jsem ale nezjistil co znamenají. )
C) Jak zjišťujete chyby v alokování / uvolňování zdrojů (Pořád mi roste paměť co program spotřebovává) ?
D) znáte nějaký dobrý profiler ? Nebo používáte něco, co umí ukázat program rozpadený na vlákna, a zatížení procesoru jednotlivým vláknem ?

Ještě přidám informaci, že používám volání knihovny z C, která se jmenuje BASS... Celé to zpracovává zvuk na více zvukovek,
je to vícevláknové a složeno z objektů, které mezi sebou fungují víceméně samostatně (akorát si posílají události)
bohužel projekt již zřejmě svou velikostí přesáhl únosnou míru co lze uržet v hlavě a navíc při namnožení mnoha instancí objektu se projevují postraní efekty jinak velmi výhodné multiplikace.

V turbo delphi mám všecken debuging zaplý,

díky Petr

Offline pepak

  • Guru
  • *****
  • Příspěvků: 1436
  • Karma: 34
    • Pepak.net
Re:ladění v Turbo Delphi
« Odpověď #1 kdy: 21-06-2012, 08:41:58 »
B) ví někdo jak lépe odhalovat zhroucení programu ? (používám logování výjimek do souboru, zkoušel jsem GP profiler. Ten vyhodí nějaká dvě čísla u kterých jsem ale nezjistil co znamenají. )
Pro něco takového se typicky používají různé speciální knihovny, které kromě typu výjimky a adresy, kde nastala, vypíšou více či méně užitečné info o okolnostech výjimky. Já třeba používám EurekaLog, který ti vypíše velmi podrobný stack trace (ze které unity se to volalo, z jaké její funkce a z jakého řádku té funkce), přidá parametry procesu (kdo byl přihlášen, jaké moduly jsou v paměti) a spoustu dalších věcí a celé to třeba pošle na e-mail. Existují i další podobné knihovny. Jestli některá z nich funguje s Turbo Delphi, nevím.

Citace
C) Jak zjišťujete chyby v alokování / uvolňování zdrojů (Pořád mi roste paměť co program spotřebovává) ?
Pokud máš kód napsaný tak, že to nenajdeš na první pohled, a současně to roste tak moc, že stojí za to to řešit, tak použij nějaký alternativní memory manager, jako například FastMM - prakticky všechny ti umožní hlídat, která alokovaná paměť nebyla dealokována a odkud se alokovala. O použitelnosti pro Turbo Delphi platí totéž, co výše - nevím.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2349
  • Karma: 102
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
Re:ladění v Turbo Delphi
« Odpověď #2 kdy: 21-06-2012, 09:28:01 »
Citace

A) Je ladění v Delphi XE lepší ? (mám koupené delphi XE a zatím jsem se nedokopal k tomu abych celou tu VĚC přepsal) 

To každopádně.
Citace

B) ví někdo jak lépe odhalovat zhroucení programu ? (používám logování výjimek do souboru, zkoušel jsem GP profiler. Ten vyhodí nějaká dvě čísla u kterých jsem ale nezjistil co znamenají. )
Dost jsem se tomu na delphi.cz věnoval. Velmi pomůže FastMM a FullDebugMode. Popřípadě http://www.eurekalog.com/
Citace

C) Jak zjišťujete chyby v alokování / uvolňování zdrojů (Pořád mi roste paměť co program spotřebovává) ?
FastMM4 a FullDebugMode

Citace

D) znáte nějaký dobrý profiler ? Nebo používáte něco, co umí ukázat program rozpadený na vlákna, a zatížení procesoru jednotlivým vláknem ?

Zkus http://delphitools.info/samplingprofiler/ , opět jsem se tomu na delphi.cz věnoval

FastMM a SamplingProfiler by měl být podporován i normální TurboVerzí, jak je to s tou neplacenou nevím.
Embarcadero MVP - Czech republic

frankee_

  • Host
Re:ladění v Turbo Delphi
« Odpověď #3 kdy: 21-06-2012, 11:18:00 »
tak mi to vyhodilo toto,
da se s tim neco vymyslet ?


FastMM has detected an error during a free block scan operation. FastMM detected that a block has been modified after being freed.

Modified byte offsets (and lengths): 720(1), 2696(1)

The previous block size was: 2792

This block was previously allocated by thread 0x12F8, and the stack trace (return addresses) at the time was:
402F12 [system.pas][System][@GetMem][2648]
4043FF [system.pas][System][TObject.NewInstance][8824]
404786 [system.pas][System][@ClassCreate][9489]
4B1139 [radio.pas][radio][TRadio.Create]
4B62B9 [radio_list.pas][radio_list][InicializaceRadioListu][178]
4CB272 [astra_main.pas][astra_main][TForm1.FormCreate][1418]
4707B3 [Forms.pas][Forms][TCustomForm.DoCreate][2756]
4703FB [Forms.pas][Forms][TCustomForm.AfterConstruction][2680]
4047F4 [system.pas][System][@AfterConstruction][9537]
4703C7 [Forms.pas][Forms][TCustomForm.Create][2676]
764762FA [Unknown function at gapfnScSendMessage]

The block was previously used for an object of class: TRadio

The allocation number was: 5791

The block was previously freed by thread 0x12F8, and the stack trace (return addresses) at the time was:
402F2E [system.pas][System][@FreeMem][2693]
40441D [system.pas][System][TObject.FreeInstance][8830]
4047D1 [system.pas][System][@ClassDestroy][9530]
463D67 [Controls.pas][Controls][TCustomControl.Destroy][10010]
404463 [system.pas][System][TObject.Free][8849]
4CB4F9 [astra_main.pas][astra_main][TForm1.FormDestroy][1476]
47082F [Forms.pas][Forms][TCustomForm.DoDestroy][2768]
470676 [Forms.pas][Forms][TCustomForm.BeforeDestruction][2730]
404830 [system.pas][System][@BeforeDestruction][9565]
470687 [Forms.pas][Forms][TCustomForm.Destroy][2734]
423AAD [classes.pas][Classes][TComponent.DestroyComponents][10453]

The current thread ID is 0x12F8, and the stack trace (return addresses) leading to this error is:
40C99E [FastMM4.pas][FastMM4][FinalizeMemoryManager][11077]
40CA0E [FastMM4.pas][FastMM4][Finalization][11167]
404F53 [system.pas][System][FinalizeUnits][11273]
4051EB [system.pas][System][@Halt0][11943]
4D0C5E
7549339A [BaseThreadInitThunk]
77619EF2 [Unknown function at RtlInitializeExceptionChain]
77619EC5 [Unknown function at RtlInitializeExceptionChain]

Current memory dump of 256 bytes starting at pointer address 7EF3F6B0:
10 AE 4D 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
.  ®  M  .  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2349
  • Karma: 102
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
Re:ladění v Turbo Delphi
« Odpověď #4 kdy: 21-06-2012, 11:23:36 »
No objekt byl uz predtim uvolnen v destruktoru astra_main.
A pak se k nemu snazis pristupovat (FastMM detected that a block has been modified after being freed) .
Objekt je TRadio.
Embarcadero MVP - Czech republic

frankee_

  • Host
Re:ladění v Turbo Delphi
« Odpověď #5 kdy: 21-06-2012, 12:55:17 »
diky,
to teda nebylo ono, tohle je pouze drobnost..
uvolnoval jsem ten objekt a on se uvolnil sam,
protoze mel nastaveny owner.

Petr

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2349
  • Karma: 102
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
Re:ladění v Turbo Delphi
« Odpověď #6 kdy: 21-06-2012, 13:32:42 »
Jo objekt byl uvolnen v destruktoru formulare, protoze tam se uvolnuji komponenty, ktere maji Ownera formular.
Embarcadero MVP - Czech republic

.

  • Host
Re:ladění v Turbo Delphi
« Odpověď #7 kdy: 21-06-2012, 22:11:34 »
... já ještě nedávno používal MemProof. Ale ten už je přece jenom staršího data (memory leaky ale detekoval výborně).

Offline Vrtule

  • Mladík
  • **
  • Příspěvků: 54
  • Karma: 10
    • Verze Delphi: XE2
    • Jádro systému Windows
Re:ladění v Turbo Delphi
« Odpověď #8 kdy: 22-06-2012, 01:03:40 »
Citace
B) ví někdo jak lépe odhalovat zhroucení programu ? (používám logování výjimek do souboru, zkoušel jsem GP profiler. Ten vyhodí nějaká dvě čísla u kterých jsem ale nezjistil co znamenají. )
Pokud něco píšu pořádně, loguju na začátku a na konci každé funkce/procedury. Zaznamenávám hodnoty argumentů a návratovou hodnotu. Je ale pravda, že takový postup volím obvykle v případě programování v C/C++. Nevím totiž, jak moc nová Delphi podporují "makra", která zajišťují, že se určitý kód do programu v Release režimu nedostane (např. ASSERT, KdPrint a KdPrintEx v případě Windows Driver Kit).

Prohlížet pak x MB logů je dosti "zábavné", ale často stačí pohled na část těsně předcházející problému, aby člověk začal tušit, co je špatně.

Offline < z >

  • Administrátoři
  • Guru
  • *****
  • Příspěvků: 1127
  • Karma: 42
    • Verze Delphi: 7, 2010
Re:ladění v Turbo Delphi
« Odpověď #9 kdy: 22-06-2012, 08:53:53 »
pro takove logovani, aby to bylo jen v debug a ne v release, je tam akorat IFDEF ...

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2349
  • Karma: 102
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
Re:ladění v Turbo Delphi
« Odpověď #10 kdy: 22-06-2012, 09:22:24 »
Od Delphi XE je součástí CodeSite, což je dobrý nástroj a věnoval jsem mu menší článeček

http://delphi.cz/post/Logovani-za-pomoci-CodeSite-4.aspx

Požadovaného chování dosáhnete pokud napíšete
{$IFDEF DEBUG}
CodeSiteManager.Enabled := True; // zakaz logovani
{$ENDIF}
Embarcadero MVP - Czech republic

Offline Vrtule

  • Mladík
  • **
  • Příspěvků: 54
  • Karma: 10
    • Verze Delphi: XE2
    • Jádro systému Windows
Re:ladění v Turbo Delphi
« Odpověď #11 kdy: 22-06-2012, 13:51:51 »
Od Delphi XE je součástí CodeSite, což je dobrý nástroj a věnoval jsem mu menší článeček

http://delphi.cz/post/Logovani-za-pomoci-CodeSite-4.aspx

Požadovaného chování dosáhnete pokud napíšete
{$IFDEF DEBUG}
CodeSiteManager.Enabled := True; // zakaz logovani
{$ENDIF}

Díky za info, ten nástroj vypadá zajímavě, i když toho umí více, než obvykle potřebuju (zatím mi vždy stačilo logování do souboru a nepotřeboval jsem k tomu například prohlížet vlastnosti objektů atd.).

O {$IFDEF} vím, jen je škoda, že to nejde dělat nějak elegantněji – že prostě Delphi neumí makra jako třeba C/C++.

Offline frankee

  • Příspěvků: 16
  • Karma: 3
Re:ladění v Turbo Delphi
« Odpověď #12 kdy: 28-06-2012, 07:29:42 »
díky za všechny rady,

chybnou část kódu jsem zkusil přepsat do delphi XE, stejně to nnic neřeklo, pouze výjimka.
Nakonec jsem experimentoval s Turbo Delphi portable edicí a ta mi řekla oproti jiný edicím (nechápu),
že se jedná o Stack Overflow...

To mě nakoplo,
nainstaloval jsem všecky nástroje které jste mi poradili, ale nic důležítého jsem nezjistil.
Tak jsem se jal zjednodušovat kód až do té míry, kdy ta chyba nebude...

Naštěstí toto byl správný postup. Tímto postupem jsem zjistil, že stack ubývá tehdy když zavolám inicializaci BASS knihovny

 BASS_WASAPI_Init(-1,48000,2, flag,0.05,0.005,@PlaybackWasapiProc,nil);
 BASS_WASAPI_Start();

s callback funkcí:

function PlaybackWasapiProc( buffer: pointer; length: dword ): dword; stdcall;
begin
end;

Prostudoval jsem dokumentaci a zjistil, že hlavička  callback funkce má mít nově o parametr navíc a to takto...
function PlaybackWasapiProc(buffer:Pointer; length:DWORD; user:Pointer): DWORD; stdcall;

200x za sekundu jsem tímto přicházel o 4 bajty pointeru, což brzo způsobilo pád.


moc sice nechápu proč mi FASTMM s fulldebug mode nic neodhalil, ale jsem rád že jsem na to nakonec kápl. Problém jsem si zavinil sám, protože definici funkce jsem opsal z fóra kde autor použil starší verzi knihovny...


Petr