slashCAM Forum

Hallo Resolve- User,

ich arbeite seit Version 15 mit der Studio- Version von Resolve und bin damit glücklich und zufrieden gewesen. Abstürze sind selten, das System lief stabil.
Seit Anfang November hatte ich aber lästige Probleme mit meinem Resolve, was bis zur absoluten Unbrauchbarkeit führte. Kaum greife ich einen Clip, um ihn in die Timeline zu ziehen, friert Resolve ein. Wenn ich von der Media- Page zur Edit- Page wechsele, friert Resolve ein.

Solange ich in meinen letzten Projekt gearbeitet habe, trat das nur sporadisch auf. Seit einer Woche versuche ich ein neues Projekt zu erstellen, aber das ist fast unmöglich. Permanentes Einfrieren, Neustarten und wieder Einfrieren haben mich soweit frustriert, dass ich beinahe wieder das Adobe- Abo (mit Cyber-Monday-Angebot) abgeschlossen hätte :(

Ich habe Slashcam nach einem ähnlichen Problem durchsucht, aber nichts dazu gefunden.

Ich habe weiter alles mögliche versucht; Resolve komplett deinstalliert und von Version 15.0 an Version für Version neu installiert.
Ich habe vor lauter Verzweiflung mein Windows 10 neu installiert, Motherboard- Treiber und BIOS aktualisiert, nichts hat geholfen.
Dann habe ich das englische BM- Forum durchsucht, aber auch nicht gleich etwas für mein Problem hilfreiches gefunden.

Aaaaaber dann: habe ich zufällig eine kleine Anmerkung und einen Link zu einem Beitrag gefunden, der mein Problem auf einen Schlag gelöst hat:
https://forum.blackmagicdesign.com/view ... 1&t=102152

Grundsätzlich wird das Problem vom aktuellen NVIDIA- Studio- Treiber V441.x verursacht. Die Installation der letzten Version vom 4. September (V431.86) hat bei mir das Problem behoben. Die V441.xx funktionieren aktuell nicht mit BRAW.

Nun ist mir auch klar geworden, warum das alte Projekt noch ging; hier waren 70% der Clips *.mp4, 10% CDNG und nur 20% BRAW. Das aktuelle Projekt ist 100% BRAW.

Ich hoffe, ich kann mit dieser Info dem einen oder anderen hier die Verzweifelung ersparen, die ich erleiden musste, bis ich den Beitrag gefunden habe.

Erleichterte Grüße, AndySeeon

ja -- wirklich nervig an diesen problemen is vor allen dingen der umstand, dass resolve bzw. die BMD programmierer fast durchgängig keine vernünftigen fehlermeldungen einbauen, mit denen man ein bisserl gezielter nach den ursachen auftretender probleme suchen könnte. so ist man dann ständig nur auf das herumraten angewisen, od. eben auf hinweise im netz, wo andere nach langem rumprobieren irgendwann doch eine erklärung od. gar lösung für entsprechendes fehlferhalten gefunden haben.

Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?

Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.

@mash_gh4
Ein Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon (default) Fehlermeldung...nur nicht für die GUI.

roki100 hat geschrieben: ↑So 01 Dez, 2019 14:10

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?

Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.

@mash_gh4
Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon eingebaute Fehlermeldung...nur nicht für die GUI.

Wahrscheinlich ist das nicht so, aber egal.
Die Antwort könnte lauten, dass BRAW Cuda nutzt und Cuda in den Grafiktreibern integriert ist. Dort könnte der Fehler liegen. Ein Test mit OpenCL hätte vielleicht schon Abhilfe geschaffen.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?

Wenn in den Resolve- Preferences die Option "" aktiviert ist: dann wird eben die GPU für die BRAW- Verarbeitung genutzt. Diese Option kann man abwählen, dann funktioniert Resolve auch problemlos mit dem aktuellen V441.28 Treiber. Allerdings ist dann der Workflow an einigen anderen Stellen deutlich zäher. Den Unterschied spürt man vor allem, wenn man eine schnelle GraKa hat (2080Ti).

Gruß, AndySeeon

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 14:37Ein Test mit OpenCL hätte vielleicht schon Abhilfe geschaffen.

Gute Idee, darauf bin ich noch garnicht gekommen. Könnte man mal ausprobieren - aber das mache ich erst, wenn der nächste neue Studiotreiber auch nicht funktionieren sollte. Vielleicht hat jemand hier noch das Problem und kann das mal testen...

Gruß, AndySeeon

roki100 hat geschrieben: ↑So 01 Dez, 2019 14:10 Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.

das ist mal wieder ein typischer Roki - nichts verstanden, aber Verschwörungstheorien ausbrüten...

CUDA nicht, weil es muss ja auch mit AMD funktionieren, was bleibt also übrig?

Das ist höchstwahrscheinlich so bzw. DaVinci Resolve oder BRAW Player nutzt (im Hintergrund) entweder (QT) OpengGL(ES) oder OpenCL...was gibt es noch? Nichts anderes... Eine gute Idee, doch leider sind die passende (qt4/5) Library immer wieder von den proprietären Grafiktreiber Version abhängig...
Das DaVinci Resolve unter MacOS besser/stabiler funktioniert, hat sicherlich etwas damit zu tun, weil Apple die Treiber nur dann ändert wenn es tatsächlich damit Probleme gibt, also sehr selten (wenn DaVinci für macOS Compilert wird, dann kann der Nutzer davon ausgehen, dass es bei ihm genau so funktioniert wie auch bei dem Entwickler)... Das die MacOS Treiber und passende Library als veraltet gelten, kann man hier als positiv sehen, andere tun das nicht. In der 3D Welt z.B. von Blender... oder Autodesk Community, wird das sehr kritisiert. Siehe Beispiel: https://www.heise.de/mac-and-i/meldung/ ... 23044.html

AndySeeon hat geschrieben: ↑So 01 Dez, 2019 15:00 das ist mal wieder ein typischer Roki - nichts verstanden, aber Verschwörungstheorien ausbrüten...

Quatsch. Ich versuche es eben zu verstehen. Hast Du eine andere Erklärung? Wieso gibt es einen extra (aktivieren/deaktivieren) Schalter - "use GPU..." BRAW?

roki100 hat geschrieben: ...Hast Du eine bessere Erklärung?

Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).
Ich denke (ohne es genau zu wissen), dass die Ursache nicht allein bei NVIDIA liegt, sondern auch bei Resolve bzw. dem BRAW- Decoder von BM, denn der spricht den Treiber von NVIDIA an und irgendetwas in dieser Kommunikation geht schief, so dass Resolve einfriert. Dieser Fehler (das Einfrieren) muss eindeutig von Resolve abgefangen und behandelt werden und das ist derzeit nicht der Fall.

