radikaler Absturz des Python Scripts

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 12:56

Hi zusammen,

ich hab ein Problem mit einem Script das ich geschrieben habe.

Dies stürtzt durch bisher nicht geklärte Umstände einfach nach einer unbestimmten Zeit mit folgender Fehlermeldung ab:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Das Probelm ist das es keine Exception oder Vorwarnung gibt. Ich kann also nicht feststellen wo die Ursache des Problems liegt.
Der einzige Anhaltspunkt ist die Auslastung des Speichers im Taskmanager. Wenn dort die Speichenutzung des Scripts so um die 200MB liegt dann knallts.

Ich hab leider keine Ahnung wo ich suchen soll.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Freitag 7. März 2008, 13:01

schonmal in der Konsole gestartet und den Output angeschaut?

:roll:
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Freitag 7. März 2008, 13:03

Hallo und willkommen im Forum,

big_earl, so wird Dir niemand helfen können. Du erzählst uns ja noch nicht einmal um welche Anwendung es überhaupt geht, bzw. was der Pythoncode ist, der ggf. zum Absturz führt.
Wenn es eine closed-source Anwendung ist wirst Du wohl u. U. nicht drumhin kommen dem Ratschlag der Fehlermeldung folgen und beim support um Info fragen. Aber erst einmal: Magst Du uns nicht mehr erzählen, damit wir probieren können Dir zu helfen?

Gruß,
Christian
BlackJack

Freitag 7. März 2008, 13:08

Informationen zu Zusatzbibliotheken wäre hilfreich. Solche harten Abstürze kommen in der Regel nicht aus Python-Code, sondern aus Modulen die in C programmiert sind, wobei die in der Standardbibliothek recht gut getestet sind.
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 14:14

By the way: Danke für die Wilkommensgrüße. Hab das ja noch in keinem Forum so erlebt. :)

Kann nur begrenzt ne Aussage machen zu dem Code weil´s wirklich CS ist.

Aber soweit, es geht um die Abbarbeitung von XML-Dateien. Die Struktur wird mit der Satine Bib. geladen und dann darauf ausgeführt. Während der Ausführung der Daten aus dem XML wird gleichzeitig ne neue XML-Struktur aufgebaut. Die bleibt im Speicher bis alles fertig ist und dann wird das ganze auf die Platte geschireben.

Ich verwende (haltet euch fest) Python 2.2 weil´s nicht anders geht. Is so vorgegeben. Das ganze unter Windows mit wxPython 2.3.

Ich hab Zugriff auf einige native Bibliotheken, aber da hab ich überhaupt keinen Einfluß drauf, da die zugeliefert werden.

Gibt es nicht ein Anastz, wie ich raus bekommen kann welcher Teil des Codes genau dafür sorgt das der Process abschmiert?
Debuggen hilft ja nicht, da es keine Exception gibt und das Problem ist das ich nicht den ganzen Code durchlaufen lassen kann bis es Kracht. Das sind zwischen 100 und 200 Durchläufe ungefähr.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Freitag 7. März 2008, 15:00

Wenn das auf Windows läuft....
Packe eine Version mit Python2.5 in einen Ordner, mit Py2exe.
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 15:06

Und dann?
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Freitag 7. März 2008, 15:10

audax hat geschrieben:Wenn das auf Windows läuft....
Packe eine Version mit Python2.5 in einen Ordner, mit Py2exe.
Ich zweifle irgendwie, daß das Verpacken einen Bug löst ...

Aber, big_earl, Du hast uns immer noch nicht verraten, was Du eigentlich für ein Modul nutzt, nur das es wxPython nutzt. Und Du sprachst von einem eigenen Skript, ausgeschlossen, daß Du mit dem den Fehler triggerst? Kannst Du den Code vielleicht so zusammendampfen, daß der Fehler schneller provoziert wird? Und was ist mit BJs Frage?

Wenn Du hier nicht frustriert rausgehen willst, mußt Du schon etwas freigiebiger mit relevanter Info sein.

