pyfltk-user — Mailing list for the discussion of pyFLTK related issues.

Re: [Pyfltk-user] Mystery swig error when exiting pyfltk program

[Andreas H. <and...@bl...>]

Hi Dima

I now got a better understanding of this error, but still no real 
solution. The problem as I can see it is that there are two Swig modules 
present. Each Swig module has a pointer to a global data structure 
containing all the swig type info: swig_module->types

When cleaning up, the function SWIG_Python_DestroyModule is called which 
deallocates the type info. If this is called before the destructor of 
the Fl_Window is called, then the error you are seeing is shown, because 
part of the information needed to cleanly deallocate the Fl_Window 
structure is contained in the type info and is now missing. As I see it, 
this is basically a race condition between the two modules. Besides the 
factors you have mentioned, also exchanging the import order of fltk and 
Fl_Gl_Image_Widget seems to resolve the problem. In that case, 
deallocation of the type info is done by the fltk module, properly after 
deallocating the Fl_Window.

Long story short, at the moment I see no possibility to really fix this.

Best regards

Andreas

On 6/27/25 00:18, Dima Kogan wrote:
> Hello!
>
> Can one of you help debugging a mystery error please? I have this
> script, that does more-or-less nothing:
>
>    import Fl_Gl_Image_Widget
>    from fltk import *
>
>    def func():
>        5
>
>    window = Fl_Window(100,200,"xxx")
>    window.end()
>    window.show()
>
>    Fl.run()
>
> I run it, the window pops up, I press Escape, the application exits.
> This is right. But as it exits it prints to the console:
>
>    swig/python detected a memory leak of type 'Fl_Window *', no destructor found.
>
> Does this mean something to any of you? I can make this message go away
> by doing unrelated-looking things. I can remove the definition of func()
> above (which doesn't do anything anyway). Or I can remove the "import
> Fl_Gl_Image_Widget" (which also doesn't do anything). Doing any of these
> silences the error.
>
> This is on a very recent Debian, running everything from packages:
>
>    dima@shorty:~/projects/mrcam$ dpkg -l python3-fltk python3-gl-image-display libfltk1.4
>    ii  python3-fltk:amd64       1.4.2.0-2    amd64        Python wrapper for the Fast Light Toolkit
>    ii  python3-gl-image-display 0.23-1       amd64        OpenGL-based image visualizer
>    ii  libfltk1.4:amd64 1.4.3-1      amd64        Fast Light Toolkit - main shared library
>
> I just upgraded libfltk1.4 from 1.4.2-7; it made no difference.
>
> python3-gl-image-display is mine:
>
>    https://github.com/dkogan/GL_image_display
>
> It also uses swig. Note that here I'm just doing the import; I'm NOT
> actually using it.
>
> Suggestions? Since unrelated-looking things make the problem disappear
> for me, I wouldn't be surprised if yall have trouble reproducing.
>
> Suggestions?
>
> Thanks!
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

Re: [Pyfltk-user] measure_label

[RJ A. <rj....@gm...>]

Hi Matthias,

That's great news. Thank you.
I'm away until Thursday but I will test and commit this change when I get
back home. BTW thank you for clearly explaning how this function works.


On Wed, Jul 2, 2025, 3:13 a.m. Matthias Melcher <mm...@ma...> wrote:

>
>
>
> Awesome. I am learning swig as we go ;-)
>
>
> So in the file `swig/Fl_Widget.i`
>
>  - insert the following line 50 before %include "FL/Fl_Widget.H"
>
> %ignore measure_label(int& ww, int& hh);
>
>
>  - and starting at line 61 after #include <FL/Fl_Image.H>
>
>
> %apply int *OUTPUT { int *w_ret };
> %apply int *OUTPUT { int *h_ret };
> void measure_label(int w, int h, int *w_ret, int *h_ret) const {
>   self->measure_label(w, h);
>   if (w_ret) *w_ret = w;
>   if (h_ret) *h_ret = h;
> }
>
>  - tested and working, Matthias
>
>
>
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user
>

Re: [Pyfltk-user] measure_label

[Matthias M. <mm...@ma...>]

Awesome. I am learning swig as we go ;-)


So in the file `swig/Fl_Widget.i`

 - insert the following line 50 before %include "FL/Fl_Widget.H"

%ignore measure_label(int& ww, int& hh);


 - and starting at line 61 after #include <FL/Fl_Image.H>


