Chyba aplikace po kliknutí na "Hot Paths"

ufoun · Post by **ufoun** » 05 May 2007, 13:53

AS 2.5 RC3 i 2.5

Často se mi stavá, že AS spadne když kliknu na nějaký "odkaz" v tomhle panelu. AS mám zapnutý "nonstop" a třeba po hodině "nic nedělaní", po kliknutí spadne s hláškou co je příloze na screenu. Žadný chybový soubor není vygenerován.

Win XP SP2
TortoiseSVN

Post by **Jan Rysavy** » 05 May 2007, 14:51

Pravděpodobně stejný problém jako http://forum.altap.cz/viewtopic.php?t=1952

Příčinou by mohl být TortoiseSVN, protože používá knihovnu MSVCR80.DLL, zatímco Salamander ne.

Máte nainstalovanou aktuální verzi TortoiseSVN? (momentálně je to TortoiseSVN 1.4.3)
Pokud již máte verzi 1.4.3, stálo by za pokus otestovat nightly build, protože mám dojem, že nedávno vychytali padání ve Windows Vista.

Co by nám pravděpodobně pomohlo, by byl call stack v době pádu. Předpokládám, že máte nainstalovaný debugger?
Mohl byste prosím po pádu kliknout na tlačítko "Ladění", nafotit call stack (nebo nakopírovat do schránky) a vložit ho sem?

Chybové hlášení od Salamandera není vygenerováno ze dvou možných příčin:
1. je porušený stack a nefunguje exception handling, takže pád nezachytíme
2. k pádu dochází v cizím vlákně (kde Salamander nemá exception handler); tuto možnost autor Tortoise SVN vyloučil

ufoun · Post by **ufoun** » 05 May 2007, 17:06

Tortoise pouzivam ve verzi 1.3.5, Build 6804 - 32 Bit. Zkusim tedy aktualizovat na novou verzi. A az mi AS zase spadne, tak sem zkusim dat vice informaci.

ufoun · Post by **ufoun** » 06 May 2007, 18:48

Tak mi ted prave spadl AS...

Klikl jsem tedy na tlacitko "ladeni".. otevrel se builder s oknem co je v priloze. Mam to tu stale zaple, mohl byste me pls nevest co presne vam mam nakopirovat?

Post by **Jan Rysavy** » 07 May 2007, 05:58

Takže padá i verze 1.4.3. Mohl byste ještě přejít na aktuální nightly build? Podle konference autor opravuje chyby prakticky každý den, tak abychom neladili vyřešený problém.

Pokud jde o call stack, mělo by to vypadat jako okénko v příloze. Bohužel neznám Builder, takže nedokážu přesně navést, jak se okno vyvolá. Podstatné je, že v tomto okně vidíme sekvenci, jaké moduly se postupně volaly (včetně adres) a kde vlastně k pádů došlo.

Ještě by byla zajímavá informace odrolovat v hlavním okně z (Vaší fotky) nahoru a podívat se, v jaké funkci k pádu došlo. Jde o první nápis shodný s ntdll.DllUserBreakPoint, ale ležící nad místem pádu.

Mimochodem, ten předchozí pád měl pravděpodobně jiné úvodní hlášky o pádu? Vypadá to, že to spadlo v NTDLL místo MSVCR80. Nemáte náhodou ty úvodní hlášky také nafocené?

Post by **zarevak** » 07 May 2007, 16:01

Jan Rysavy wrote:Ještě by byla zajímavá informace odrolovat v hlavním okně z (Vaší fotky) nahoru a podívat se, v jaké funkci k pádu došlo. Jde o první nápis shodný s ntdll.DllUserBreakPoint, ale ležící nad místem pádu.

Toto není místo pádu, ale následek Debugování. Nad funkcí ntdll.DbgUserBreakPoint leží na adrese 0x7C901230 začátek funkce ntdll.DbgBreakPoint (Windows XP SP2)

Post by **Jan Rysavy** » 07 May 2007, 18:15