Gruß,
Christian
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 15:27

Ich bin mir nicht sicher ob es euch hilft wenn ich sage das es von DSpace kommt.

Ich kann nicht ausschließen das ich den Fehler produziere. Ich gehe sogar davon aus. Das Problem ist nur das ich keinen Hinweis bekomme woher der kommt. Könnte ja sein das es was mit dem Garbage Collector zutun hat oder sonst was. Keine Ahnung.

Das Script läuft ne ganze Zeit super und auf einmal is es weg. Dann seh ich nur noch die Meldung von oben.

Ist eine Anwendung die mehrere Klassen hat insgesamt 26 modul-Dateien mit meistens einer aber manchmal auch mehr Klassen.
Der Teil der die XML Struktur von oben nach unten durchgeht läuft in einem eigenen Thread.

Das sind nur die Imports aus der Klasse die die Hauptarbeit erledigt Viele Imports sind von mir selbst aus anderen Modulen:

Code: Alles auswählen

from ConditionHandler import *
from TeststepHandler import *
from Timing import RealTimeError
from Timing import TimingObserver
from controller import *
from controller.hilcontrol.CalDesk import CalDesk
from controller.hilcontrol.ControlDesk import ControlDesk
from controller.hilcontrol.CanController import CanController
from controller.reporter import XMLReporter
from controller.scheduler import SendReceive
from time import *                   
from win32api import Sleep
import satine
import string
Was an externen Bib. dazukommt führ ich mal insgesamt auf ohne Struktur wo sie importtiert werden:

Code: Alles auswählen

import os
from time import sleep
import manmcdlib
from cdautomationlib import *
from controller import Logger
from controller import ProcessHelper
from sdmlib import *
from time import sleep
import cdacon
import controller
import dSPACEDemoUtilities
import manmcdlib
import os
import pythoncom
import rtplib
from xml.dom.minidom import getDOMImplementation
from     threading    import *              
import   pythoncom
from threading import *              
from time import *
from win32api import Sleep
import os
import pythoncom
import satine
import thread
Hoffe das euch das weiter hilft :?

Ich habe mich bisher darauf verlassen das der Garbage Collector alles aufräumt was nicht mehr benötigt wird. Bin mir aber dessen nicht sicher. Vieleicht habe ich da ein Problem mit Objekten die nicht mehr gebraucht werden und dann ein Problem verursachen.

Was ich eigentlich suche ist ein Weg herauszubekommen was genau den Fehler produziert zu dem Zeitpunkt wenn er auftritt. Es muß doch ne Möglichkeit geben zu sehen was da hinter den Kulissen passiert. Mir ist die Meldung "Contact Support Team..." einfach zu dürftig um den Fehler einzugrenzen.

Ich bin das Supportteam! lol :oops:
Zuletzt geändert von big_earl am Freitag 7. März 2008, 15:40, insgesamt 1-mal geändert.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Freitag 7. März 2008, 15:38

Sternchenimporte....die Wurzel allen Übels :D

Kurz:
Räum doch mal die Imports auf...da ist auch einiges doppelt und so. Und es wird Sleep aus der win32-api und zweimal sleep aus time importiert.. Oo
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 16:01

audax hat geschrieben: Kurz:
Räum doch mal die Imports auf...da ist auch einiges doppelt und so. Und es wird Sleep aus der win32-api und zweimal sleep aus time importiert.. Oo
Wie gesagt, ich habs ja auch nur untereinanderweg rein kopiert. Die sind nicht alle aus dem gleichen Modul.

Wenn ich aber in inem Modul time brauch und in einem anderen auch, dann muß ich das wohl dort importieren wo ich es benötige.
Zuletzt geändert von big_earl am Freitag 7. März 2008, 16:04, insgesamt 1-mal geändert.
BlackJack

Freitag 7. März 2008, 16:04