%apply int *OUTPUT { int *w_ret };
%apply int *OUTPUT { int *h_ret };
void measure_label(int w, int h, int *w_ret, int *h_ret) const {
  self->measure_label(w, h);
  if (w_ret) *w_ret = w;
  if (h_ret) *h_ret = h;
}

 - tested and working, Matthias

Re: [Pyfltk-user] measure_label

[Andreas K. <an...@ke...>]

Hi Robert,

perhaps more like
fl_measure() in fl_draw.i. But there it is more complex,
some %ignore, some undo the ignore, another prototype.

I am also not very familiar with Swig.

Regards,
Andreas

Am Tue, 1 Jul 2025 11:24:22 -0700
schrieb Robert Arkiletian <ro...@gm...>:

> Hi Mr. Kemnade,
> 
> We have not yet implemented the widget.measure_label method typemap in
> the swig interface files. Andreas H. usually does this work. I tried
> it myself by adding
> %apply int* OUTPUT { int& ww, int& hh };
> to swig/Fl_Widget.i
> and rebuilding, but it failed as I'm not very familiar with Swig. We
> will put this on our radar for the next release if possible. If you
> can figure out how to patch the swig interface files to make it work,
> please let us know.
> 
> The part I'm a little confused about is that the FLTK documentation
> states that measure_label is a set method but to me it really seems
> like a get method by reference.
> Here is a snippet example of how it's used in C++ from src/Fl_File_Chooser.cxx
> 
> void Fl_File_Chooser::ok_label(const char *l) {
>  if (l) okButton->label(l);
>  int w=0, h=0;
>  okButton->measure_label(w, h);
>  okButton->resize(cancelButton->x() - 50 - w, cancelButton->y(),
>                   w + 40, 25);
>  okButton->parent()->init_sizes();
> }
> 
> On Mon, Jun 30, 2025 at 2:45 AM Andreas Kemnade <an...@ke...> wrote:
> >
> > Hi,
> >
> > I wonder a bit how the measure_label method should be used.
> > Intuitively according to  https://www.swig.org/Doc1.3/Arguments.html in
> > the genwinsize example I would expect
> > w,h = widget.measure_label()
> >
> > but that does not work. So what is the right way?
> >
> > Regards,
> > Andreas
> >
> >
> > _______________________________________________
> > Pyfltk-user mailing list
> > Pyf...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyfltk-user  
> 

Re: [Pyfltk-user] measure_label

[Matthias M. <mm...@ma...>]

> On 1. Jul 2025, at 20:24, Robert Arkiletian <ro...@gm...> wrote:
> 
> The part I'm a little confused about is that the FLTK documentation
> states that measure_label is a set method but to me it really seems
> like a get method by reference.

Fl_Label::measure(int &width, int &height)


When you call it, `width` is the preferred width in pixels where FLTK will word-wrap the label text. Depending on the width, the height will change if the text actually wraps at some horizontal position once or multiple times. If width is 0, FLTK does not use word wrapping.

When returning, width is the actual width of the output. If width was 0 on input, it will be the width of the entire string. Height will be the font height, multiplied with the number of newlines and wordwraps.

Maybe this works?

%apply int *INOUT { int &W };
%apply int *OUTPUT { int &H };
void Fl_Label::measure(int& W, int& H) const;

or

void Fl_Label::measure(int& INOUT, int& OUTPUT) const;

or write a wrapper that is easy to translate:

void Fl_Label_measure(Fl_Label *self, int w, int *INOUT, int *OUTPUT) const;


Apologies for the guess work. I know FLTK, but very little SWIG.

Re: [Pyfltk-user] measure_label

[Robert A. <ro...@gm...>]

Hi Mr. Kemnade,

We have not yet implemented the widget.measure_label method typemap in
the swig interface files. Andreas H. usually does this work. I tried
it myself by adding
%apply int* OUTPUT { int& ww, int& hh };
to swig/Fl_Widget.i
and rebuilding, but it failed as I'm not very familiar with Swig. We
will put this on our radar for the next release if possible. If you
can figure out how to patch the swig interface files to make it work,
please let us know.

The part I'm a little confused about is that the FLTK documentation
states that measure_label is a set method but to me it really seems
like a get method by reference.
Here is a snippet example of how it's used in C++ from src/Fl_File_Chooser.cxx