Aha, možná je to slepá cesta, Visual C++ debugger v tomto případě dokáže zobrazit správný kontext, tedy místo pádu. Je možné, že díky chybě v shell extension došlo k naprostému porušení zásobníku a zkrátka není co ukazovat.

Další problém s TortoiseSVN je v anglickém vlákně:
http://forum.altap.cz/viewtopic.php?t=2096

Máte někdo nápad jak dále postupovat? Možná by pomohlo nainstalovat PDB soubory, jak popisuje autor TortoiseSVN:
http://article.gmane.org/gmane.comp.ver ... evel/28888

Netuším, zda Builder umí s PDB pracovat? Ale asi bez potíží by šel nainstalovat MS Windows Debugger, viz:
http://forum.altap.cz/viewtopic.php?p=8854#8854

Post by **manison** » 07 May 2007, 19:57

Pokud vím, tak Builder s PDB soubory pracovat neumí (alespoň ještě před pár lety neuměl). MS debugger je výborný nástroj, ale pro běžné uživatele (ponechme nyní stranou termín "běžný uživatel AS"

) poměrně složitě použitelný.

Myslím, že v mnoha případech postačí i logy z Dr. Watsona, který je výchozím debuggerem při instalaci Windows. Většinou je hlavním vodítkem call stack, příp. seznam modulů. Obojí je ve výpisu z Watsona obsaženo.

V tuhle chvíli by mě spíš zajímalo, jaktože Salamander spadne bez zobrazení vlastního bug report okna. Ukazuje se, že po zavedení icon overlays se Salamander stává v některých případech ne vlastní vinou nestabilní, a těchto případů bude pravděpodobně přibývat. Pokud Salamander nainstaluje globální filtr neošetřených výjimek, tak by měl být schopný (téměř) vždy spadnout "elegantně". Pokud to lze z povahy výjimky zjistit, může uživateli sdělit, která shell extension problém způsobila a nabídnout její další nenahrávání.

Pro představu ještě uvádím část záznamu z Dr. Watsona (při havárii je třeba klepnout na tlačítko Ladění a Watson vygeneruje záznam do souboru C:\Documents and Settings\All Users\Data aplikací\Microsoft\Dr Watson\drwtsn32.log):

Code: Select all

Nastala výjimka aplikace:
        Aplikace: E:\tests\bugmaker\Debug\bugmaker.exe (pid=1224)
        Kdy: 7.5.2007 v 19:04:52.722
        Číslo výjimky: c0000005 (narušení přístupu)

