| |
| |
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.
8: Fl_Window::y_root - 0x140709297101632
9: fl_win32_xid - 0x140709297228272
10: Fl_Tiled_Image::draw - 0x140709297052528
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.
--
Gonzalo Garramuño
ggarra13@gmail.com
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/ff59fd58-b295-4fa5-93cf-4eb4d91d90d7%40gmail.com.
[ Direct Link to Message ] | |
|
| |