void Fl_File_Chooser::ok_label(const char *l) {
 if (l) okButton->label(l);
 int w=0, h=0;
 okButton->measure_label(w, h);
 okButton->resize(cancelButton->x() - 50 - w, cancelButton->y(),
                  w + 40, 25);
 okButton->parent()->init_sizes();
}

On Mon, Jun 30, 2025 at 2:45 AM Andreas Kemnade <an...@ke...> wrote:
>
> Hi,
>
> I wonder a bit how the measure_label method should be used.
> Intuitively according to  https://www.swig.org/Doc1.3/Arguments.html in
> the genwinsize example I would expect
> w,h = widget.measure_label()
>
> but that does not work. So what is the right way?
>
> Regards,
> Andreas
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

Re: [Pyfltk-user] measure_label

[Matthias M. <mm...@ma...>]

Not sure how it is implemented, but in C++ FLTK, 'w' is an in.out parameter. So you need to pass the preferred with with w, and it will return the actual width.

For Python, I would expect something line `w,h = widget.measure_label(w)`. For reference, `fl_measuer(...)` is pretty much the same call. Can you see how that one is called?


> On 30. Jun 2025, at 11:29, Andreas Kemnade <an...@ke...> wrote:
> 
> Hi,
> 
> I wonder a bit how the measure_label method should be used.
> Intuitively according to  https://www.swig.org/Doc1.3/Arguments.html in
> the genwinsize example I would expect
> w,h = widget.measure_label()
> 
> but that does not work. So what is the right way?
> 
> Regards,
> Andreas

Re: [Pyfltk-user] Quitting a pyfltk application with Ctrl-c

[Dima K. <di...@se...>]

That certainly sounds reasonable. Another data point: I tried replacing
SET_SIGINT/RESET_SIGINT with
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS. That did not work. Perhaps
that's only useful for non-main threads.

[Pyfltk-user] measure_label

[Andreas K. <an...@ke...>]

Hi,

I wonder a bit how the measure_label method should be used.
Intuitively according to  https://www.swig.org/Doc1.3/Arguments.html in
the genwinsize example I would expect
w,h = widget.measure_label()

but that does not work. So what is the right way?

Regards,
Andreas

Re: [Pyfltk-user] Quitting a pyfltk application with Ctrl-c

[Dima K. <di...@se...>]

Here's a patch.

Makes Fl::run() use the default SIGINT handler, which makes things exit
quickly and nicely, as is expected. It completely ignores existing
SIGINT handlers, which maybe is wrong, but that's the mess Python made.
Maybe we should remove the %rename line, to leave the Fl.run() alone,
but give us a new Fl.run_with_default_SIGINT() to use as an option? Also
should handle Fl.wait() and maybe a few others.

Re: [Pyfltk-user] Quitting a pyfltk application with Ctrl-c

[Dima K. <di...@se...>]

Robert Arkiletian <ro...@gm...> writes:

> Also tried it with tkinter (built-in python gui). Tkinter does NOT
> kill the process until you switch focus back to the gui window.

OK. Tkinter is bugged too, it looks like


> I am, however, skeptical that this issue should be the responsibility
> of pyfltk to fix.

I don't know whose "responsibility" it is. But currently the
applications don't work right and pyfltk can fix it. So... maybe we
should? To be clear, it's not obvious to me what specifically the fix
would be. But currently it's not right.


> BTW are you trying to send a pyfltk process SIGINT from another
> process (IPC)?

I'm just pressing Ctrl-c in the console.

Re: [Pyfltk-user] Mystery swig error when exiting pyfltk program

[Dima K. <di...@se...>]

Andreas Held <and...@bl...> writes:

> what is the intention of calling window.end() before window.show()?

This tells fltk that we're done adding widgets to the window. Isn't that
the normal way to do it? The samples do that:

  https://github.com/fltk/fltk/blob/master/examples/howto-text-over-image-button.cxx
  https://github.com/fltk/fltk/blob/master/examples/tree-simple.cxx

Re: [Pyfltk-user] Mystery swig error when exiting pyfltk program

[Andreas H. <and...@bl...>]

Hi Dima and Robert

I can also reproduce the problem here. All I can say at the moment is 
that it happens in the function  SwigPyObject_dealloc and that it seems 
to be a kind of race condition. It could well be related to the previous 
issue mentioned by Dima, however, I do get somehow a slightly different 
feeling.

