2009-11-23 15 views
6

Devo eseguire un sito Web Zope2 legacy e avere qualche risentimento con esso. Il problema più grande è che, occasionalmente, si blocca solo, con il 100% di carico della CPU e non risponde più alle richieste. Sebbene il problema non sia riproducibile su base regolare, una pagina contenente 3 grafici dinamici lo fa scattare a volte, quindi sospetto una qualche condizione di competizione che porti ad un loop infinito o ad una busywait bloccata.Ottieni stacktrace dal processo python bloccato

Il problema è che non ho ancora trovato un modo per eseguire il debug di questa cosa. Non c'è nulla nei log di Zope e nulla nei log di sistema. Ho provato i suggerimenti da this question per ottenere uno stacktrace, ma l'unico segnale che ha effetto è SIGKILL.

C'è un'altra possibilità di scoprire dove si trova esattamente il processo quando si blocca?

risposta

0

Se il processo è bloccato in modo che nessun altro segnale passi attraverso, si potrebbe prendere in considerazione l'esecuzione da un debugger, invece di provare a collegarsi ad esso in fase di esecuzione.

Inoltre, potrebbe essere utile ad altre tattiche di debug, come la disattivazione di alcune parti del codice per scoprire il caso minimo in cui è ancora riproducibile per vedere quali sono le cause migliori.

1

Si potrebbe provare a collegare un debugger al processo in esecuzione. Vedi anche this question.

2

Vedere la risposta a this SO question, utilizzare Products.signalstack. Registra lo stesso gestore della risposta che hai già trovato, al momento della registrazione del prodotto. Forse funziona meglio per te.

In caso contrario, probabilmente hai un problema di I/O a livello di sistema operativo e l'unica speranza è allegare gdb al processo. Overflow dello stack di ricerca per le risposte gdb; c'è una ricchezza di informazioni qui!

+1

+1 Anche ** pstack ** e ** lsstack ** potrebbero essere di qualche utilità. –

0

dopo aver girato in Internet in cerchio per un po ', finalmente sono finito qui: http://podoliaka.org/2016/04/10/debugging-cpython-gdb/ - descrive in dettaglio come tutti i pezzi combaciano. la citazione di denaro per me era 'gdb /usr/bin/python -p $ PID' - il nome dell'eseguibile è richiesto affinché gdb trovi i file di informazioni di debug corretti.

2

È possibile stampare una bella traccia di stack utilizzando pyrasite.

Prima di tutto, è necessario aver installato gdb.

# Redhat, CentOS, etc 
$ yum install gdb 

# Ubuntu, Debian, etc 
$ apt-get update && apt-get install gdb 

Quindi, installare pyrasite.

$ pip install pyrasite 

Usa ps o qualche altro metodo per trovare l'ID di processo per il processo di pitone bloccato e correre pyrasite-shell con esso.

# Assuming process ID is 12345 
$ pyrasite-shell 12345 

Ora dovresti vedere un REPL python. Eseguire il seguente comando in REPL per vedere le tracce dello stack per tutti i thread.

import sys, traceback 
for thread_id, frame in sys._current_frames().items(): 
    print 'Stack for thread {}'.format(thread_id) 
    traceback.print_stack(frame) 
    print ''