Nur Du behauptest, dass BM absichtlich trotz abgeschalteter GPU- Beschleunigung die GPU nutzt um besser dazustehen und weil das nicht stimmt ist das eine Verschwörungstheorie - sieh es ein! xp

Gruß, AndySeeon

AndySeeon hat geschrieben: ↑So 01 Dez, 2019 15:27

roki100 hat geschrieben: ...Hast Du eine bessere Erklärung?

Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).
Ich denke (ohne es genau zu wissen), dass die Ursache nicht allein bei NVIDIA liegt, sondern auch bei Resolve bzw. dem BRAW- Decoder von BM, denn der spricht den Treiber von NVIDIA an und irgendetwas in dieser Kommunikation geht schief, so dass Resolve einfriert. Dieser Fehler (das Einfrieren) muss eindeutig von Resolve abgefangen und behandelt werden und das ist derzeit nicht der Fall.

Nur Du behauptest, dass BM absichtlich trotz abgeschalteter GPU- Beschleunigung die GPU nutzt um besser dazustehen und weil das nicht stimmt ist das eine Verschwörungstheorie - sieh es ein! xp

Dann hast Du etwas missverstanden, obwohl deine Erklärung sich von meine kaum unterscheidet (ich habe es fettmarkiert). Ich schreibe nichts anderes: Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
Deswegen gibt es ja diesen extra Schalter für BRAW (use GPU...) den Du auch entdeckt hast. Dieser ist also unabhängig davon, was man unter GPU processing ausgewählt hat. Man kann nun meinen, dass beim aktivieren des Schalters, die ausgewählte "GPU processing mode" (unter Hardware Configuration) genutzt wird und m.M lautet hier: wahrscheinlich nicht...

