MorphXT stürzt beim Beenden von DLs ab->pure virtual call

$Acid$ · 13. June 2004, 18:52

Hi!

ich hab seit einigen Wochen ein ganz mysteriöses Problem:

Ich verwende Morph XT 3.2. Mit den Downloadergebnissen bin ich trotz DSL Light mehr als zufrieden, aber wenn ein Download fertig wird, passiert folgendes: Manche Downloads werden ganz normal beendet. Andere aber bleiben bei 100% mit der Meldung "nicht genügend Festplattenspeicher" stehen. Auf meiner Download Partition sind momentan aber noch 37 Gig frei ?!? Bei den Einstellungen ist kein Haken gesetzt, dass er des Platz überwachen soll.

Bisher habe ich dieses Problem umgangen, indem ich mir von den fertigen Dateien die Nummer der .met rausgesucht hab, diese rauskopiert und umbenannt habe. Im Log sieht das Ganze dann so aus

13.06.2004 21:07:53: Unerwarteter Dateifehler beim Fertigstellen von X. Datei wird pausiert; starten Sie eMule neu, um das Fertigstellen erneut zu versuchen - "X": Invalid argument

Jetzt muss ich dabei aber einen Fehler gemacht haben. Emule bringt mir jetzt beim Neustart für jeden nicht beendeten Download folgendes Fenster:

_____________________________
Microsoft Visual C++ Runtime Library
Runtime Error!
R6025
-pure virtual function call
_____________________________

Kurze zeit später kommt dann ein Speicheradressierungsfehler und das wars dann. Ich dachte, es könnte an der preferences.ini liegen. Ich habs mal ohne ini versucht, aber leider ohne Erfolg.

Was kann das sein? Meine Hardware funktioniert 1a. Mit dem aktuellen Sivka Mod und dem MorphXT Emule Ordner konnte ich dieses Problem auch nachvollziehen. Kein Plan, was das ist

NACHTRAG:

als Morph Fan hab ich zum Glück alle älteren Versionen noch auf der Platte. Ich habe mich jetzt von der 3.2 bis zur 2.6 an den Abstürzen beim Beenden vorbei gekämpft und auf einmal werden die Downloads beendet ?!?!? Die Einstellungen zwischen 2.6 und 3.2 sind übrigens unverändert. Ich habe meine optimalen Einstellungen und an denen wird nichts mehr verändert. Der Config Ordner wird von Version zu Version mitgenommen.

Es scheint also, als sei bei mir in allen Morph Versionen nach der 2.6 (42e) der Wurm (Bug?) drin!

fakeraol · 13. June 2004, 23:35

ich hab in der 2.6 oder 3.0 mal downloads importiert.
jetzt hab ich mal mit edwatch nachgeschaut und festgestellt, das immer zwei files zusammen das gleiche part-file genutzt haben. eins davon war immer pausiert (zufällig?).

ich hab mich auch gewundert, das einige files, die kurz vor der vollendung standen, plötzlich verschwunden waren.
die sind mit sivka wieder sichbar geworden. wurden einfach pausiert, als sie komplett waren, statt sie zu beenden.
ich musste sie dann von hand umbenennen und ins incoming verschieben.

als ich jetzt auf die 3.2 umsteigen wollte, hatte ich genau den fehler, allerdings mit sofortigem absturz.

da ich im moment ein super schwer zu bekommendes file sauge (seit 26.03. 354 von 501 mb), ist sowas nicht so prikelnd.

ich würd mich auch riesig drüber freuen, wenn das "sources handling" vom sivka in den morph eingebaut werden würde.

**Pathfinder** · 14. June 2004, 10:26

Zitat:

Zitat von $Acid$

Die Einstellungen zwischen 2.6 und 3.2 sind übrigens unverändert. Ich habe meine optimalen Einstellungen und an denen wird nichts mehr verändert. Der Config Ordner wird von Version zu Version mitgenommen.

Es scheint also, als sei bei mir in allen Morph Versionen nach der 2.6 (42e) der Wurm (Bug?) drin!

Vielleicht ist der "Wurm" ja auch in deinem Config-Ordner, den der war, deiner Aussage nach, auch bei allen Tests gleich. Hast du mal eine neue Installation versucht, bei der du nur den alten Temp-Ordner eingestellt hast? Auch dein Temp-Ordner kann duch das viele "Herumkopieren" einen Schlag weg haben. Um sicherzugehen solltest du einen neuen Temp-Ordner anlegen lassen und die Datei-Paare Stück für Stück übernehmen.