Der Garbage-Collector gibt nur dann Objekte wieder frei, wenn sie nicht mehr durch irgendeine Referenz erreichbar sind. Das ist unabhängig davon, ob Du sie noch brauchst. Soll heissen, es kann durchaus passieren, dass Objekte noch leben, die Du eigentlich nicht mehr bräuchtest. Dagegen hilft allgemein saubere Programmierung und in schweren Fällen von zyklischen Verweisen das `weakref`-Modul.

Tritt der Absturz bei gleichen Daten immer an der gleichen Stelle auf? Falls nicht, könnte man vermuten, dass die C-Module die dabei verwendet werden, nicht "thread safe" sind.

Ansonsten müsste man das Problem versuchen zu isolieren. `logging` in das Programm einbauen um besser eingrenzen zu können wo/wann das Problem zuschlägt, Teile des Programms gegen "Mock-ups" laufen lassen etc.
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Freitag 7. März 2008, 16:21

Ich habe mal den Garbage Collector gezwungen aufzuräumen und gleichzeitig auch angezeigt ob es zyklische Referenzen gibt die nicht gelöscht werden können.
First we set up the gc module to help us debug the leak. The DEBUG_LEAK flag causes it to print information about objects which cannot be seen other than through the reference the garbage collector has to them.
(http://www.oreillynet.com/onlamp/blog/2 ... akref.html)

Es gab aber keine. Sprich der Garbage Collector hat also nichts zu tun. Es scheint so als wäre das nicht das Problem.

BlackJack hat geschrieben: Tritt der Absturz bei gleichen Daten immer an der gleichen Stelle auf? Falls nicht, könnte man vermuten, dass die C-Module die dabei verwendet werden, nicht "thread safe" sind.
Das kommt drauf an, wenn ich immer von vorne starte ist es an der selben stelle. Wenn ich aber im XML weiter hinten starte und über diese STelle drüber komme passiert nichts. Erst wieder nach längerem Durchlaufen des Scripts.

Hab mal die Speicherauslastung aufgezeichnet bis es abstürzt.
Bild[/url][/quote]
big_earl
User
Beiträge: 12
Registriert: Freitag 7. März 2008, 12:51

Montag 10. März 2008, 13:03

Für alle die es interessiert.

Ich hab die Lösung des Problems gefunden.

Die von mir verwendete Bibliothek "satine" hat bei den aufgeführten Befehlen ein Problem verursacht.

Code: Alles auswählen

teststepcount = teststepcount + len(item.query(".<preparation><statecheck>|"))
teststepcount = teststepcount + len(item.query(".<preparation><statechange>|"))
teststepcount = teststepcount + len(item.query(".<preparation><requestresponse>|"))
teststepcount = teststepcount + len(item.query(".<preparation><wait>|"))
teststepcount = teststepcount + len(item.query(".<preparation><diagservicecheck>|"))
teststepcount = teststepcount + len(item.query(".<preparation><disablecanmsg>|"))
teststepcount = teststepcount + len(item.query(".<preparation><enablecanmsg>|"))
teststepcount = teststepcount + len(item.query(".<preparation><disablelinmsg>|"))
teststepcount = teststepcount + len(item.query(".<preparation><enablelinmsg>|"))
teststepcount = teststepcount + len(item.query(".<preparation><testerconfirmation>|"))
teststepcount = teststepcount + len(item.query(".<preparation><initialize>|"))
Zum einen wurde dadurch die Speicherauslastung extrem vergrößert. Und zum anderen ist irgendwann ein Problem aufgetreten das die Bibliothek nicht handeln konnte und ist dabei abgeschmiert.

Schade eigentlich, das da keiner mehr dran weiter entwickelt. Ist eigentlich ne ziemlich geniale Sache. Naja, vieleicht tut sich da ja nochmal was.

Für die, die es interessiert. Hier ist der Link:

http://satine.sourceforge.net/


@BlackJack: Danke, das mit dem Mock-Ups hat geholfen ;)
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Montag 10. März 2008, 13:45

Ach dü meine Güte, was für Code /o\

Benutz lieber lxml.etree für XML-Kram. Das ist robust, schnell und ungalublich bequem!
Antworten