[Erledigt] Bug in TSaveDialog

[Michl]

Normalerweise gibt "Speichern" ohne eine Auswahl keinen Modalwert zurück und schließt das Fenster nicht. (Der Button wird allerdings nicht ausgegraut.)

Wenn ich dich jetzt richtig verstanden habe, wäre das aber eher schlecht für mich. Ich möchte gerne eine Datensicherung durchführen können, dabei soll der Nutzer einen Vorschlag über den Namen der zu speichernden Sicherung erhalten (daher vordefinierter Dateiname).

Den Debuggerfehler bekomme ich allerdings auch dann, wenn ich nur Abbrechen klicke.

Da stürzt der Debugger bei mir nicht ab!!!

Wobei der Debugger in letzter Zeit bei vielen Gelegenheiten abstürzt, z.B. beim Inspizieren von Klassen.

Das stimmt, die SVN-Version (Lazarus 1.1 r42453 FPC 2.7.1 i386-win32-win32/win64 vom 23.08.13) läuft bei mir eigentlich wieder recht stabil, habe mich daher bisher gescheut, eine neuere SVN für TestZwecke zu installieren...

[theo]

Geht's denn ohne Debugger?
Was ist denn so schlimm daran, wenn der Debugger beim Programmende abstürzt?
Kann auch ein Fehler im GDB sein.

[Michl]

Ohne Debugger gehts. Kann daher ein Fehler im GDB sein. Schlimm ist´s nicht, ich nutze halt gern den Debugger. Und dann ist es schlecht, wenn nach dem Schließen des Programms neben dem Debugger manchmal auch die IDE mit abstürzt.

[jammern an] Und zum Verzweifeln ist es, wenn man ein recht großes Projekt hat, eigentlich alles stabil läuft und dann kommt so ein undefinierter Fehler, den man erst sonstwo vermutet und dann ist es ein Klick auf ein Button...[/jammern aus]

Nein im Ernst, ich komm auch so weiter aber besser ist es doch, wenn man einen Fehler identifiziert, diesen auch zu melden. Evtl. kann dann jemand damit was anfangen. Evtl kann er behoben werden?! Oder wer einen ähnlichen Fehler hat, kann ihn dann evtl. besser zuordnen?!

[theo]

Nein im Ernst, ich komm auch so weiter aber besser ist es doch, wenn man einen Fehler identifiziert, diesen auch zu melden. Evtl. kann dann jemand damit was anfangen. Evtl kann er behoben werden?! Oder wer einen ähnlichen Fehler hat, kann ihn dann evtl. besser zuordnen?!

Fragt sich halt, ob Lazarus/FPC was dafür kann und ob sich die Spurensuche lohnt.
Nimmt man die Meldung von GDB ernst ("A problem internal to GDB has been detected"), dann ist es ein GDB Problem.

[Michl]

dann ist es ein GDB Problem.

Und was macht man in diesem Fall? Ist der Bug-Tracker der falsche Ort?

[theo]

Und was macht man in diesem Fall? Ist der Bug-Tracker der falsche Ort?

GDB gehört nicht eigentlich zu FPC. Es muss wahrsch. erstmal schon via FPC/Lazarus Bugtracker gehen, aber es dürfte schwierig werden.
Für GDB gibt es hier mehr:
https://www.gnu.org/software/gdb/bugs/
https://www.gnu.org/software/gdb/mailing-lists/

[Michl]

Danke für die Info, werd mal schauen, ob sich was beim Bug-Tracker tut.

Na dann...

[willi4willi]

Hallo,
ich habe

• win-64
• Lazarus 1.1. Rev.40788 CT
• FPC-Version 2.7.1

und keine Probleme mit o.g. Code. Egal ob mit oder ohne Debugger.

Ich kann mich aber erinnern, dass ich dieses Problem mit einer anderen Lazarus-Version auch schon einmal hatte. Mit einer anderen Version ging es dann aber.


Viele Grüße
Willi4Willi

[Michl]

Danke für die Info,

lt BugTracker und Theos Post wird da leider nicht viel zu machen sein, aufgrund des genutzten Debuggers. Dass der Debugger hin und wieder Probleme verursacht, ist offensichtlich bekannt, wird aber als ein kosmetisches Problem angesehen (was es ja auch bei mir ist, nervig aber nicht bedrohlich).

