Fl_Native_File_Chooser() crash with FLTK 1.4

[Karl Harbinger]

I have the following function in my program:

static int native_file_chooser_gtk(int mode)
{
  int type = (mode == DIR_CHOOSER) ? Fl_Native_File_Chooser::BROWSE_DIRECTORY : Fl_Native_File_Chooser::BROWSE_FILE;

  Fl_Native_File_Chooser fnfc;
  fnfc.title(title);
  fnfc.type(type);
  int ret = fnfc.show();

  if (ret != -1 && ret != 1) {
    std::cout << quote << fnfc.filename() << quote << std::endl;
    return 0;
  }
  return ret;
}

Running this code from the FLTK 1.3 version of my programs works fine, but on the FLTK 1.4 version it crashes saying "free(): invalid pointer".

Here's the output from gdb:

Starting program: /home/djcj/dev/fltk-dialog/fltk-dialog --file --native
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec2d5700 (LWP 29631)]
[New Thread 0x7fffebad4700 (LWP 29632)]
[New Thread 0x7fffeb2d3700 (LWP 29633)]
[New Thread 0x7fffea68b700 (LWP 29634)]
free(): invalid pointer

Thread 1 "fltk-dialog" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.


 

Here are the two branches that have the code from above:

https://github.com/darealshinji/fltk-dialog/tree/fltk-1.3-gtk

https://github.com/darealshinji/fltk-dialog/tree/fltk-1.4

I wanted to switch to FLTK 1.4 but this bug is currently preventing me from it. I really don't know if it's my fault or a bug in FLTK.

OS: Ubuntu 18.04

GCC: 7.3.0

[Antal Ispanovity]

Hi,

the gdb output seems a bit incomplete. It doesn't really show at which
line (instruction) does your application stop. Maybe you ran it in
release mode?
Maybe you can try to compile fltk-1.4 in debug mode and you'll have
more information whether the problem is in fltk's code or in yours.

> --
> You received this message because you are subscribed to the Google Groups
> "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fltkgeneral...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Manolo]

I've just tried FLTK 1.4 test/native-filechooser under Ubuntu 18.04 and it runs well.

It's thus tempting to suggest the problem is not in FLTK.

The code you present does not define the variable title. Could that be the problem?

[Karl Harbinger]

After removing nearly all components from my program it works. Now I'm seriously confused as to what the actual problems is, especially since it runs well with FLTK 1.3.

[Karl Harbinger]

When I run the Qt file chooser I get the same error:

Gtk-Message: 18:26:08.632: GtkDialog mapped without a transient parent. This is discouraged.
free(): invalid pointer

The stuff that dlopen()s gtk and libappindicator as well as loading a plugin with Qt indicator support works. Dlopen of libnotify works too.

Totally weird, and I seriously never had these issues with FLTK 1.3.

[Karl Harbinger]

Update: I thought it could have something to do with FLTK 1.4 being built against Pango, but even with Pango set to OFF the same happens.

[Paul Douglas Hahn]

Sometimes mysterious things like this are the result of memory trashing. A clue to that possibility is that you said in a previous message that you removed nearly all other components in your program and it works. I suggest you could try using valgrind on your program (with all components/ functionality in place again) if you haven't done so already. :-)

Regards,
Paul

On 2/27/19 2:04 PM, Karl Harbinger wrote:

Update: I thought it could have something to do with FLTK 1.4 being built against Pango, but even with Pango set to OFF the same happens.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

[Karl Harbinger]

Thanks, for the hint, I think I found the issue.

I was always using the latest libpng from my own fork/copy of FLTK 1.3.4, but when I checked FLTK 1.4 I used the older bundled libpng version.

It seems to be an issue inside libpng that was fixed in newer versions. When I link against the system's libpng nothing bad happens.

I will do some further testing, but anyway, I'd suggest to A) update the bundled libraries to the latest stable releases and B) use a unique symbol prefixing for extra insurance.

Here are patches I used to do the symbol prefixing in FLTK 1.3.4: https://github.com/darealshinji/fltk-1.3.4/tree/master/patches

Addendum:

Updating the PNG files gives me a different error:

munmap_chunk(): invalid pointer

[Karl Harbinger]

This is really frustrating me. Creating portable, statically linked apps on Windows doesn't seem to be as much of a problem (with and without FLTK).

[Albrecht Schlosser]