$Acid$ · 14. June 2004, 13:33

@ Pathfinder

Ich habe es grad so getestet, wie Du geschrieben hattest. Leider wars erfolglos.

Eben habe ich Morph XT 3.3 in einen komplett neuen Ordner entpackt. Es wurden keine alten Dateien von anderen Mule Ordnern hinzugefügt. Den Temp Ordner habe ich jetzt auf eine andere Platte verlegt und einen 100% Kandidaten hineinkopiert. Nach dem ersten Start habe ich nur den Download- und den Temp-Pfad geändert. Beim Neustart gings wieder los. Zuerst sah es ja gut aus. Der Download wurde beendet, es stand "vollständig" da, im Transfer Fenster verschwand plötzlich der Dateiname und der übliche Speicheradressierungsfehler erschien wieder.

Nun habe ich wieder Version 2.6 gestartet. Der Download war wie erwartet noch drin und wurde problemlos beendet. Ich möchte mal wissen, wie der Mule ab 2.7 darauf kommt, dass nicht genug Platz zum Beenden wäre. Ich habe als Ausgabepfad schon verschiedene Partitionen auf verschiedenen Platten angegeben. Immer das Gleiche. Ich bin echt ratlos

Ich weiß nicht, ob es was zu sagen hat, aber die Fertigstellungs-Blockade trat bis jetzt nur bei pdf und rar auf. avi's werden ohne Probleme beendet.

Haggi20 · 14. June 2004, 17:46

Wenn du die Option deaktivierst, daß er auf freien Speicher prüfen soll, beendet er dann die Downloads?

**Pathfinder** · 14. June 2004, 17:53

Haggi20

Zitat:

Zitat von $Acid$

Bei den Einstellungen ist kein Haken gesetzt, dass er des Platz überwachen soll.

Ich denke das hat er.

$Acid$,
wenn du einen Bug im Morph-MOD im Verdacht hast, hast du mal eine frisch installierte Original-Version zum Vergleich probiert?

$Acid$ · 14. June 2004, 20:58

Auf Dein Anraten hin hab ichs grad gemacht ... und die normale 42g hat einen dieser Downloads ohne Probleme beendet. Ich geh kaputt :o

Aber was dieser "pure virtual function call" ist, weiß ich immer noch nicht. Ich hab nur oberflächliche C++ Kenntnisse. Kann mir das bitte jemand übersetzen.

Haggi20 · 14. June 2004, 21:11

Huch überlesen. *schäm*

Zum pure virtual function call hier nen Link zur Microsoft Knowledge Base.

$Acid$ · 14. June 2004, 23:08

Ahh ... danke für den Link. Wieder was gelernt

Also entsteht bei mir nach dem Neustart beim Beenden von Downloads irgendeine Exeption, die nicht ordentlich abgefangen wird und mein Morph schmiert ab.

fakeraol · 16. June 2004, 15:57

aber warum zeigen morph und sivka das gleiche verhalten? das weist doch darauf hin, dass es nicht an den mods selber liegt, sondern an irgend einem anderen fehler, dass die dateien nicht beendet werden.

$Acid$ · 16. June 2004, 19:57

Ich kann wirklich nicht sagen, woran es liegt. Der Witz ist ja, große Downloads (ISO-Archive, ISOs, Filme) werden beendet. Bei kleineren Downloads (MP3 Archive, Anwendungen, Ebooks) meint Morph "nicht genug Platz". Wenn ich dann als 2. Mule den originalen 42g nebenher starte, zeigt der mir nur die nicht mehr verwendeten, fertigen Downloads an und beendet sie. Danach beende ich den originalen Mule wieder und werfe die inzwischen beendeten Downloads beim Morph aus der Liste. Das ist doch auf Dauer keine Lösung

fakeraol · 16. June 2004, 22:39

bei mir hat er grad nen 700mb-file nicht beendet, an der grösse liegt es also anscheinend auch nicht.
und ich benutze inzwischen den sivka, weil der morph immer wieder abgestürzt ist. der beendet diese files aber auch nicht.
wobei mich das umbenennen und verschieben von hand weniger stört, als z.b. die falsche last seen complete-anzeige oder, das bei einer suche nicht die ersten 5 quellen für ein file gleich von den servern abgefragt werden.
das würde bei seltenen files enorm helfen, überhaupt quellen zu finden und vielleicht sogar rechtzeitig in ihre queue zu kommen, bevor ihre oder die eigene 24std-trennung fällig ist.

Ähnliche Themen: MorphXT stürzt beim Beenden von DLs ab->pure virtual call