BRAW hat also eine separate Leitung für die Kommunikation mit GPU.

Das BMD den eigenen Codec besser als andere Codecs darstellen, um das zu verstehen, muss man doch kein Verschwörungstheoretiker sein... Das was ich schreibe basiert auf Wahrscheinlichkeitstheorie. Die Idee von BMD mit BRAW, sehe ich sogar als sehr gut, nur wird es da m.M. öfter Abhängigkeitsprobleme geben (die GPU Hersteller müssen mitmachen bzw. das unterstützen). In der OpenSource Welt ist das eines der Gründe damals gewesen mit OpenSource Treiber für Nvidia & ATI zu starten... Denn das eine hat öfter mit dem anderen nicht immer gut funktioniert...öfter war das eine Bremse für die Weiterentwicklung unter Linux.

Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:13 Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*

Ich sehe immer noch nicht wo der Quatsch ist?

roki100 hat geschrieben: ↑So 01 Dez, 2019 16:29

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:13 Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*

Ich sehe immer noch nicht wo der Quatsch ist?

Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:38

roki100 hat geschrieben: ↑So 01 Dez, 2019 16:29

Ich sehe immer noch nicht wo der Quatsch ist?

Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss.

Das ist klar. Was ich aber angesprochen habe ist, dass BRAW eigene Leitung/Port hat, für das aktivieren und deaktivieren von GPU Hardwarebeschleuniger. Dieser funktioniert unabhängig davon, was unter "Hardware Configuration"->GPU processing mode ausgewählt ist. Das hat BMD u.a. deswegen gemacht, damit Drittentwickler, die sich mit BRAW SDK bedienen, BRAW mit GPU Hardwarebeschleuniger auch für andere NLE's zur Verfügung zu stellen (möglich ist also CUDA, Metal, OpenCL). Die Idee ist gut, doch dass es damit Probleme gibt, beweist sogar der Erfinder selbst und zwar mit der eigene NLE Software (DaVinci)... Denn, es ist von GPU Library Version abhängig, womit BRAW (SDK) compiliert ist. Und das funktioniert leider nicht immer gut. BMD selbst und auch die, die sich mit BRAW SDK bedienen, müssen bei eine Änderung (seitens GPU Hersteller) immer hinterherlaufen. Betroffen sind am ende die Nutzer, die sich darüber beklagen, dass die BRAW+GPU Wiedergabe das Programm zum Absturz bringt, dass das BRAW Plugin für Adobe nicht funktioniert... das Rosa streifen... oder schwarze Bild ..oder andere Artefakte beim BRAW abspielen zum Vorschein kommen usw. usf. ALL das hat damit zu tun, was ich versuche zu erklären. Apple hat das einfach gelöst, indem sie ein Treiber verwenden der bei MacOS standardmäßig dabei ist. Die Entwickler (außer Adobe ;) ) wissen und nutzen die eine GPU Library für eigene MacOS-Programme...

Wenn die Option "use GPU" für BRAW in DaVinci aktiviert wird, dann muss das nicht bedeuten, dass damit auch das genutzt wird, was man unter "Hardware Configuration"->GPU processing mode" ausgewählt hat. Wäre es so, dann ist die separate Option "use GPU...BRAW" eine Option zu viel...? Es kann also schon sein, dass z.B. OpenCL für die Wiedergabe genutzt wird, während alles andere das, was man unter GPU processing mode ausgewählt hat.

roki100 hat geschrieben: ↑So 01 Dez, 2019 14:10 @mash_gh4
Ein Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon (default) Fehlermeldung...nur nicht für die GUI.

ich verwende zwar resolve in genau dieser weise, aber auch hier schaut es leider icht wesentlich anders aus. du brauchst dir nur die unzähligen beispiele solcher ausgaben im resolve forum ansehen, um zu erkennen, wie wenig information über die tatsächlichen absturzursachen diesen logs zu entnehmen ist. nur in den allerseltensten fällen lässt sich daraus auf umwegen irgendwas sinnvolles od. gar eindeutiges ableiten. am ehesten noch aus den backtraces bzw. core dumps bei richtig gravierenden abstürzen. aber auch diese information kann man als endanwender ohne zugriff auf den zugrundeliegenden code im regelfall nicht wirklich sinnvoll nutzen od. nachvollziehen.

ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.