On 28.02.2019 08:21 Karl Harbinger wrote:
> Thanks, for the hint, I think I found the issue.
> I was always using the latest libpng from my own fork/copy of FLTK
> 1.3.4, but when I checked FLTK 1.4 I used the older bundled libpng version.
> It seems to be an issue inside libpng that was fixed in newer versions.

Are you sure? See below why I doubt that this is true.

> When I link against the system's libpng nothing bad happens.

(1) OK, that's important. See below why.

> I will do some further testing, but anyway, I'd suggest to A) update the
> bundled libraries to the latest stable releases and B) use a unique
> symbol prefixing for extra insurance.
> Here are patches I used to do the symbol prefixing in FLTK 1.3.4:
> https://github.com/darealshinji/fltk-1.3.4/tree/master/patches

I'm not sure that either of these are a general solution to your
problem, because:

(2) Regarding (A): See below.

(3) Regarding (B): See below.

> Addendum:
> Updating the PNG files gives me a different error:
> munmap_chunk(): invalid pointer

This supports my assumption: you are likely mixing two different
versions of libpng (and maybe other libs) in one application. This is
particularly problematic since most (if not all) libraries define some
structs or objects like FLTK in their header files. If these
structs/objects differ between library versions and you compiled
different parts of your program with different versions of the headers,
then trouble is certain.

Now back to points (1) to (3):

(1) This again supports my assumption that you're mixing different
libpng versions. This means that your program uses (and links to)
another version of libpng than the FLTK library was compiled with (i.e.
the bundled libpng). This can be caused by using an image library that
was compiled and linked (supposedly) to a shared libpng.so.

(2) Updating to the latest version of libpng wouldn't solve the "mixing
libraries" issue because other linked libraries may still use other
(older) versions of the library. And after FLTK was released there may
be a new (libpng) library version released just a day later.

(3) The need to use a "prefixed" libpng version inside the FLTK library
also supports the thesis that you are mixing two (png) libraries.
Otherwise you wouldn't need to prefix the bundled png, zlib, and jpeg
libraries.

That all said, I saw STR #3347 for image library prefixing but I'm not
sure that this is a suitable solution. I didn't close the STR though
("will not fix") because ... yes, I was not sure. :-(

But I tend to close it because it would only hide symptoms but not fix
anything. It would only make the FLTK code (and the bundled libs) harder
to maintain (upgrade to new upstream versions) and wouldn't help to
resolve real problems, i.e. one should rather improve the application's
build system to avoid using different libary versions.

Hence I suggest to use a "proper" solution in the first place. If you're
using another version of libpng and other libs, don't use the image libs
bundled with FLTK. As you wrote above this worked for you with FLTK 1.4.
This should also work well if you use FLTK 1.3.

If this wouldn't work - maybe because FLTK uses an older image library
API that was deprecated and later removed upstream - then this would be
a bug in FLTK's image handling code and should be fixed.

When I developed a cross platform application with image libs I made
sure that we were using the same image libs for the entire application.
This meant to (a) use the (shared) system image libs where available
(Linux) and (in our case) (b) building the image libs ourselves on
systems that didn't provide them (Windows). Option (a) would also have
been an option on Linux but only if the app didn't use other shared
image or compression (zlib) libs.

I apologize if this long post didn't hit the point but I wrote it anyway
in the hope that it will help you and maybe others.

[Manolo]

OK. I can replicate what you report under Ubuntu with test/native-filechooser.

If FLTK is built using default options regarding liibpng, the system's version of libpng is used,

lib/libfltk_png.a is not created, and test/native-filechooser runs well.

Notice that even an FLTK app that does not need libpng obviously (such as test/hello)

finds itself using libpng (as shown by the ldd command). It turns out that libXft calls

libpng somewhere, because if FLTK is built without Xft, test/hello no longer uses libpng.

If FLTK is built forcing it to use the version of libpng bundled in FLTK,

test/native-filechooser crashes with the 'free() invalid pointer' error message.

The cause here is that 2 libpng versions are called in, one from lib/libfltk_png.a,

one from the OS linked in by other libraries such as libXft, and these do not

cohabit well.

Because the user can't control whether some dynamic libraries called in (e.g., libXft,

libpango) do or don't call in the OS version of libpng, it's necessary to build FLTK

so that it uses the OS libpng rather than the FLTK png version.

A problem arises for portable applications built on an old linux version that can't run

on some newer linux versions because there are some incompatibilities between some

versions of libpng.so.

[Albrecht Schlosser]

