What does the "fluid-cmd" exe do on the WIN32 builds?

9 views
Skip to first unread message

Ian MacArthur

unread,
Oct 1, 2022, 8:00:16 AM10/1/22
to coredev fltk
All,

So, what *does* fluid-cmd.exe do?
It gets built by the cmake builds on Windows (the Makefile build doesn’t seem to build it?) but I cannot tell what it does - I can’t read cmake files very well, but it seems to be built out of the same things as “regular” fluid... and..?

Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...

Builds on other 32-bit machines didn’t show the issue, until I did a make clean, so when it then had to regenerate the various .fl files in the test directory, they too hang.

64-bit mingw builds appear to be immune (I need to check that properly though!) as did my recent msvc 32-bit IDE build.

What is it, what’s it for, how/why is it different from “regular” fluid, etc.?
And why does it hang?


Albrecht Schlosser

unread,
Oct 1, 2022, 8:32:23 AM10/1/22
to fltkc...@googlegroups.com
On 10/1/22 14:00 Ian MacArthur wrote:
> All,
>
> So, what *does* fluid-cmd.exe do?
> It gets built by the cmake builds on Windows (the Makefile build doesn’t seem to build it?) but I cannot tell what it does - I can’t read cmake files very well, but it seems to be built out of the same things as “regular” fluid... and..?

The only difference is that it's a Windows Console (-mconsole) rather
than a Windows GUI (-mwindows) executable. This was done on request (by
Greg) because some fluid issues (e.g. not being able to access remote
file systems or other errors) would not display an error message if
built as GUI exe as it was before.

> Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...

Sigh. This is something I experienced as well but it is not related to
using fluid vs. fluid-cmd. I had this issue before and after the
modification, and it happens sometimes but not every time I build FLTK
with MinGW (MSYS2/mingw-w64 to be precise). I wonder if it has something
to do with virus checking (Windows Defender) but I could never find it
out. I tried to add a Defender exception but this didn't really work. I
can usually see lots of CPU activity related to "virus checking" or
whatever its name is while I'm building FLTK - unless I disable online
virus checking entirely while building FLTK. Virus checking of the FLTK
build is a PITA anyway (steals way too much CPU time and probably also
disk activity).

Back to the original issue:
The symptoms are that some fluid instances seem to hang forever *after*
the output files were written. If you build with `make -j3` it may
happen that you have three (3) hanging fluid instances and then the
build stalls. If you kill these fluid instances via the task manager the
build continues but may hang later again. It's indeterminate AFAICT. I'm
not sure if disabling virus checking really helps, I don't have enough
test data.

When I experienced this issue first I terminated the build with ctrl/c
and ran it again which continued often till the end. Hence this might
help you too, but killing fluid instances via task manager was the most
stable procedure for me so far. That said, my build about one hour ago
executed successfully w/o hangs. Random, or should I say "Windows"?

> Builds on other 32-bit machines didn’t show the issue, until I did a make clean, so when it then had to regenerate the various .fl files in the test directory, they too hang.
>
> 64-bit mingw builds appear to be immune (I need to check that properly though!) as did my recent msvc 32-bit IDE build.

I'm not sure but I would guess that this doesn't have to do with 32- vs.
64-bit. It might have to do with MSYS2/MinGW though. I never experienced
such hangs in VS IDE build (VS 2019).

> What is it, what’s it for, how/why is it different from “regular” fluid, etc.?
> And why does it hang?

See above. It should not make a difference and it did not for me. Other
Windows/MSYS2 magic seems to cause these hangs but I have no idea how to
debug this (other than printf statements in fluid, maybe).

imm

unread,
Oct 1, 2022, 9:23:59 AM10/1/22
to fltkc...@googlegroups.com
On Sat, 1 Oct 2022 at 13:32, Albrecht Schlosser wrote:
>
> The only difference is that it's a Windows Console (-mconsole) rather
> than a Windows GUI (-mwindows) executable. This was done on request (by
> Greg) because some fluid issues (e.g. not being able to access remote
> file systems or other errors) would not display an error message if
> built as GUI exe as it was before.

Ah, OK.
Well, annoyingly, that's a "feature" of the DOS shell, that it drops
the stdio handles for GUI applications; the Msys shell does not, so
you still get stdio to the console on GUI applications, if you run
them from an Msys shell.

So I'd probably never seen the behaviour that Greg was seeing - and
conversely, he probably never sees the behaviour I see!


> > Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...
>
> Sigh. This is something I experienced as well but it is not related to
> using fluid vs. fluid-cmd. I had this issue before and after the
> modification, and it happens sometimes but not every time I build FLTK
> with MinGW (MSYS2/mingw-w64 to be precise). I wonder if it has something
> to do with virus checking (Windows Defender) but I could never find it
> out. I tried to add a Defender exception but this didn't really work. I
> can usually see lots of CPU activity related to "virus checking" or
> whatever its name is while I'm building FLTK - unless I disable online
> virus checking entirely while building FLTK. Virus checking of the FLTK
> build is a PITA anyway (steals way too much CPU time and probably also
> disk activity).

OK - well, knowing that it is not just me is useful!
If it is a virus scanner side-effect, it is not just Defender, as I
have seen the same behaviour on machines "protected" by
McAfee/Trellix/whatever-it-is-called-now too.

Greg Ercolano

unread,
Oct 2, 2022, 2:05:06 AM10/2/22
to fltkc...@googlegroups.com

On 10/1/22 05:32, Albrecht Schlosser wrote:

On 10/1/22 14:00 Ian MacArthur wrote:
All,

So, what *does* fluid-cmd.exe do?
It gets built by the cmake builds on Windows (the Makefile build doesn’t seem to build it?) but I cannot tell what it does - I can’t read cmake files very well, but it seems to be built out of the same things as “regular” fluid... and..?

The only difference is that it's a Windows Console (-mconsole) rather than a Windows GUI (-mwindows) executable. This was done on request (by Greg) because some fluid issues (e.g. not being able to access remote file systems or other errors) would not display an error message if built as GUI exe as it was before.

    Yes, though more importantly: the Makefile would not get a proper exit code from fluid
    when it failed, causing a build invoking e.g. 'fluid -c foo.fl' to sail right through
    even if the creation of .cxx/.h failed due to a write error.

    This is super bad in a production environment, where build errors MUST stop the build,
    otherwise build errors would go undetected.

    In my case I was building a 3rd party app in a context where the .cxx/.h files had
    weird network permissions (ACLs vs unix chmod), preventing them from being overwritten
    by fluid, causing stale .cxx/.h files to remain behind after fluid finished, and since the Makefile
    never saw an exit code, caused the old code in the new binary, causing old behavior in new
    releases. This was BAD BAD BAD.


Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...

    Hmm, I'd be curious what fluid-cmd's were being invoked (was it the -c flag? e.g. "fluid-cmd -c xyz.fl"?)

    For sure that should just write out files, print errors to stdout/err and /exit/, and not pop any GUI dialogs
    so as to prevent any kind of interaction with the GUI, esp. in a parallel processing context where several
    might run at once, such as from a parallel make.

    fluid should be avoiding ANY gui calls during a -c operation; all -c flag handling in main()
    should precede any initialization or use of FLTK calls.

    Hopefully there's no global window manager stuff being triggered before main() in fluid,
    otherwise there might be contention with the window manager in a parallel build
    scenario, where two or more fluids run at once, contending for the window manager
    and blocking each other. I hope that's not the case.


What is it, what’s it for, how/why is it different from “regular” fluid, etc.?
And why does it hang?

See above. It should not make a difference and it did not for me. Other Windows/MSYS2 magic seems to cause these hangs but I have no idea how to debug this (other than printf statements in fluid, maybe).

    I'd probably suggest attaching a debugger to one of the hung processes
    to see what it's stuck executing.

    If it's hung during a -c command in window manager stuff, then we may have
    to move the -c option to a separate binary that doesn't link with fltk, just so
    it can be a purely 'headless' command line tool.

   

Albrecht Schlosser

unread,
Oct 2, 2022, 8:58:38 AM10/2/22
to fltkc...@googlegroups.com
On 10/2/22 08:05 Greg Ercolano wrote:

On 10/1/22 05:32, Albrecht Schlosser wrote:

On 10/1/22 14:00 Ian MacArthur wrote:

The only difference is that it's a Windows Console (-mconsole) rather than a Windows GUI (-mwindows) executable. This was done on request (by Greg) because some fluid issues (e.g. not being able to access remote file systems or other errors) would not display an error message if built as GUI exe as it was before.

    Yes, though more importantly: the Makefile would not get a proper exit code from fluid
    when it failed, causing a build invoking e.g. 'fluid -c foo.fl' to sail right through
    even if the creation of .cxx/.h failed due to a write error.

Oh, thanks, I didn't know that fact.


Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...

    Hmm, I'd be curious what fluid-cmd's were being invoked (was it the -c flag? e.g. "fluid-cmd -c xyz.fl"?)

During the build only `fluid-cmd -c xxx.fl` commands are executed.

    For sure that should just write out files, print errors to stdout/err and /exit/, and not pop any GUI dialogs
    so as to prevent any kind of interaction with the GUI, ...


    fluid should be avoiding ANY gui calls during a -c operation; all -c flag handling in main()
    should precede any initialization or use of FLTK calls.

    Hopefully there's no global window manager stuff being triggered before main() in fluid,
    otherwise there might be contention with the window manager in a parallel build
    scenario, where two or more fluids run at once, contending for the window manager
    and blocking each other. I hope that's not the case.

... And why does it hang?

... I have no idea how to debug this (other than printf statements in fluid, maybe).

    I'd probably suggest attaching a debugger to one of the hung processes
    to see what it's stuck executing.

I know that this is possible but I never tried this. Seems like something I need to learn so I can try this the next time my build hangs in fluid-cmd. Or maybe Ian, could you try it in your situation?



    If it's hung during a -c command in window manager stuff, then we may have
    to move the -c option to a separate binary that doesn't link with fltk, just so
    it can be a purely 'headless' command line tool.

This is something Matt did always take care of and I test this from time to time. It's easy to test in a "normal" (non-wayland) build on Linux by deassigning the DISPLAY environment variable, e.g. in bash:

$ unset DISPLAY
$ cd fluid
$ ./fluid -c about_panel.fl 
$

You can test this yourself. If fluid (or fluid-cmd) returns w/o error message it works, obviously w/o opening the display. If you run `fluid` only you'll see the error message:

$ ./fluid  
Can't open display:  
$

Note: for a wayland (hybrid) build you'd have to assign FLTK_BACKEND=x11 to enforce the x11 backend.

Although we're talking in this thread about Windows it shouldn't be different on that platform. I don't know how to *verify* this on Windows though other than adding printf's (or setting a breakpoint in a debugger) at appropriate places in the code.

Reply all
Reply to author
Forward
0 new messages