Some issues with latest FLUID

[Mo_Al_]

Hello

So I've been tinkering around with the latest version of FLUID and Fl_Flex. 

2 things I noticed:

- The orientation changes (HORIZONTAL -> VERTICAL) when adding widgets into the Fl_Flex:

1- create a function

2- add a window

3- add a flex

4- change orientation to Horizontal

5- add a button to the flex. The flex's orientation changes back to vertical

- I had a spurious crash on windows when adding widgets into the Fl_Flex:

1- create a function

2- add a window

3- add a flex

4- create a tree inside the flex

[Matthias Melcher]

Thanks for testing it. I will give that a test run.

[Matthias Melcher]

may64...@gmail.com schrieb am Donnerstag, 24. November 2022 um 09:17:21 UTC+1:

- The orientation changes (HORIZONTAL -> VERTICAL) when adding widgets into the Fl_Flex:

Ooopsie. I bailed out of the function when there were no children without actually changing the type. Fixed. 

- I had a spurious crash on windows when adding widgets into the Fl_Flex:

I tried to trigger this under Valgrind, but did not find anything. If you have anything repeatable, that would be really helpful.

I did fix two other Valgrind hits though: git commit 6f36a6362982b08574e27a61d9c8716fe5aac8a8

 

[Mo_Al_]

Thanks for checking things out.

The second issue I only noticed on Windows. This is a backtrace using windbg (since I don't think valgrind runs on windows):
HEAP[fluid.exe]: Heap block at 00000144B3F1D290 modified at 00000144B3F1D2E0 past requested size of 40 (52d8.224c): Break instruction exception - code 80000003 (first chance) ntdll!RtlpBreakPointHeap+0x16: 00007ff9`ba2a70ce cc int 3

I'll try to build a debug build of fluid and run again via windbg.

[Mo_Al_]

Debugging things in VS it seems the problem lies in fltk.lib in the gdi driver code:

     fluid.exe!operator delete(void * block) Line 38    C++
     fluid.exe!operator delete[](void * block) Line 32    C++
>    fluid.exe!Fl_GDI_Graphics_Driver::create_bitmask(int w, int h, const unsigned char * data) Line 393    C++
     fluid.exe!Fl_GDI_Graphics_Driver::cache(Fl_Pixmap * img) Line 806    C++
     fluid.exe!Fl_Graphics_Driver::draw_pixmap(Fl_Pixmap * pxm, int XP, int YP, int WP, int HP, int cx, int cy) Line 242    C++
     fluid.exe!Fl_Pixmap::draw(int XP, int YP, int WP, int HP, int cx, int cy) Line 48    C++
     fluid.exe!Fl_Image::draw(int X, int Y) Line 295    C++
     fluid.exe!Fl_Tree_Item::draw(int X, int & Y, int W, Fl_Tree_Item * itemfocus, int & tree_item_xmax, int lastchild, int render) Line 1104    C++
     fluid.exe!Fl_Tree::draw() Line 733    C++
     fluid.exe!Fl_Group::draw_child(Fl_Widget & widget) Line 961    C++
     fluid.exe!Fl_Group::draw_children() Line 917    C++
     fluid.exe!Fl_Group::draw() Line 932    C++
     fluid.exe!Fl_Group::draw_child(Fl_Widget & widget) Line 961    C++
     fluid.exe!Fl_Group::draw_children() Line 917    C++
     fluid.exe!Fl_Window::draw() Line 523    C++
     fluid.exe!Overlay_Window::draw() Line 344    C++
     fluid.exe!Fl_Window_Driver::draw() Line 82    C++
     fluid.exe!Fl_WinAPI_Window_Driver::flush_overlay() Line 349    C++
     fluid.exe!Fl_Overlay_Window::flush() Line 53    C++
     fluid.exe!Fl_Window_Driver::flush() Line 204    C++
     fluid.exe!Fl::flush() Line 755    C++
     fluid.exe!Fl_WinAPI_System_Driver::wait(double time_to_wait) Line 521    C++
     fluid.exe!Fl::wait(double time_to_wait) Line 581    C++
     fluid.exe!Fl::run() Line 600    C++
     fluid.exe!main(int argc, char * * argv) Line 2023    C++
     fluid.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 113    C

[Mo_Al_]

Crudely commenting `delete[] newarray;` in the `HBITMAP Fl_GDI_Graphics_Driver::create_bitmask(int w, int h, const uchar *data)` method seems to resolve the issue. 

Maybe CreateBitmap requires the data to be still alive?

[Matthias Melcher]

I was thinking that the bitmap width or height is 0, so "new[w*h]" returns NULL. But the C++ standard allows "delete[] NULL", so that should not crash. VisualStudio 2010 seems to ignore that though, so maybe that's the issue? Either way, if w or h is zero or less, there should be no attempt to build the bitmap at all.

[lifeatt...@gmail.com]

A few observations ...

>Maybe CreateBitmap requires the data to be still alive?

The docs don't say that. The docs have been wrong before ...

> fluid.exe!Fl_GDI_Graphics_Driver::create_bitmask(int w, int h, const unsigned char * data) Line 393

The matching line in Github is line 390. Explanation for the discrepancy?

>the bitmap width or height is 0, so "new[w*h]" returns NULL

This is true if FLTK was built against the C std library (not the C++ std library). In which case the library is not C++ standard

conformant [new should not return NULL]; the assumption that delete (null) will be handled might not be valid?

Kevin

[Matthias Melcher]

I am a bit further. So it seems that the device context is invalid (gc_) which gives us 0 for most values, allocating 0 bytes, but writing many more bytes. No wonder that crashes. So this is a regression, but when did that happen? Maybe related to the overlay window?

[Matthias Melcher]

Ok, with different git commits, the location of the crash moves randomly. So this some memory corruption, probably in the MSWindows code. Now, I am not using VisualStudio much, and I don't know how to switch on bounds checkers and stuff, so I will have to leave this here for someone else to solve.

[Matthias Melcher]

Ok, this is fixed in the current master with 09697c47385b2b4749f41e2862b0e93eb9933092

[Mo_Al_]

Thanks Matthias

I confirm I no longer get the crash with the latest commit.

[Manolo]

Le vendredi 25 novembre 2022 à 10:55:46 UTC+1, Matthias Melcher a écrit :

Ok, this is fixed in the current master with 09697c47385b2b4749f41e2862b0e93eb9933092

I've made Fl_XXX_Graphics_Driver:: create_bitmask() become static member functions

to avoid the kind of error that occurred here where the non relevant graphics driver was used.

That is at commit 4de491d

[Matthias Melcher]

Thanks!