On 28.02.2019 10:09 Karl Harbinger wrote:
> This is really frustrating me. Creating portable, statically linked apps
> on Windows doesn't seem to be as much of a problem (with and without FLTK).

You can't avoid to include shared libraries on either system hence a
completely statically linked app is not possible. The difficulties you
saw were likely created because Linux includes shared png and zlib
libaries and headers but Windows does not.

Did you ever read about (or experience) the "DLL hell"?
https://en.wikipedia.org/wiki/DLL_Hell

Interesting stuff, but not everything may still apply (16-bit systems,
Windows 3.1 etc.).

[Albrecht Schlosser]

On 28.02.2019 11:22 Manolo wrote:
> OK. I can replicate what you report under Ubuntu with
> test/native-filechooser.

> ...

> Notice that even an FLTK app that does not need libpng obviously (such
> as test/hello)
> finds itself using libpng (as shown by the ldd command). It turns out
> that libXft calls
> libpng somewhere, because if FLTK is built without Xft, test/hello no
> longer uses libpng.

Wow, that's a great finding!

To support it, here's an excerpt of 'ldd .../libXft.so.2' on my Ubuntu
18.04 system:

$ ldd /usr/lib/x86_64-linux-gnu/libXft.so.2
...
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x...)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x...)
...

> Because the user can't control whether some dynamic libraries called
> in (e.g., libXft, libpango) do or don't call in the OS version of
> libpng, it's necessary to build FLTK so that it uses the OS libpng
> rather than the FLTK png version.

Well, maybe we should disallow to use the bundled image libs if FLTK is
built with Xft because they are not (guaranteed to be) compatible. At
least this would be true for libpng and zlib.

libjpeg would be different but IIRC there exist different libjpeg
versions so that this would likely be an issue as well.

Maybe we should even disable all bundled image libs under Linux but this
might break other "simple" apps that use the bundled libs, particularly
if they don't use Xft. Hard to say what would be the best...

[Albrecht Schlosser]

On 28.02.2019 11:49 Albrecht Schlosser wrote:
> On 28.02.2019 11:22 Manolo wrote:
>> OK. I can replicate what you report under Ubuntu with
>> test/native-filechooser.
>> ...

> ... here's an excerpt of 'ldd .../libXft.so.2' on my Ubuntu

> 18.04 system:
>
> $ ldd /usr/lib/x86_64-linux-gnu/libXft.so.2
> ...
>     libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x...)
>     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x...)
> ...
>

> Well, maybe we should disallow to use the bundled image libs if FLTK is
> built with Xft because they are not (guaranteed to be) compatible. At
> least this would be true for libpng and zlib.

FTR: I filed STR 3514 so this will not get lost:
https://www.fltk.org/str.php?L3514

[Karl Harbinger]

The thing is: I want my tool to be as portable as possible without the need to create an AppImage or a tarball that includes all dependencies.

I guess this means I will have to add my own copy of jpeg, png and zlib with prefixed symbols and make sure those are used.

[w1hkj]