First of all, what is the intention of calling window.end() before 
window.show()? Is this just something you tried or is there a deeper use 
case to it?

Unfortunately, I will now be away for two weeks without access to my 
computer, but I will join in again once I am back.

Best egads

Andreas

On 6/27/25 19:59, Dima Kogan wrote:
> Hi. Thanks for looking. I just dug into it a bit also, and it started to
> look familiar. We already looked into this sort of thing here:
>
>    https://sourceforge.net/p/pyfltk/mailman/pyfltk-user/thread/1014543129.14367.1712509274536%40bluewin.ch/#msg58757564
>
> The punchline is that swig has a bug: it should do most of its
> deallocation in tp_finalize, but instead it puts everything into
> tp_destroy. This makes it possible for stuff to be cleaned-up out of
> order. In THIS case it looks like the derived Fl_Window type in
> Fl_Gl_Image_Widget is being cleaned up twice, or something of that
> nature. I don't know if this swig problem is THE problem here, but it's
> adjacent. Did either of you happen to talk to the swig folks about it
> the last time around?
>
> Thanks
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

Re: [Pyfltk-user] Quitting a pyfltk application with Ctrl-c

[Robert A. <ro...@gm...>]

On Thu, Jun 26, 2025 at 3:30 PM Dima Kogan <di...@se...> wrote:
>
> Hello.
>
> This is another issue i just looked into, that I would appreciate some
> pointers for. I have this trivial pyfltk program:
>
>   #!/usr/bin/python3
>
>   from fltk import *
>
>   window = Fl_Window(100,200,"xxx")
>   window.end()
>   window.show()
>
>   Fl.run()
>
> I run it. Instead of hitting Escape, I go back to the console, and hit
> Ctrl-c. I expect the program to exit, but it ignores the C-c, and does
> nothing. If I go back to the application, and hit Escape, it does exit,
> but also says this:
>

Tried it with C++ fltk hello world, and sending sigint with ctrl-c
does indeed kill the process. Also tried it with tkinter (built-in
python gui). Tkinter does NOT kill the process until you switch focus
back to the gui window. I am, however, skeptical that this issue
should be the responsibility of pyfltk to fix. To me, this seems more
like a python issue.  BTW are you trying to send a pyfltk process
SIGINT from another process (IPC)?

Tkinter seems to have had the same issue here
https://stackoverflow.com/questions/39840815/exiting-a-tkinter-app-with-ctrl-c-and-catching-sigint

Re: [Pyfltk-user] Mystery swig error when exiting pyfltk program

[Dima K. <di...@se...>]

Hi. Thanks for looking. I just dug into it a bit also, and it started to
look familiar. We already looked into this sort of thing here:

  https://sourceforge.net/p/pyfltk/mailman/pyfltk-user/thread/1014543129.14367.1712509274536%40bluewin.ch/#msg58757564

The punchline is that swig has a bug: it should do most of its
deallocation in tp_finalize, but instead it puts everything into
tp_destroy. This makes it possible for stuff to be cleaned-up out of
order. In THIS case it looks like the derived Fl_Window type in
Fl_Gl_Image_Widget is being cleaned up twice, or something of that
nature. I don't know if this swig problem is THE problem here, but it's
adjacent. Did either of you happen to talk to the swig folks about it
the last time around?

Thanks

Re: [Pyfltk-user] Mystery swig error when exiting pyfltk program

[Robert A. <ro...@gm...>]

Hi Dima,

Confirmed, I tested this on Debian 12 with fltk 1.3.8 and got the
exact same results as you. I really can't understand why adding a
simple function creates the error message. Importing your
Fl_Gl_Image_Widget module may cause an issue, as it runs any code in
the module, but that doesn't explain why removing the func() function
silences the error message. I also changed the functions to

def foo():
    pass

