On 4/24/2024 2:52 PM, 'Albrecht
Schlosser' via fltk.coredev wrote:
Note: a
stack trace w/o debug info is not very helpful. If this issue
persists I recommend to deploy an executable from a debug build
(assuming that you build the executable and not the end user).
I have now sent a debug build to my user on github. I am waiting
for him to test it.
KiUserExceptionDispatcher is not defined by FLTK. This indicates
that the handle() method of your derived window class calls
KiUserExceptionDispatcher().
This is a common stack trace step when a SEGV or similar exception
happens on MSVC.
7: Fl_Window::handle - 0x140709297099744
I have no idea why Fl_Tiled_Image::draw() would (indirectly) call
Fl_Window::handle(). There's some clipping done, hence
fl_win32_xid() might be plausible.
Fl_Tiled_Image::draw() may be called (IIRC) when the 'plastic'
scheme is used to draw the background image
That's interesting.
IMHO the best you can do is to use a memory analyzer like Address
Sanitizer (ASAN) or valgrind to check for access violations in
thorough tests. IIRC Visual Studio supports ASAN, hence you should
be able to build your program with ASAN support on Windows, and
I'd guess that MSYS2 also supports (clang and) ASAN.
Sadly AddressSanitizer I believe it is still in beta on Visual
Studio and valgrind is not available on Windows.
I hope this helps. Good luck.
Yes, it helped. But I am still waiting on my user to get back to
me.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.