Dotaz: Zmražení pythoního procesu (á la pythoní "coredump")

[limit_false]

Je nějak možné zmrazit pythoní proces a pak ho post-mortem "debugovat", podívat se na stack trace, parametry volání, lokální proměnné (vrátane nadřazených framů)? Něco podobného jako když  v C/C++ programu zavoláte abort(), ono to hodí coredump, z kterého lze zjistit nějaké informace via gdb.

Jde o tohle: na jediném stroji občas nastane podivná race condition (jinde nenastává), kterou je velmi těžké zreplikovat. Je sice možné zjistit, že nastala, zalogovat, jenže to nestačí.

Nápady k tomu jsem měl zatím jenom dva, ale žádný není ideální:

1. přeložit python s ladícími symboly, při zjištení chyby zavolat os.abort(), co vyhodí coredump, ten pak prohlédnout s gdb
2. při porušení nějaké "podmínky zmysluplnosti" se pythoní proces připojí na remote debugger, kde bude čekat až se na to člověk podívá

První možnost je příliš low-level (zjišťování jaký pythoní kód se vlastně vykonává).

Daný race-condition nastane cca 10-20 krát za den, při druhé možnosti buď člověk musí čekat nebo jich má mnoho.

Víte o nejakém jednodušším řešení?

Odpovědi

[Jan Martinek]

V podobných situacích občas může pomoct pustit interpret pythonu s parametrem -i (interactive). Když program skončí, pustí se pythonní konzole a je možné se v tom rýpat, protože všechny objekty zůstanou beze změny.

Ale to asi znáš.

[Pavel Stárek]

Tady se píše že: pdb.py can also be invoked as a script to debug other scripts. For example:

python -m pdb myscript.py

a dále se píše že:

When invoked as a script, pdb will automatically enter post-mortem debugging if the program being debugged exits abnormally. After post-mortem debugging (or after normal exit of the program), pdb will restart the program. Automatic restarting preserves pdb's state (such as breakpoints) and in most cases is more useful than quitting the debugger upon program's exit. New in version 2.4: Restarting post-mortem behavior added.

Takže by to možná mohlo pomoci, ale já jsem nikdy takhle neladil, to si radši přidám nějaký ten print navíc

[limit_false]

Tohle jde AFAIK s kazdym trocha lepsim pythonim debuggerem. Problematicky skript je spusten automaticky cronem stovky krat denne, co dela cekani na vyskyt race condition neprijemny. Zatim jsem pridal dalsi logging hlasky aby bylo aspon videt kdy chyba nastane prvne (jestli to dela C/C++ kod nebo pythoni kod).

Jinak zatim jsem zjistil, ze dumpnutni kompletniho stavu pythoniho procesu zadny nastroj nedokaze (vyjma coredump).

Po kratkem pruzkumu jsem zjistil, ze by slo naprogramovat nastroj co by to umel jako nadstavbu GDB. Nejake info:

• http://stackoverflow.com/questions/1080832/accessing-python-objects-in-a-core-dump
• http://stackoverflow.com/questions/141351/how-do-i-find-what-is-using-memory-in-a-python-process-in-a-production-system
• http://stackoverflow.com/questions/141802/how-do-i-dump-an-entire-python-process-for-later-debugging-inspection

Bohuzel je to prace tak na mesic, co nemam.

Ale nasel jsem jeste CryoPID projekt, ktery pry umi zmrazit proces. Tak to vyzkousim a uvidim.

Treti moznost by byla udelat si jednoducheho daemona , ktereho by procesy zavolaly, kdyby zjistili poruseni invariantu. Ten by je uspal (procesy by cekaly na odpoved). Daemon by se ovladal z command line, mohl by "odekmknout" uspany proces a hodit ho remote debuggeru, nechat pokracovat, atd.

Ja nejvic doufam ze CryoPID bude fungovat To by se hodilo i v jinych pripadech.