SVG stretchDraw causes access violation about bgracontrols HOT 18 CLOSED

Hellu circular17,

with latest fixes, a loop of 10000 clicks can't reproduce the bug anymore.
Great job!

from bgracontrols.

Hello Freihut,

Thanks for testing again. This was indeed essential as there was still some remaining problem. I was able to get an exception by clicking seven times that seem to be the error you mention. So, there is something not quite right with memory management.

Digging into it, I found a malfunction related to the list of listeners in TSVGDataLink. The TFPGList was comparing the address of the method and not the instance of the object, so it could not differentiate between listeners. Hence the listeners were not removed in the right order. I've fixed it on dev : bgrabitmap/bgrabitmap@a830741

I invite you to pull the latest changes again and let me know if this resolves the issue. Let's keep on improving my baby library!

from bgracontrols.

Hi, please provide a compilable demo project. And steps to reproduce.

from bgracontrols.

Hellu,

I'm not sure I ran into the same issue, but I also got a access violation caused by stretchDraw (happens at Free()).

For some reason this needs to be compiled with the flags -gh and -gl to occur. Tried Gtk2 and Qt5: Doesn't matter.

Seems to be related to the svg you're loading: In the example it happens with 'bash_fails.svg' but not with 'bash_passes.svg' which on my sys are part of the "Humanity-icon-theme" (/usr/share/icons/Humanity/*).

example.zip

Used: Laz 2.2.6 + fpc 3.2.2 + bgracontrols 7.7 + bglcontrols 1.2 + bgrabitmappack 11.5.4

from bgracontrols.

@lainz Found a way to reproduce, just build and launch the program attached and access violation will happen in a second.

SVGaccessviolation.zip

from bgracontrols.

@circular17 this bug should be part of bgrabitmap repo, but is reported here, can you label this?

from bgracontrols.

Hi @lainz,

I don't know if it is related to BGRABitmap nor BGRAControls. Looking at the code proposed by @Fratee, I see that there are some instructions in the TThread object that can cause problems.

{ Tth }

procedure Tth.Execute;
begin
  while true do begin
    Form1.mpBGeo.Repaint;
    sleep(1);
    Form1.Label1.Caption := IntToStr(StrToInt(Form1.Label1.Caption) + 1);
  end;
end;

...

procedure TForm1.FormCreate(Sender: TObject);
begin
  th := Tth.Create(false);
end;  

The thread is created as not suspended, so it may run before the variable Form1 is actually defined. To avoid this, the form object should be passed to the constructor Tth.Create by using self variable, and the thread should use this variable instead of the global variable Form1.

Secondly, the thread Execute function accesses controls directly, but controls must be accessed in the main thread, by using Synchronize if it is from another thread.

The intent of the code seem to be to repaint the map as much as possible. Using only the timer can be sufficient, otherwise one can tap into the idle event of the application using Application.AddOnIdleHandler, though drawing too frequently can prevent the user from interacting with the form.

Finally, using Repaint is not cross-platform. It is better to use Invalidate when possible.

from bgracontrols.

I suppose that's the last comment sources?
Because there's another example in a previous comment with the same issue (apparently).

from bgracontrols.

Indeed, it was about #130 (comment)

About the example in #130 (comment) indeed there is an exception with bash-fails.svg. Unfortunately, the debugging doesn't work on my computer. Can you have a look, maybe tell me the stack trace of the error?

from bgracontrols.

Hi, I can't compile that test project, missing dependencies...

from bgracontrols.

@lainz Try to create a new project, drop a TButton and a Timage and copy that procedure TForm1.Button1Click(Sender: Tobject); from my unit1.pas and you should be good to go (don't forget the svgs and custom options "-gh -gl" of course).

from bgracontrols.

@lainz The first example called example.zip does not seem to me to have special dependencies, except that it uses qt5 widgetset. You can uncheck the LCLWidgetType option in the project options. The second example called SVGaccessviolation.zip does have a lot of dependencies.

@Freihut It would be of great help if you provide the full stack trace.

from bgracontrols.

@circular17 Here you go: gdb_backtrace.txt
(Its from a gtk2-build)

from bgracontrols.

Thanks. Ok, so the top lines of the stack trace are:

#0  0x0000000000432080 in fpc_raiseexception ()
#1  0x000000000079ecf1 in FGL$_$TFPSLIST_$__$$_ERROR$SHORTSTRING$INT64 ()
#2  0x000000000079e908 in FGL$_$TFPSLIST_$__$$_DELETE$LONGINT ()

It seems an exception is raised on purpose by the Delete function. Are you sure it is an access violation?

Here it is TFPSList but in fact BGRABitmap uses TFPGList that inherits from TFPSList. So there error happens at some point when Delete or Remove is called on one of these generic lists. The only case I can find is if the index is out of bound.

The stack trace has lines without debug information. For example:

#3  0x6e69207473694c1d in  ()
#4  0x2964252820786564 in  ()

It would be great @Freihut to have all the details. For this, one need to include debug information in the BGRABitmap package. This is in the "Debugging" options of the package. Another thing that can help is to ensure that the optimization level is set to zero in "Compiling and Linking".

Thanks again for helping solve this bug!

from bgracontrols.

Are you sure it is an access violation?

Good question! I double-checked and modified the example (to dump the exceptions), and it turned out: Sometimes you'll get an EListError and other times you'll get an EAccessViolation.
Seems kind of random and not depending on the widgetset, but I only ran a few passes.
I'll attach the new unit1.pas + the dumps.

The 2nd backtrace was created with:

Options for package:
OPTIMIZATION LVL = 0
[x] Generate info for debugger
-gw2
-gl

Options for project (using the buildmode GLGH in the example):
OPTIMIZATION LVL = 0
Checks and asserts: all
[x] Generate info for debugger
-gw -godwarfsets
-gl

(buildmode forgot to set -gh, but for some reason it doesn't matter now)

gdb_backtrace2.txt
code+exceptions.zip

from bgracontrols.

Thank you so much for providing such detailed information!

From what I gather, the issue arises from accessing memory that has already been deallocated, which explains the random error. This occurs in the ResetGradients function.

I've identified a reentrance problem in ResetGradients. To address it, I've added a boolean to check and exit when function is already being called.

The changes have been made on the dev-bgrabitmap branch: bgrabitmap/bgrabitmap@3805b30

I invite you to pull the latest changes and let me know if this resolves the issue. I am glad we are improving on the robustness of BGRABitmap.

from bgracontrols.

Glad to help, but I'm afraid, this doesn't fix it:

First button click usually runs without exception now, but on 2nd I got ElistError/EaccessViolation, than the example-app just disappears (without the commit 3805b30 it keeps running).

Also, gdb's output is gone now.

I was wondering about the need to click twice to throw an error, so I commented out Image1.Picture.Bitmap.LoadFromBitmapHandles(Pic.Bitmap.BitmapHandle, Pic.Bitmap.MaskHandle); (because this is the only reused element), but that didn't change much.
gdb_output.txt
Exception_gtk2_25-10-23 18:50:58.txt
Exception_gtk2_25-10-23 18:51:34.txt
Exception_gtk2_25-10-23 18:52:52_without_Image1_line.txt

from bgracontrols.

Hello @Freihut,

Wonderful. Thank you so much for your valuable feedback and testing!

I will proceed and close the issue.

from bgracontrols.