fpspreadsheet SIGSEGV mit Frames - Lazarus 2 RC2

[af0815]

Ich verwende fpspreadsheet innerhalb von Frames (in Frames), die zur Laufzeit geladen werden.

Wenn ich jetzt dasselbe Programm mit Lazarus 1.8.5 / mit fpc 3.1.1 58495 laufen lasse so funktioniert es. Verwende ich zum konpileren Lazarus 2.0RC2 /fixes20) mit fpc (fixes3.2) so gibt es eine SIGSEGV in der laz_avl_tree.pp line 1410. fpspreadsheet aus dem OPM V1.10.1 (gleiches Problem mit 1.9.0).

Dort in der laz_avl_tree.pp hat sich aber nicht wirklich was geändert, wenn ich mir den SVN ansehe.

Ich rufe dort nur sWorksheetGrid1.AutoColWidth(i) auf. Wobei i eine vorhandene Spalte ist.

Call Stack ist

Code: Alles auswählen

#0 TAVLTREENODE__SUCCESSOR(<error reading variable>) at laz_avl_tree.pp:1410
#1 TSROWCOLENUMERATOR__MOVENEXT(<error reading variable>) at .\common\fpsclasses.pas:311
#2 TSCUSTOMWORKSHEETGRID__AUTOADJUSTCOLUMN(0, <error reading variable>) at .\visual\fpspreadsheetgrid.pas:1402
#3 TSCUSTOMWORKSHEETGRID__AUTOCOLWIDTH(0, <error reading variable>) at .\visual\fpspreadsheetgrid.pas:1361
#4 TFRAMExxxxxxyyyyyXLS__CB_CHANGE(0x0, <error reading variable>) at .\firgendwo.pas:312

Wie gesagt, mit der älteren Version von Lazarus läuft alles. Ich gehe auch davon aus, das es keine Probleme gibt, wenn ich keine Frames verwenden würde.

Any Hint ?!

[wp_xyz]

Versuche mal ein Demoprojekt zu erstellen, an dem ich den Fehler nachvollziehen kann. Wenn ich in den svn-Logs nichts übersehen habe, war die letzte Änderung in Bezug auf Frames im Mai 2017 (r5868), sollte also in der OPM-Version enthalten sein.

[af0815]

Das mit dem Frames im Mai 2017 kenne ich

Ich habe versucht mal das in der App einzugrenzen, der Fehler tritt bei verschiedenen Bereichen auf, auch scheinbar beim Zeichnen. Der SIGSEGV liegt aber immer hier
TAVLTREENODE__SUCCESSOR(<error reading variable>) at laz_avl_tree.pp:1410 nur dort ist auch schon länger nichts gemacht worden.

Weisst du was im the AVL-Tree drinnen liegen soll ? Ich vermute das es da wieder Probleme mit dem Parent beim Traversieren gibt, der beim Übergang Komponnete -> Frame --> Form aus dem Tritt kommt.

Ich versuche mal ein Beispiel zu machen, mal sehen ob der Fehler dort einfacher zu sehen ist.

Danke,
Andi

[af0815]

Erstes Konklusio:

Der Fehler ist sehr substil. Es hängt mit den Suchen der nachfolgenden Zelle zusammen.

Aber:
EIn Beispiel erstellt mit der aktuellen Lazarus/FPC Konfiguration zeigt den fehler nicht.
Ein Beispiel mit der alten Lazarus/FPC Version zeigt den Fehler auch nicht.

Wenn ich das Frame herauslöse so zeigt sich der Fehler nur bedingt zur Laufzeit. Es hat IMHO irgendwie mit der Erkennung der Spaltenbreite beim Textfeldern zu tun. Wenn das Grid mit keiner sWorkbooksource verbunden ist gehts. Wenn ich die beiden verbinde kracht es. Logik ist aber noch nicht bekannt.

Wird also noch dauern bis ich das Problem weiter eingegrenzt habe.

[af0815]

Zur Info:
In Lazarus 2.0.0RC2 r59724 FPC 3.2.0 i386-win32-win32/win64 (FPC fixes 3.2. Rev. 40301) ist das Problem nicht mehr vorhanden.

[wp_xyz]

Oje, die schlimmsten Fehler sind die, die sich selbst reparieren...

[af0815]