with the exact same results.
Also tried changing "from fltk import *" to "import fltk". And used
fltk.Fl_Window(...  and fltk.Fl.run()
no difference, same results.
Also ran the python process with valgrind and it definitely seems to
indicate that the error message is real.
see output below:

valgrind python3 dima-test.py
==5954== Memcheck, a memory error detector
==5954== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==5954== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==5954== Command: python3 dima-test.py
==5954==
==5954== Invalid read of size 8
==5954==    at 0x4023B8C: strncmp (strcmp-sse2.S:160)
==5954==    by 0x4004B9E: is_dst (dl-load.c:216)
==5954==    by 0x400596E: _dl_dst_count (dl-load.c:253)
==5954==    by 0x4005B47: expand_dynamic_string_token (dl-load.c:395)
==5954==    by 0x4005CB2: fillin_rpath.isra.0 (dl-load.c:483)
==5954==    by 0x4005FA2: decompose_rpath (dl-load.c:654)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==  Address 0x56f34e1 is 1 bytes inside a block of size 8 alloc'd
==5954==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
==5954==    by 0x402397A: malloc (rtld-malloc.h:56)
==5954==    by 0x402397A: strdup (strdup.c:42)
==5954==    by 0x4005F34: decompose_rpath (dl-load.c:629)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B5B7: _dl_open (dl-open.c:884)
==5954==
==5954== Invalid read of size 8
==5954==    at 0x4023B94: strncmp (strcmp-sse2.S:162)
==5954==    by 0x4004B9E: is_dst (dl-load.c:216)
==5954==    by 0x400596E: _dl_dst_count (dl-load.c:253)
==5954==    by 0x4005B47: expand_dynamic_string_token (dl-load.c:395)
==5954==    by 0x4005CB2: fillin_rpath.isra.0 (dl-load.c:483)
==5954==    by 0x4005FA2: decompose_rpath (dl-load.c:654)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==  Address 0x56f34e9 is 1 bytes after a block of size 8 alloc'd
==5954==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
==5954==    by 0x402397A: malloc (rtld-malloc.h:56)
==5954==    by 0x402397A: strdup (strdup.c:42)
==5954==    by 0x4005F34: decompose_rpath (dl-load.c:629)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B5B7: _dl_open (dl-open.c:884)
==5954==
==5954== Invalid read of size 8
==5954==    at 0x4023B8C: strncmp (strcmp-sse2.S:160)
==5954==    by 0x4004B9E: is_dst (dl-load.c:216)
==5954==    by 0x4005A0D: _dl_dst_substitute (dl-load.c:295)
==5954==    by 0x4005CB2: fillin_rpath.isra.0 (dl-load.c:483)
==5954==    by 0x4005FA2: decompose_rpath (dl-load.c:654)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==  Address 0x56f34e1 is 1 bytes inside a block of size 8 alloc'd
==5954==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
==5954==    by 0x402397A: malloc (rtld-malloc.h:56)
==5954==    by 0x402397A: strdup (strdup.c:42)
==5954==    by 0x4005F34: decompose_rpath (dl-load.c:629)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B5B7: _dl_open (dl-open.c:884)
==5954==
==5954== Invalid read of size 8
==5954==    at 0x4023B94: strncmp (strcmp-sse2.S:162)
==5954==    by 0x4004B9E: is_dst (dl-load.c:216)
==5954==    by 0x4005A0D: _dl_dst_substitute (dl-load.c:295)
==5954==    by 0x4005CB2: fillin_rpath.isra.0 (dl-load.c:483)
==5954==    by 0x4005FA2: decompose_rpath (dl-load.c:654)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==  Address 0x56f34e9 is 1 bytes after a block of size 8 alloc'd
==5954==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
==5954==    by 0x402397A: malloc (rtld-malloc.h:56)
==5954==    by 0x402397A: strdup (strdup.c:42)
==5954==    by 0x4005F34: decompose_rpath (dl-load.c:629)
==5954==    by 0x400815B: _dl_map_object (dl-load.c:2111)
==5954==    by 0x4002260: openaux (dl-deps.c:64)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x40025C9: _dl_map_object_deps (dl-deps.c:232)
==5954==    by 0x400BA6C: dl_open_worker_begin (dl-open.c:592)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B1C5: dl_open_worker (dl-open.c:782)
==5954==    by 0x4AE41D9: _dl_catch_exception (dl-error-skeleton.c:208)
==5954==    by 0x400B5B7: _dl_open (dl-open.c:884)
==5954==
swig/python detected a memory leak of type 'Fl_Window *', no destructor found.
==5954==
==5954== HEAP SUMMARY:
==5954==     in use at exit: 2,464,217 bytes in 2,466 blocks
==5954==   total heap usage: 30,151 allocs, 27,685 frees, 29,696,663
bytes allocated
==5954==
==5954== LEAK SUMMARY:
==5954==    definitely lost: 0 bytes in 0 blocks
==5954==    indirectly lost: 0 bytes in 0 blocks
==5954==      possibly lost: 189,405 bytes in 100 blocks
==5954==    still reachable: 2,274,812 bytes in 2,366 blocks
==5954==         suppressed: 0 bytes in 0 blocks
==5954== Rerun with --leak-check=full to see details of leaked memory
==5954==
==5954== For lists of detected and suppressed errors, rerun with: -s
==5954== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

On Thu, Jun 26, 2025 at 3:18 PM Dima Kogan <di...@se...> wrote:
>
> Hello!
>
> Can one of you help debugging a mystery error please? I have this
> script, that does more-or-less nothing:
>
>   import Fl_Gl_Image_Widget
>   from fltk import *
>
>   def func():
>       5
>
>   window = Fl_Window(100,200,"xxx")
>   window.end()
>   window.show()
>
>   Fl.run()
>
> I run it, the window pops up, I press Escape, the application exits.
> This is right. But as it exits it prints to the console:
>
>   swig/python detected a memory leak of type 'Fl_Window *', no destructor found.
>
> Does this mean something to any of you? I can make this message go away
> by doing unrelated-looking things. I can remove the definition of func()
> above (which doesn't do anything anyway). Or I can remove the "import
> Fl_Gl_Image_Widget" (which also doesn't do anything). Doing any of these
> silences the error.
>
> This is on a very recent Debian, running everything from packages:
>
>   dima@shorty:~/projects/mrcam$ dpkg -l python3-fltk python3-gl-image-display libfltk1.4
>   ii  python3-fltk:amd64       1.4.2.0-2    amd64        Python wrapper for the Fast Light Toolkit
>   ii  python3-gl-image-display 0.23-1       amd64        OpenGL-based image visualizer
>   ii  libfltk1.4:amd64 1.4.3-1      amd64        Fast Light Toolkit - main shared library
>
> I just upgraded libfltk1.4 from 1.4.2-7; it made no difference.
>
> python3-gl-image-display is mine:
>
>   https://github.com/dkogan/GL_image_display
>
> It also uses swig. Note that here I'm just doing the import; I'm NOT
> actually using it.
>
> Suggestions? Since unrelated-looking things make the problem disappear
> for me, I wouldn't be surprised if yall have trouble reproducing.
>
> Suggestions?
>
> Thanks!
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

[Pyfltk-user] Quitting a pyfltk application with Ctrl-c

[Dima K. <di...@se...>]

Hello.

This is another issue i just looked into, that I would appreciate some
pointers for. I have this trivial pyfltk program:

  #!/usr/bin/python3

  from fltk import *

  window = Fl_Window(100,200,"xxx")
  window.end()
  window.show()

  Fl.run()

I run it. Instead of hitting Escape, I go back to the console, and hit
Ctrl-c. I expect the program to exit, but it ignores the C-c, and does
nothing. If I go back to the application, and hit Escape, it does exit,
but also says this:

  Traceback (most recent call last):
    File "/home/dima/projects/mrcam/tst.py", line 9, in <module>
      Fl.run()
      ~~~~~~^^
    File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 3292, in run
      return _fltk.Fl_run(*args)
             ~~~~~~~~~~~~^^^^^^^
  KeyboardInterrupt

I vaguely remember seeing this in other contexts before. This was years
ago, but back then, when Python called an extension-module function it
reset the SIGINT handler to a function that sets a flag, and does
nothing else. Then when the extension module function returned, it would
look at the flag, and respond to it at that time. This would cause us to
ignore C-c until the Python interpreter got control back. I actually
work around this in all my extension modules. For instance:

  https://github.com/dkogan/mrcam/blob/f37ea3577567e4bd64fe3b69a8196c48f538ee03/mrcam-pywrap.c#L30

At the top of any extension-module function that is not expected to
return immediately, I SET_SIGINT(), and RESET_SIGINT() when done. Do we
need to do something vaguely similar here? pyfltk should allow the
expected thing to happen: when we get a Ctrl-c, the application should
exit.

As with the previous email, this is on a very recent Debian system with:

  $ dpkg -l python3-fltk libfltk1.4 python3
  ii  python3-fltk:amd64 1.4.2.0-2    amd64  Python wrapper for the Fast Light Toolkit
  ii  libfltk1.4:amd64   1.4.3-1      amd64  Fast Light Toolkit - main shared library
  ii  python3            3.13.1-2     amd64  interactive high-level object-oriented language (default python3 version)

Thanks

[Pyfltk-user] Mystery swig error when exiting pyfltk program

[Dima K. <di...@se...>]

Hello!

Can one of you help debugging a mystery error please? I have this
script, that does more-or-less nothing:

  import Fl_Gl_Image_Widget
  from fltk import *

  def func():
      5

  window = Fl_Window(100,200,"xxx")
  window.end()
  window.show()

  Fl.run()

I run it, the window pops up, I press Escape, the application exits.
This is right. But as it exits it prints to the console:

  swig/python detected a memory leak of type 'Fl_Window *', no destructor found.

Does this mean something to any of you? I can make this message go away
by doing unrelated-looking things. I can remove the definition of func()
above (which doesn't do anything anyway). Or I can remove the "import
Fl_Gl_Image_Widget" (which also doesn't do anything). Doing any of these
silences the error.

This is on a very recent Debian, running everything from packages:

  dima@shorty:~/projects/mrcam$ dpkg -l python3-fltk python3-gl-image-display libfltk1.4
  ii  python3-fltk:amd64       1.4.2.0-2    amd64        Python wrapper for the Fast Light Toolkit
  ii  python3-gl-image-display 0.23-1       amd64        OpenGL-based image visualizer
  ii  libfltk1.4:amd64 1.4.3-1      amd64        Fast Light Toolkit - main shared library

I just upgraded libfltk1.4 from 1.4.2-7; it made no difference.

python3-gl-image-display is mine:

  https://github.com/dkogan/GL_image_display

It also uses swig. Note that here I'm just doing the import; I'm NOT
actually using it.

Suggestions? Since unrelated-looking things make the problem disappear
for me, I wouldn't be surprised if yall have trouble reproducing.

Suggestions?

Thanks!

[Pyfltk-user] pyfltk 1.4.3 Released

[Robert A. <ro...@gm...>]

Announcement:

pyfltk 1.4.3 is now released. Wheel packages for Windows 64 bit and
MacOS arm platforms available on Sourceforge and from PyPi. MacOS
intel platform will be available within the next few days.

Re: [Pyfltk-user] My 1.4.2 build issue

[Robert A. <ro...@gm...>]

Hi,

We have not uploaded any wheel packages to Pypi for Fedora (or Linux).
Debian comes with python3-fltk package but Fedora does not. So you
will have to build the package from source. Instructions should be in
the INSTALL file of the source tarball from SF. However, another issue
is that you will need FLTK 1.4 as a dependency of pyfltk. But
unfortunately, Fedora still has no FLTK 1.4 package as you can see
from this thread https://groups.google.com/g/fltkgeneral/c/5wvb2cOngHY
So you will need to build FLTK from source as well.

On Mon, Apr 21, 2025 at 8:39 AM Paxton Sanders
<pax...@ou...> wrote:
>
> Trying to install on Fedora 42. Just built and installed FLTK 1.4.2.
>
> In my virtual environment, I try pip install pyfltk, which soon gives me this error:
>
>       g++ -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -O3 -fPIC -DUNIX=1 -DFL_INTERNALS=1 -I/usr/include/sysprof-6 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/include/harfbuzz -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/local/include/FL/images -I/usr/local/include -I./src -I./contrib -I/usr/include -I./plug-in/include -I./plug-in/src -I/home/paxton/MyStuff/source/pyfltk/tutorial1/venv/include -I/usr/include/python3.13 -c ./fltk/fltk_wrap.cpp -o build/temp.linux-x86_64-cpython-313/fltk/fltk_wrap.o -Wno-unused-label -Wno-unused-but-set-variable -Wformat=1 -Werror=format-security
>       cc1plus: fatal error: ./fltk/fltk_wrap.cpp: No such file or directory
>       compilation terminated.
>       error: command '/usr/bin/g++' failed with exit code 1
>       [end of output]
>
> Any idea what I'm doing wrong?
>
> gcc 15.0.1
> Python 3.13.3
>
> Thanks!
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

[Pyfltk-user] My 1.4.2 build issue

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

Trying to install on Fedora 42. Just built and installed FLTK 1.4.2.

In my virtual environment, I try pip install pyfltk, which soon gives me this error:

      g++ -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -O3 -fPIC -DUNIX=1 -DFL_INTERNALS=1 -I/usr/include/sysprof-6 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/include/harfbuzz -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/local/include/FL/images -I/usr/local/include -I./src -I./contrib -I/usr/include -I./plug-in/include -I./plug-in/src -I/home/paxton/MyStuff/source/pyfltk/tutorial1/venv/include -I/usr/include/python3.13 -c ./fltk/fltk_wrap.cpp -o build/temp.linux-x86_64-cpython-313/fltk/fltk_wrap.o -Wno-unused-label -Wno-unused-but-set-variable -Wformat=1 -Werror=format-security
      cc1plus: fatal error: ./fltk/fltk_wrap.cpp: No such file or directory
      compilation terminated.
      error: command '/usr/bin/g++' failed with exit code 1
      [end of output]

Any idea what I'm doing wrong?

gcc 15.0.1
Python 3.13.3

Thanks!

Re: [Pyfltk-user] Custom Fl_Valuator::format() in fltk

[<and...@bl...>]

Hi Dima

I was trying to analyze this in some more detail and there is indeed a problem that I could not figure out yet. It appears that the downcall from Fl_Value_Slider, which is trying to call the format() method is actually not a downcall at all, but appears to be upcalling into Fl_Valuator::format(). I am still not sure why this happens and I am also not sure whether this is indeed connected to the signature of the format() method or not.  
In short, what you are trying to do is currently not working and I will need some more time to investigate this.

Best regards

Andreas

> Dima Kogan <di...@se...> hat am 01.04.2025 08:39 CEST geschrieben:
> 
>  
> OK... Can I apply this to an Fl_Value_Slider? Does this work in the 1.3
> branch of pyfltk, or 1.4 only? I cannot get this to work.
> 
> 
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

Re: [Pyfltk-user] Custom Fl_Valuator::format() in fltk

[Dima K. <di...@se...>]

OK... Can I apply this to an Fl_Value_Slider? Does this work in the 1.3
branch of pyfltk, or 1.4 only? I cannot get this to work.

Re: [Pyfltk-user] Custom Fl_Valuator::format() in fltk

[Andreas H. <and...@bl...>]

Hi Dima

Actaully, this should work out of the box now. To derive from 
Fl_Valuator, you need something like the following:
class My_Valuator(Fl_Valuator):
     def _init__(self, x, y, w, h, label):
         Fl_Valuator.__init__(self, x, y, w, h, label, len(label))

     def format(self):
         return (4, "test")

In addition, you will need to override the draw() method, as this is 
also not provided by Fl_Valuator. Please let me know if you see some 
problems with your implementation.

Best regards

Andreas

On 3/25/25 17:21, Dima Kogan wrote:
> and...@bl... writes:
>
>> Yes, Fl_Valuator cannot be used on its own and should be derived from.
>> This is, for instance, what has been done with Fl_Adjuster, which is
>> derived from Fl_Valuator.
> We're not understanding each other. What I ACTUALLY want to do is to
> build a log-scale Fl_Slider. This is derived from Fl_Valuator. And I'd
> need to create my own derived class Fl_Log_Slider(Fl_Slider) in Python,
> and this Fl_Log_Slider would need to have a def format() that overrides
> the virtual implementation in Fl_Valuator. And this format() would need
> to return its string in the way the C++ api expects. Can we do that?
>
>
> _______________________________________________
> Pyfltk-user mailing list
> Pyf...@li...
> https://lists.sourceforge.net/lists/listinfo/pyfltk-user

Re: [Pyfltk-user] Custom Fl_Valuator::format() in fltk

[Dima K. <di...@se...>]

and...@bl... writes:

> Yes, Fl_Valuator cannot be used on its own and should be derived from.
> This is, for instance, what has been done with Fl_Adjuster, which is
> derived from Fl_Valuator.

We're not understanding each other. What I ACTUALLY want to do is to
build a log-scale Fl_Slider. This is derived from Fl_Valuator. And I'd
need to create my own derived class Fl_Log_Slider(Fl_Slider) in Python,
and this Fl_Log_Slider would need to have a def format() that overrides
the virtual implementation in Fl_Valuator. And this format() would need
to return its string in the way the C++ api expects. Can we do that?