Crash on startup.

[Rob McDonald]

I tried updating to 1.4.1 today and ran into a problem.  I've bisected it down to

3922ef67c1385  Further accelerating Fl_Text_Display (#596)            Matthias Melcher

-- Configuration Summary for FLTK 1.4.0 generated by CMake 3.31.1 --

-- The following OPTIONAL packages have been found:

 * Doxygen
 * LATEX
 * OpenGL

-- Static libraries    will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/lib
-- Shared libraries    will not be built (set FLTK_BUILD_SHARED_LIBS=ON to build)
-- The forms library   will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/lib
-- The OpenGL library  will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/lib
-- fluid               will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/bin
-- fltk-options        will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/bin
-- Test programs       will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/bin/test
-- Example programs    will be built in: /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/bin/examples
--
-- Build configuration      RelWithDebInfo
-- Installation prefix      /Users/ramcdona/Documents/OpenVSP/build/llvmrwdi-FLTK/install

-- Bundled Libraries        JPEG     = Bundled
--                          PNG      = Bundled
--                          ZLIB     = Bundled

-- Fl_Cairo_Window support  No
-- Use std::                No

-- End of Configuration Summary --

-- Configuring done (3.7s)
-- Generating done (0.2s)

Stacktrace:

[Inlined] fl_font() fl_draw.H:812
TabScreen::MakeTab(const std::string &) ScreenBase.cpp:223
TabScreen::AddTab(const std::string &) ScreenBase.cpp:239
CfdMeshScreen::CreateGlobalTab() CfdMeshScreen.cpp:67
CfdMeshScreen::CfdMeshScreen(ScreenMgr *) CfdMeshScreen.cpp:29
ScreenMgr::Init() ScreenMgr.cpp:616
ScreenMgr::ScreenMgr(Vehicle *) ScreenMgr.cpp:80
GuiInterface::InitGUI(Vehicle *) GuiInterface.cpp:51
main main.cpp:218

This is happening on program startup -- while constructing all of my various screens.  This is the first of my screens that uses a tab, if I move this one to the end of the list, it succeeds until the next screen with Tabs.  The last line in 'my' code reads:

int rx, ry, rw, rh;

m_MenuTabs->client_area( rx, ry, rw, rh, TAB_H );

I don't see any connection between the commit I bisected down to and this problem -- but I've checked the result of the bisection repeatedly.

Rob

[Greg Ercolano]

Can you replicate any crashes in the test apps?

If not, but sure sounds like your app is building against mismatched versions of fltk, or there are stale .o files compiled against a different version than the new fltk.

To rule out interference between old and new releases, this may sound obvious, but be sure you've:

• Made a clean checkout of 1.4.x current in an empty directory (git clone)
  
• Modified your app to refer to this clean checkout directory
• Do a clean rebuild of your app (making sure no .o's for your app are left over from a previous build of fltk)
• Make sure you're not linking to an old fltk lib
• Make sure there's no old links in /usr/include/FL (pointing to an old or different FLTK version)

Any one of those things could cause a crash in strange places, and bisecting your way back to solve might just mean whatever header file had changes in the newer fltk releases was reverted back to a binary compatible release that some old stale .o files were compiled with, so that "bisect solves the problem" might be a red herring.
  

On 12/2/24 14:46, Rob McDonald wrote:

I tried updating to 1.4.1 today and ran into a problem.  I've bisected it down to

3922ef67c1385  Further accelerating Fl_Text_Display (#596)            Matthias Melcher

[..]

[melcher....@googlemail.com]

Without seeing the code that generates the crash, I'll have a will guess here. It seems that [Inlined] fl_font() fl_draw.H:812 is the last running code location. It's possible that you change some widget size based on the width of a string, but the graphics driver is not yet initialized. Please try to call fl_open_display() before you construct the GUI and see if the crash goes away.

FLTK 1.4 is a bit more reluctant to open a display connection unless absolutely necessary. This is really helpful when you write apps that run without GUI as well as in interactive mode, making it possible to run apps on "headless" Linux machines. The disadvantage is, that graphics calls are not available until a window is actually shown (or fl_open_display() is called).

[Rob McDonald]

On Monday, December 2, 2024 at 3:48:06 PM UTC-8 melcher....@googlemail.com wrote:

Without seeing the code that generates the crash, I'll have a will guess here. It seems that [Inlined] fl_font() fl_draw.H:812 is the last running code location. It's possible that you change some widget size based on the width of a string, but the graphics driver is not yet initialized. Please try to call fl_open_display() before you construct the GUI and see if the crash goes away.

FLTK 1.4 is a bit more reluctant to open a display connection unless absolutely necessary. This is really helpful when you write apps that run without GUI as well as in interactive mode, making it possible to run apps on "headless" Linux machines. The disadvantage is, that graphics calls are not available until a window is actually shown (or fl_open_display() is called).

Talk about pulling a rabbit from the hat -- this seems to have fixed the issue!!!

Is 'fl_open_display()' the correct fix, or should I dig deeper?

Off the top of my head, I don't think I set the width of any widget based on the width of a string -- but perhaps it is happening implicitly.

Likewise, I'm building with RelWithDebugInfo settings -- so my debug location might not be 100% accurate.

Interestingly enough, running on headless Linux machines is a design requirement for my code -- but to an extent that we can't assume any graphics libraries are even installed on the machine -- no X, no GL, etc.  So, we actually compile a separate headless binary that does not use any GUI or Graphics code whatsoever.  The entire program has been architected to facilitate this.  The GUI and Graphics code can #include and access the core -- but the core must be able to compile and function without any awareness of the GUI and Graphics stuff at all. 

Thanks,

Rob

  

[Rob McDonald]

On Monday, December 2, 2024 at 3:13:57 PM UTC-8 er...@seriss.com wrote:

Can you replicate any crashes in the test apps?

If not, but sure sounds like your app is building against mismatched versions of fltk, or there are stale .o files compiled against a different version than the new fltk.

To rule out interference between old and new releases, this may sound obvious, but be sure you've:

• Made a clean checkout of 1.4.x current in an empty directory (git clone)
  
• Modified your app to refer to this clean checkout directory
• Do a clean rebuild of your app (making sure no .o's for your app are left over from a previous build of fltk)
• Make sure you're not linking to an old fltk lib
• Make sure there's no old links in /usr/include/FL (pointing to an old or different FLTK version)

Any one of those things could cause a crash in strange places, and bisecting your way back to solve might just mean whatever header file had changes in the newer fltk releases was reverted back to a binary compatible release that some old stale .o files were compiled with, so that "bisect solves the problem" might be a red herring.

My process _should_ pass all these criteria.

That said, none of the test programs I tried so far exhibited the issue.  Is there an easy way to run all the test programs in sequence?

Fortunately, it looks like we're making progress with fl_open_display().

Rob

 

[Albrecht Schlosser]

On 12/3/24 02:47 Rob McDonald wrote:

Is there an easy way to run all the test programs in sequence?

Sure. Using bash:

$ for f in bin/test/* ; do echo "-- $f --"; $f; done
-- bin/test/adjuster --
-- bin/test/animated --
-- bin/test/arc --
-- bin/test/ask --
^C

I'm doing this regularly to check for memory errors in my Address Sanitizer build. In the simplest for you just hit Esc but some programs need a little more "work" to exit.

[Albrecht Schlosser]

On 12/3/24 02:43 Rob McDonald wrote:

I'm building with RelWithDebugInfo settings -- so my debug location might not be 100% accurate.

For bug reports I recommend using CMAKE_BUILD_TYPE=Debug to get full debug info, e.g. when the program really crashes - which is obviously your case here.

I'm glad that you found a solution (with a hint from Matthias).

BTW: lines 811-813 of FL/fl_draw.H are

   811	inline Fl_Font fl_font() {
   812	  return fl_graphics_driver->font();
   813	}

which indicates clearly that something in your program calls fl_font() and that the display has not yet been opened (fl_graphics_driver is presumably NULL).

Here's another guess: if you introduced Fl_Terminal in this program then it's probably something in Fl_Terminal. But that's only a guess...

A simple test would be to run the program under gdb (after building in Debug mode) and issue `bt` when it crashed which should issue a full backtrace with more relevant information like line numbers and perhaps some argument values (NULL).

[Rob McDonald]

I will try a full Debug build when I get a chance -- hopefully it will clear something up.

I updated FLTK trying to sort out my Fl_Simple_Terminal vs. Fl_Terminal issues (which were really just the documentation issues).  Then I ran into this bug.  I too first suspected Fl_Terminal, so the first thing I did was back out all of that.  I reverted to a safe baseline of my program before I bisected the issue.

I do not intentionally or knowingly call fl_font() -- but as we know, without a proper Debug build, we could be losing some things in the Stacktrace I have -- and adding a Tab to a GUI (which I believe is dynamically sized to fit the Label) would logically require calling fl_font() to figure out the label width.

Rob

 

[Rob McDonald]

The full debug build didn't help the stack trace because everything in-between is marked inline, but stepping through until the crash confirmed our current understanding...

I call Fl_Tabs::client_area

Which calls (line 1138 of Fl_Tabs.cxx)

int label_height = fl_height(labelfont(), labelsize()) + BORDER*2;

fl_height() calls (line 461 of fl_draw.cxx )

if ( font == fl_font() && size == fl_size() ) return(fl_height());

Which is the fl_font() call that causes the crash.

I'm satisfied that calling fl_open_display(); is a reasonable fix (though possibly undocumented as a requirement).

I have no idea why the commit I bisected to caused this to occur.

Thanks for all the help,

Rob

[melcher....@googlemail.com]

rob.a.m...@gmail.com schrieb am Dienstag, 3. Dezember 2024 um 09:12:22 UTC+1:

I call Fl_Tabs::client_area

I updated the documentation of this call to clarify the issue. 

I'm satisfied that calling fl_open_display(); is a reasonable fix (though possibly undocumented as a requirement).

Yes, that's the correct thing to do.