I build and distribute several FLTK based audio processing applications (http://www.w1hkj.com) targeting Unix, Linux, Puppy-linux, OS-X (both G4, i386 and x64 dmgs) and all Windows versions XP...10.  Linux and Unix users are usually capable of building from source.  All of the other targets are static builds and never use any dependent shared libraries.  The supporting libraries are built as static, and that includes FLTK and it's dependent libs.  Xft is always a part of the build.  That is required if you do not want really horrible looking font renditions.  I have not had any issues with dll hell in over 15 years of distributing Windows executables.

Native file selectors are used on all targets.  You might want to look at the source for either fldigi or flmsg

http://www.w1hkj.com/files/fldigi
http://www.w1hkj.com/files/flmsg

for example code.

David, W1HKJ

On 2/28/19 8:00 AM, Karl Harbinger wrote:

The thing is: I want my tool to be as portable as possible without the need to create an AppImage or a tarball that includes all dependencies.

I guess this means I will have to add my own copy of jpeg, png and zlib with prefixed symbols and make sure those are used.

[w1hkj]

I should have added that the Windows targets are cross compiled on a Linux host.

David

[Karl Harbinger]

Sometimes people want to provide portable closed-source apps. For such a case the prefixed symbols are useful.

Besides, building FLTK with prefixed image library symbols isn't impossible, it's just extra work you have to do by yourself.

png and zlib provide build options for that and for jpeg you can create a header file on the fly that does the same.

[Albrecht Schlosser]

On 02.03.2019 12:25 Karl Harbinger wrote:
> Sometimes people want to provide portable closed-source apps. For such a
> case the prefixed symbols are useful.

I understand.

> Besides, building FLTK with prefixed image library symbols isn't
> impossible, it's just extra work you have to do by yourself.
> png and zlib provide build options for that and for jpeg you can create
> a header file on the fly that does the same.

The image libraries bundled with FLTK are just for convenience, let's
say if you want to build a toy image display program under Windows which
lacks system image libraries. We can never guarantee that the version of
these libs is up-to-date, hence using them for professional or any other
"serious" (closed source) programs is discouraged.

If you need prefixed image libraries whose versions you can control
(which would IMHO be a prerequisite for a closed-source application)
then you should keep your own copy of the image libs and patch them such
that they can use any prefix you want.

Then you could build FLTK using these image libraries and link your
application with the same image libraries. Since all prefixing happens
by defining some macros in the libary headers this should work w/o
patching the FLTK library.

Please correct me if I'm wrong.

[Karl Harbinger]

Am Samstag, 2. März 2019 12:50:17 UTC+1 schrieb Albrecht Schlosser:

If you need prefixed image libraries whose versions you can control
(which would IMHO be a prerequisite for a closed-source application)
then you should keep your own copy of the image libs and patch them such
that they can use any prefix you want.

Then you could build FLTK using these image libraries and link your
application with the same image libraries. Since all prefixing happens
by defining some macros in the libary headers this should work w/o
patching the FLTK library.

Please correct me if I'm wrong.

You're right, that does work indeed, at least with CMake where you can specify each library and include directory manually.

You don't even need to patch the image libraries. png and zlib already have options to enable prefixing, and for jpeg you

can create such a header file and add it to your build flags with -include.

I'm currently doing it, not because I'm working on a closed-source project but more for convenience and to see if it works.

[Albrecht Schlosser]

On 02.03.2019 15:06 Karl Harbinger wrote:
> Am Samstag, 2. März 2019 12:50:17 UTC+1 schrieb Albrecht Schlosser:
>
> If you need prefixed image libraries whose versions you can control
> (which would IMHO be a prerequisite for a closed-source application)
> then you should keep your own copy of the image libs and patch them
> such
> that they can use any prefix you want.
>
> Then you could build FLTK using these image libraries and link your
> application with the same image libraries. Since all prefixing happens
> by defining some macros in the libary headers this should work w/o
> patching the FLTK library.
>
> Please correct me if I'm wrong.
>
> You're right, that does work indeed, at least with CMake where you can
> specify each library and include directory manually.
> You don't even need to patch the image libraries. png and zlib already
> have options to enable prefixing, and for jpeg you
> can create such a header file and add it to your build flags with -include.

Sounds great, thanks for the feedback!

> I'm currently doing it, not because I'm working on a closed-source
> project but more for convenience and to see if it works.

Looking forward to your results.

[Karl Harbinger]

I guess you can close STR #3347

Am Samstag, 2. März 2019 15:17:33 UTC+1 schrieb Albrecht Schlosser:

> I'm currently doing it, not because I'm working on a closed-source
> project but more for convenience and to see if it works.

Looking forward to your results.

https://github.com/darealshinji/fltk-dialog/tree/fltk-1.4

I might merge it with the master branch and delete the "fltk-1.4" tree later (so you know in case the link isn't working anymore).

[Albrecht Schlosser]

On 02.03.2019 18:33 Karl Harbinger wrote:
> I guess you can close STR #3347

Thanks, done.

[Karl Harbinger]

Seems like I'm still encountering issues with Gtk, depending on the platform I build and run it.

I guess I have to stick with patching the image library sources, if I really want to keep the automated builds.

[Gonzalo Garramuno]

On Sunday, March 3, 2019 at 4:04:18 PM UTC-3, Karl Harbinger wrote:

Seems like I'm still encountering issues with Gtk, depending on the platform I build and run it.

I guess I have to stick with patching the image library sources, if I really want to keep the automated builds.

I am also finding crahes with the fltk1.4 native file chooser.  In my case, I was able to reproduce the crash with the default native-chooser demo by changing the filters.   Here is my file attached.

[Gonzalo Garramuño]

El 11/3/19 a las 19:38, Gonzalo Garramuno escribió:

I was able to solve it.  The filter syntax in fltk1.4 is different than in 2.0.  That was causing havok.