Die Löung dieses Problems ist verschoben auf Target 1.4. Der Fehler wird, wenn er nicht einmal zufällig mit eliminiert wird, in naher Zukunft wahrscheinlich immer mal wieder auftauchen.

Ich weiss jetzt woran es liegt, kann das Verhalten somit abschätzen und auch damit leben. Für mich hat sich das Thema damit erstmal erledigt.

[martin_frb]

Danke für die Info,

lt BugTracker und Theos Post wird da leider nicht viel zu machen sein, aufgrund des genutzten Debuggers. Dass der Debugger hin und wieder Probleme verursacht, ist offensichtlich bekannt, wird aber als ein kosmetisches Problem angesehen (was es ja auch bei mir ist, nervig aber nicht bedrohlich).

Ja es ist bekannt. Nein es ist (im allgemeinen nicht kosmetisch). Sondern nur in diesem Fall.

Das Problem, auch in den ernsten Faellen ist kurz und mittelfristg nix zu machen.

Die Lösung dieses Problems ist verschoben auf Target 1.4. Der Fehler wird, wenn er nicht einmal zufällig mit eliminiert wird, in naher Zukunft wahrscheinlich immer mal wieder auftauchen.

1.4 ist da eher eine temporaer zuweisung.

Der Fehler kann derzeit nur auf 2 Arten behoben werden.

1) GDB wird stabil....

2) Ein Debugger ohne GDB (und das ist sehr sehr sehr viel Arbeit (aber irgendwann, hoffentlich....)

---
Der Bug wird deshalb ueber kurz oder lang geschlossen werden. Ohne Loesung.

[martin_frb]

So gerade mal getestet bei mir crashed es natuerlich nicht....

Wenn CT laueft, einfach die GDB exe kopieren. Afaik benutzt CT eine neuere Version von GDB. Allerdings haben die neueren GDB in meinen Tests alle schlechter abgeschnitten.

GGF aus interresse (obwohl es 99.99% nicht zu einer Loesung fuehren wird; Ein log http://wiki.lazarus.freepascal.org/GDB_ ... ug_session

[Michl]

Ich schau´s mir mal an, wenn ich damit helfen kann gerne, bis dahin...

[Edit] Ich nutze zwar nicht CodeTyphon (...war hde), die Log (Lazarus 1.1 r42453 FPC 2.7.1 i386-win32-win32/win64) habe ich aber trotzdem mal erstellt. Vielleicht hilfts dir ja, würd mich freuen!

[Michl]

Ich habe eben noch zum Test auf einem anderen Rechner die offizielle Lazarus-Version 1.0.12 (r42478 FPC 2.6.2 i386-win32-win32/win64) installiert und getestet -> stürzt auch ab. Anbei noch die laz.log, wird sich aber wahrscheinlich nicht unterscheiden?!

[martin_frb]

Danke. Nicht viel ... wie erwartet.

Ausser: nicht thread sondern library loading related. Und damit zumindest *wahrscheinlich* immer nur beim app beenden.

Propier mal
http://wiki.lazarus.freepascal.org/GDB_ ... ed_working
go to the debugger options and in the field "debugger_startup_options" enter:
--eval-command="set auto-solib-add off"

Wenn es das ist, erklaert sich auch warum CT lief. Das ist nur bis gdb 7.4, CT hat wahrscheinlich einen neueren (allerdings, deshalb trotzdem nicht besseren)

[Michl]

Getestet, kein Absturz des Debuggers!

Kannst du mir erklären, was "--eval-command="set auto-solib-add off" " sonst noch macht (außer das Laden der DLLs überwachen)? Bzw. weißt du, ob ich das so lassen kann oder fallen da großartig Meldungen andere Fehler auch mit weg?

[Edit] Habs mir per Google erklären lassen: If mode is on, symbols from all shared object libraries will be loaded automatically when the inferior begins execution, you attach to an independently started inferior, or when the dynamic linker informs GDB that a new library has been loaded. If mode is off, symbols must be loaded manually, using the sharedlibrary command. The default value is on.