rageworx / fl_imgtk

FLTK image toolkit for some useful effects

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Disposing of "rescaled" image may result in crash

fire-eggs opened this issue · comments

I'm trying out fl_imgtk::rescale. I noticed inside ResizeEngine::scale that if the requested size was unchanged from the original, then a copy of the original is returned:

    if ( ( src->w() == dst_width) && ( src->h() == dst_height))
    {
        return (Fl_RGB_Image*)src->copy();
    }

As I expected in this scenario, calling discard_user_rgb_image on the rescaled image caused a crash. As the returned image in this case is not allocated by fl_imgtk.

This means the caller of fl_imgtk::rescale needs to write code to know when to call discard_user_rgb_image or not. [Of course, they should have written code to not call rescale in this scenario ...]

I'm thinking it might be better to return NULL in this situation?

[And my thanks for this library, I'm definitely using the rotate/flip functions, loving the performance!]

Dear fire-eggs,

Thank you for reporting this issue .

I've been tested some scenario as you announced, make a same image size to clonned, and discard with discard_user_rgb_image(), and tested well with any problem ( couldn't met segment fault on MacOS11 ) in simple test.

Maybe is this an error case for undefined preprocessor 'FLIMGTK_IMGBUFF_OWNALLOC' ?
My concept is rescale must be returned image object by any positive size of image except not enough memory.
I was changed using FLIMGTK_IMGBUFF_OWNALLOC preprocessor for latest changes, and it will be removed to using alloced=1 for any image result.
Here's another project for using fl_imgtk to make image HDRi for any platform, and didn't met any crash for now.
Is it may cause any leakage of memory ? ( but I couldn't met this issue for now)
You should be try or, test with this :

I'll be test more for your announced case.
Plus, did you met segment fault case for this case for latest version of fl_imgtk with clean build ? Let me know !

Regards, Raph.K.

Here some tested on my MacOS 11 ( Apple silicon, M1 )
Seems no error for now, can you test it, fire-eggs ?

flimgtktest1.zip
image

Regards, Raph.

My thanks for your response, I'll take another poke at it!

I've tried a couple of attempts with increasingly complicated sample apps. I've not been able to make the crash happen except in my full-source app. So it's obviously something wrong in my code.

I'll keep working around this for now, until I can dig in deeper as to what I'm doing wrong.

For the record, I'm attaching my last "sample". The program expects an image called "testapp.jpg", any RGB image should do.

fireeggs.cpp.zip

My apologies for the spurious bug report!

Dear, fire-eggs
I've been tested your source ... and modified some for actual working well.
And I couln't find problem on fl_imgtk scaling.
Maybe your may belong to using fl_shared_image on your XBox class.
Here's my testing ( on MinGW-W64 + MSYS2 )

fireeggs_test1-mingw64.zip
image

I recommend to store own fl_rgb_image for caching source by implemented any fl_widget class ( not shared image ).
Waiting your opinion.
Regards, Raph.

It will be closed on this weekend if fire-eggs not appends question.

I don't know when I'll have a chance to chase this down, and it almost certainly is a bug in my code. My thanks for your attention, and I'll close this.

I did take a look at your posted changes above.

Your comments regarding thread safety and moving data into a class are spot-on. But please keep in mind this is a distilled, small program attempting to illustrate the problem, not to be a valid app.

So, for instance, your comment about scaling image "at same size": the issue I found only occurs when fl_imgtk::rescale() returns a copy() of the image, which happens when no scaling is taking place! As you know, I stumble into issue because of bugs in my code, and this was another such situation. I won't attempt to call rescale on the same size in "production".

Your question: // Fl_Image has release ????. Yes it does, and is equivalent to "delete this". I'm using release instead of delete because it might be a Fl_Shared_Image which should be released, not deleted.

Finally: // RaphK. - why don't you using std namespace and headers ? I didn't think I was using any std functions or macros; if I could use them instead someplace in my code, please enlighten me.

My thanks for the interesting feedback - always learning something!
Kevin

I did take a look at your posted changes above.

Your comments regarding thread safety and moving data into a class are spot-on. But please keep in mind this is a distilled, small program attempting to illustrate the problem, not to be a valid app.

So, for instance, your comment about scaling image "at same size": the issue I found only occurs when fl_imgtk::rescale() returns a copy() of the image, which happens when no scaling is taking place! As you know, I stumble into issue because of bugs in my code, and this was another such situation. I won't attempt to call rescale on the same size in "production".

Your question: // Fl_Image has release ????. Yes it does, and is equivalent to "delete this". I'm using release instead of delete because it might be a Fl_Shared_Image which should be released, not deleted.

Finally: // RaphK. - why don't you using std namespace and headers ? I didn't think I was using any std functions or macros; if I could use them instead someplace in my code, please enlighten me.

My thanks for the interesting feedback - always learning something!
Kevin

Dear Kevin,
I saw your Fl_Shared_Image bug report in FLTK issue report, and checked "Like".
Yes, I know, but I don't recommend Fl_Shared_Image because it has many other bugs today until FLTK 1.3.5 ( I was guessed you also know this ).
And asking about 'std headers' even you are using c++, it's standard maybe using namespaces, instead using stdio.h to cstdio.
Most of MSVC programmers are still using old styled headers ( MS are always insist strange C++ standard ), and stull remains strange hungarian expressions. so I recommend to programming keep C++ standard of POSIX, in my opinion, by experiences from making multi platform programs ( form MacOS to Windows, even my ARM64 embededd linux systems, too. )
You are the senior, I respect your long and great experiences, It must be unseen in my life, so I'm afraid to looks disrespectful.
Please my commentary was just asking about simply asking.

plus, My customized FLTK 1.3.5 now moving to 1.4.(0.6) at my new branch, you can check this.

Regards, Raph.

You are the senior, I respect your long and great experiences, It must be unseen in my life, so I'm afraid to looks disrespectful.

A downside of having been at this so long is my brain might be calcified! E.g. namespaces were introduced into C++ in 1995, but I learned C++ before that, and I need to add "using namespace std" to my toolbox!

So don't hesitate to point out where I could be doing something in a better way, I'm still willing to learn ...

So don't hesitate to point out where I could be doing something in a better way, I'm still willing to learn ...

Dear Kevin,
Always welcome, anytime anywhere your any advice, any question as like your activities on FLTK projects.
Regards with respect, Raph.

An update: I've removed all use of FL_Shared_Image in my project, and this problem is no longer happening. I can't say exactly what the issue was except for a double-free interaction with FL_Shared_Image.

An update: I've removed all use of FL_Shared_Image in my project, and this problem is no longer happening. I can't say exactly what the issue was except for a double-free interaction with FL_Shared_Image.

Dear Kevin,
I'd tracked your bug report at fltk repo. (and I fixed my fltk-clone by refer to your pull request )
Appreciate to you.