*----> Seznam modulů <----*
(0000000000400000 - 000000000042b000: E:\tests\bugmaker\Debug\bugmaker.exe
(0000000062ef0000 - 0000000062ef9000: C:\WINDOWS\system32\LPK.DLL
(0000000075550000 - 00000000755bb000: C:\WINDOWS\system32\USP10.dll
(0000000076370000 - 000000007638d000: C:\WINDOWS\system32\IMM32.DLL
(0000000077b30000 - 0000000077b52000: C:\WINDOWS\system32\Apphelp.dll
(0000000077bf0000 - 0000000077bf8000: C:\WINDOWS\system32\VERSION.dll
(0000000077c00000 - 0000000077c58000: C:\WINDOWS\system32\msvcrt.dll
(0000000077dc0000 - 0000000077e6b000: C:\WINDOWS\system32\ADVAPI32.dll
(0000000077e70000 - 0000000077f01000: C:\WINDOWS\system32\RPCRT4.dll
(0000000077f10000 - 0000000077f57000: C:\WINDOWS\system32\GDI32.dll
(0000000077f60000 - 0000000077fd6000: C:\WINDOWS\system32\SHLWAPI.dll
(000000007c800000 - 000000007c8f4000: C:\WINDOWS\system32\kernel32.dll
(000000007c900000 - 000000007c9af000: C:\WINDOWS\system32\ntdll.dll
(000000007e360000 - 000000007e3f0000: C:\WINDOWS\system32\USER32.dll

*----> Výpis stavu podprocesu ID 0x6c8 <----*

eax=00000000 ebx=7ffdf000 ecx=00000000 edx=00000001 esi=00360037 edi=0012fe08
eip=00411a28 esp=0012fd30 ebp=0012fe08 iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216

*** WARNING: Unable to verify checksum for E:\tests\bugmaker\Debug\bugmaker.exe
funkce: bugmaker!MakeGPF
        00411a07 0000             add     [eax],al
        00411a09 53               push    ebx
        00411a0a 56               push    esi
        00411a0b 57               push    edi
        00411a0c 8dbd34ffffff     lea     edi,[ebp-0xcc]
        00411a12 b933000000       mov     ecx,0x33
        00411a17 b8cccccccc       mov     eax,0xcccccccc
        00411a1c f3ab             rep     stosd
        00411a1e c745f800000000   mov     dword ptr [ebp-0x8],0x0
        00411a25 8b45f8           mov     eax,[ebp-0x8]
CHYBA ->00411a28 c70003000000     mov   dword ptr [eax],0x3 ds:0023:00000000=????????
        00411a2e 5f               pop     edi
        00411a2f 5e               pop     esi
        00411a30 5b               pop     ebx
        00411a31 8be5             mov     esp,ebp
        00411a33 5d               pop     ebp
        00411a34 c3               ret
        00411a35 cc               int     3
        00411a36 cc               int     3
        00411a37 cc               int     3
        00411a38 cc               int     3

*----> Zpětné trasování zásobníku <----*
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr  Args to Child              
0012fe08 00411cc3 00320036 00360037 7ffdf000 bugmaker!MakeGPF+0x28
0012fedc 00411c20 00000001 00370eb0 00370f10 bugmaker!main+0x23
0012ffc0 7c816fd7 00320036 00360037 7ffdf000 bugmaker!mainCRTStartup+0x170
0012fff0 00000000 0041132f 00000000 78746341 kernel32!RegisterWaitForInputIdle+0x49

ufoun · Post by **ufoun** » 07 May 2007, 20:45

Ad Dr Watson: On je tu problem, ze na to ladeni jsem klikl a zapina se mi builder a tam je porad totez (viz priloha vys) a kdyz jsem se ted podival na ten log tak tam je, ale je pres rok stary. Z toho usuzuju, ze aby Dr watson udelal nejaky log tak bych mel bud buildera odinstalovat a nebo "pro ladeni priradit zpet" Dr Watsona...

Ale nainstaloval jsem ten debugger od MS (snad to pomuze) a i NB TortoiseSVN (TortoiseSVN 1.4.3, Build 9342 - 32 Bit -dev, 2007/05/06 10:53:01) a ted cekam na nejaky ten pad... Jeste nez jsem mel debbuger od MS, tak mi AS spadl i s NB Tortoise - stejna chyba jako drive (screen prilozen, ale moc toho tam neni).

Post by **Jan Rysavy** » 07 May 2007, 20:46

manison wrote:Pokud Salamander nainstaluje globální filtr neošetřených výjimek, tak by měl být schopný (téměř) vždy spadnout "elegantně".

Co máte přesně na mysli tím globálním filtrem? Momentálně celý systém zachytávání výjimek stojí na dvou předpokladech:

1. každé vlákno musí být ošetřeno handlerem
(pokud shell extension vytvoří vlastní vlákno, ve kterém dojde k výjimce, ta propadne do standardního handleru, zobrazí se std. okénko a zavolá exitprocess, takže se Salamander nedostane ke slovu)

2. zásobník je OK
(pokud shell extension převálcuje stack, selže celý mechanismus výjimek, protože ten je na stacku vybudovaný)

Existují další možnosti zachycení výjimek (globální pro proces, pro všechna jeho vlákna)? Pokud jsem napsal nějaké nepřesnosti, tak mě prosím opravte, v této problematice nejsem úplně doma.

Post by **manison** » 07 May 2007, 21:06

Existují další možnosti zachycení výjimek (globální pro proces, pro všechna jeho vlákna)? Pokud jsem napsal nějaké nepřesnosti, tak mě prosím opravte, v této problematice nejsem úplně doma.

Mrkněte na funkci SetUnhandledExceptionFilter. Tou je možné nainstalovat pro celý proces callback funkci, která bude volaná v případě jakékoliv neošetřené výjimky. Tím se dají ošetřit výjimky i ve vláknech, která nemáte pod kontrolou (shell extensions). Protože je ale callback volaný v kontextu vlákna, kde vznikla výjimka, může nastat problém se zásobníkem, který popisujete v bodu 2.

Teď jsem se ještě díval, jak je to udělané v Breakpadu (takový multiplatformní Watson) a tam spouští obsluhu výjimky v samostatném vlákně.

Post by **manison** » 07 May 2007, 21:22

ufoun wrote:Ad Dr Watson: On je tu problem, ze na to ladeni jsem klikl a zapina se mi builder a tam je porad totez (viz priloha vys) a kdyz jsem se ted podival na ten log tak tam je, ale je pres rok stary. Z toho usuzuju, ze aby Dr watson udelal nejaky log tak bych mel bud buildera odinstalovat a nebo "pro ladeni priradit zpet" Dr Watsona...

Zkuste dočasně "odinstalovat" Borlandí JIT debugger následujícím způsobem:
1. Zazálohujte si větev registru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug.
2. Nastavte hodnotu Debugger v tomto podklíči na drwtsn32 -p %ld -e %ld -g.
3. Čekejte na pád

4. Hoďte sem log z Watsona a obnovte si nastavení v registru.

Post by **Jan Rysavy** » 07 May 2007, 23:34

manison wrote:Mrkněte na funkci SetUnhandledExceptionFilter.

To vypadá velmi dobře, děkujeme! Implementovali jsme bug report systém někdy v roce 1999, možná 2000 a zjevně by si zasloužil oprášit. Tuto funkci jsme museli přehlédnout. Pády v chybných shell extensions (často s přepisem stacku) jsou dlouhodobě největším zdrojem problémů.

Post by **zarevak** » 08 May 2007, 00:01

Jan Rysavy wrote:Pády v chybných shell extensions (často s přepisem stacku) jsou dlouhodobě největším zdrojem problémů.

Tento problém řešil i Microsoft ve svém Windows Exploreru - nakonec to skončilo pomocnou utilitou verclsid.exe, která před načtením Shell Extension provede několik základních testů a až poté umožní její načtení do Exploreru... Tímto základním testem však pravděpodobně většina Shell Extension projde a spadne až po nějaké době úspešného běhu

Idea: Šlo by Shell Extension hostovat v oddělené aplikaci a se Salamanderem komunikovat nějakým bezpečným způsoběm? Při pádu by to pak odnesla jen dotčená pomocná aplikace a Salamander by zůstal hrdě stát

Použití Blacklistů a Whitelistů mi přijde vzhledem k rychlosti vydávání nových verzí Shell Extension dosti nepoužitelné...

Post by **manison** » 08 May 2007, 01:43

zarevak wrote:Idea: Šlo by Shell Extension hostovat v oddělené aplikaci a se Salamanderem komunikovat nějakým bezpečným způsoběm?

Určitě by šlo, nic není nemožné

Zpátky k původnímu problému. Výjimka 0xC000000D je STATUS_INVALID_PARAMETER. Na adrese 0x78138890 se v msvcr80.dll nachází volání UnhandledExceptionFilter, která se volá v rámci funkce _invoke_watson (invarg.c). Tahle funkce je součástí mechanizmu validace parametrů v CRT Visual C++ 2005/8. Zjednodušeně řečeno, pokud voláte funkci z CRT a předáte ji neplatný parametr, je vyvolána výjimka STATUS_INVALID_PARAMETER a následně je aplikace ukončena. Teď už "jen" zjistit z logu Watsona, které funkci se předávají špatné parametry a informovat o tom autory TortoiseSVN.

Uživatel scheruga má s nejvyšší pravděpodobností stejný problém.