Es hatt dezitiert mit der Berechnung der Spaltenbreite von Text zu tun, soviel habe ich herausbekommen. Es ist was passiert beim Traversieren, da ist die Ermittlung des Parent(Forms) fehlgeschlagen. Soweit bin ich gekommen. Nur zum Debuggen hätte ich mir auch eine FPC-Installation mit aktivierten Debugging aufbauen müssen, das habe ich auf die Weihnachtsferien verschoben. Habe jetzt Zeit für was anderes in den Ferien

[af0815]

Es tritt mit dem aktuellen Lazarus 2.0 (fixes 2.0) und fpc 3.2 (fixes3.2) auch wieder auf.

Stack

Code: Alles auswählen

#0 TAVLTREENODE__SUCCESSOR(<error reading variable>) at laz_avl_tree.pp:1410
#1 TSROWCOLENUMERATOR__MOVENEXT(<error reading variable>) at .\source\common\fpsclasses.pas:547
#2 TSCUSTOMWORKSHEETGRID__DRAWCELLBORDERS(0, <error reading variable>) at .\source\visual\fpspreadsheetgrid.pas:2487
#3 TSCUSTOMWORKSHEETGRID__DRAWALLROWS(<error reading variable>) at .\source\visual\fpspreadsheetgrid.pas:2334
#4 TCUSTOMGRID__PAINT(<error reading variable>) at grids.pas:3757
#5 TCUSTOMCONTROL__PAINTWINDOW(889265107, <error reading variable>) at .\include\customcontrol.inc:118
#6 TWINCONTROL__PAINTHANDLER({MSG = 15, DC = 889265107, PAINTSTRUCT = 0xb3bfa8c, RESULT = 0}, <error reading variable>) at .\include\wincontrol.inc:4848
#7 TWINCONTROL__WMPAINT({MSG = 15, DC = 889265107, PAINTSTRUCT = 0xb3bfa8c, RESULT = 0}, <error reading variable>) at .\include\wincontrol.inc:6835
#8 TCUSTOMCONTROL__WMPAINT({MSG = 15, DC = 889265107, PAINTSTRUCT = 0xb3bfa8c, RESULT = 0}, <error reading variable>) at .\include\customcontrol.inc:98
#9 SYSTEM$_$TOBJECT_$__$$_DISPATCH$formal at :0
#10 ?? at :0
#11 TWINCONTROL__WNDPROC({MSG = 15, WPARAM = 889265107, LPARAM = 188480140, RESULT = 0, WPARAMLO = 7123, WPARAMHI = 13569, WPARAMFILLER = {}, LPARAMLO = 64140, LPARAMHI = 2875, LPARAMFILLER = {}, RESULTLO = 0, RESULTHI = 0, RESULTFILLER = {}}, <error reading variable>) at .\include\wincontrol.inc:5419
#12 TCUSTOMGRID__WNDPROC({MSG = 15, WPARAM = 889265107, LPARAM = 188480140, RESULT = 0, WPARAMLO = 7123, WPARAMHI = 13569, WPARAMFILLER = {}, LPARAMLO = 64140, LPARAMHI = 2875, LPARAMFILLER = {}, RESULTLO = 0, RESULTHI = 0, RESULTFILLER = {}}, <error reading variable>) at grids.pas:4837
#13 DELIVERMESSAGE(0x11af7ae0, <error reading variable: Attempt to dereference a generic pointer.>) at lclmessageglue.pas:112
#14 TWINDOWPROCHELPER__SENDPAINTMESSAGE(0, <error reading variable>) at .\win32\win32callback.inc:690
#15 TWINDOWPROCHELPER__DOWINDOWPROC(<error reading variable>) at .\win32\win32callback.inc:2268
#16 WINDOWPROC(1052128, 15, 0, 0) at .\win32\win32callback.inc:2673
 

Anzeige der Daten

Was man sieht ist, da die 'vermeintliche Adresse 40ba4444 verwendet wird. Egal ob man recompiliert oder nicht. Die Werte unter Data ändern sich immer wieder. Nur 40ba4444 bleibt immer konstant.

SIGSEGV

Ich hatte durch das 40ba4444 so einen Verdacht: Deaktiviere ich Heaptrace, so ist der Fehler bei mir weg. Wenn man sich die Stelle wo das passiert ansieht, so wird dort auf nil abgefragt. Was ist wenn wenn die Kennung von Heaptrace beim Hochtraversieren statt einem nil seine Kennung eingebracht hat ?!

Edit: heaptrc sollte $DEADBEEF und $AAAAAAAA haben.