wobei das problem des to´s gelöst ist, auch ich habe vor ca 3 wochen, vor meinem urlaub, den neuesten nvidia-studio-treiber installiert, mangels zeit (2 wochen urlaub) eben nicht mit resolve, bis dato stabil, benutzt, nach meiner rückkehr allerdings häuften sich die unnachvollziehbaren programmabstürze im laufe letzter woche, ich werde also morgen auch den älteren studio-treiber aufspielen und berichten.

lg

srone

edit: ich benutze kein braw, sondern prores hq, avchd und dji mp4, als abzuspielende dateiformate.

roki100 hat geschrieben: ↑So 01 Dez, 2019 19:34 ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.

dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 20:01

roki100 hat geschrieben: ↑So 01 Dez, 2019 19:34 ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.

dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone

Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:08

srone hat geschrieben: ↑So 01 Dez, 2019 20:01

dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone

Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess.

in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 20:13

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:08
Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess.

in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone

Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:19

srone hat geschrieben: ↑So 01 Dez, 2019 20:13

in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone

Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.

genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 20:26

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:19
Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.

genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.

lg

srone

Eine Fehlermeldung ist eine Textausgabe, mehr nicht.

Öfter ist die Lösung eine einfache if-Anweisung, mit ein oder zwei elseif mehr dazu. Außerdem gibt es extra Debugger, die in eigenem Code geladen/integriert/verknüpft werden... Ein Wert wird an Debugger geschickt, da analysiert und mit return OK oder nicht-OK zurückgegeben, hinter "nicht OK" kommt die exakte Fehlermeldung, die vom Entwickler in einer verständlichen Sprache übersetzt werden muss, um so den Nutzern z.B. in GUI auszugeben und lesbar zu machen....

für mein verständnis ist also der debugger der überwachungsprozess?

und quasi die entscheidungsinstanz?

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 20:32 für mein verständnis ist also der debugger der überwachungsprozess?

Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf Doch um das zu nutzen, muss BMD das DR Programm mit Flag -g kompilieren... Ob BMD das tatsächlich getan hat, kann ein Linux user mal testen.

roki100 hat geschrieben: ↑So 01 Dez, 2019 20:50

srone hat geschrieben: ↑So 01 Dez, 2019 20:32 für mein verständnis ist also der debugger der überwachungsprozess?

Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf

danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 21:09

roki100 hat geschrieben: ↑So 01 Dez, 2019 20:50
Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf

danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone

Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:24

srone hat geschrieben: ↑So 01 Dez, 2019 21:09

danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone

Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.

ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 21:28

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:24
Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.

ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone

Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:31

srone hat geschrieben: ↑So 01 Dez, 2019 21:28

ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone

Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.

ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb und deren ressourcenverbrauch, darum gings mir....;-)

lg

stone

srone hat geschrieben: ↑So 01 Dez, 2019 21:33

dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:31
Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.

ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb, darum gings mir....;-)

lg

stone

Das ist natürlich alles etwas komplexer, als hier besprochen werden kann, aber wie oben schon geschrieben, können Abfragen einfach protokolliert werden. Das kostet eher keine Ressourcen, z.B. Nvidia vorhanden, verwende Cuda. So eine Meldung hilft allerdings nicht, wenn im Treiber von Cuda ein Fehler auftritt. Nur die Programmierer der Anwendung können letztlich entscheiden, an welchen Punkten sie Meldungen generieren lassen, um im Fehlerfall Hilfestellungen zu haben.

genau, aber wer entscheidet, weshalb, über code ok oder nicht?

welche instanz macht sich das zu eigen?

lg

srone

srone hat geschrieben: ↑So 01 Dez, 2019 21:57 genau, aber wer entscheidet, weshalb, über code ok oder nicht?

welche instanz macht sich das zu eigen?

lg

srone

Code ist ok, wenn er läuft.
Wenn du allerdings ein Video sehen willst und sich dein Email Programm öffnet, dann kann es sein, dass das Programm perfekt läuft, aber irgendwie anders als erwartet ;)