FLTK logo

STR #2797

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #2797

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:1 - Specific to a machine/printer
Subsystem:Core Library
Summary:X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
Version:1.3-current
Created By:greg.ercolano
Assigned To:AlbrechtS
Fix Version:1.4.0
Fix Commit:50b04b565be5ddf21e2a14f6020655cafd5de0e6
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#1 greg.ercolano
11:17 Dec 19, 2011
(See thread in fltk.general "Tile sample and X_CreatePixmap error")

On linux (centos 5.5 for me), building fltk 1.3.x with
'configure --disable-xdbe' and running the test/tile program,
when the tiles are moved around such that the 'child window'
tile (an Fl_Double_Window itself) is sized to 0 on either W or H,
the following X windows errors occur on the console:

X_CreatePixmap: BadValue (integer parameter out of range for operation) 0x0
X_CopyArea: BadDrawable (invalid Pixmap or Window parameter) 0x11002b2

This is as far as I could get:
    o Changing Fl_Double_Window -> Fl_Window prevents the errors.
      So that seems to make it Fl_Double_Window specific.

    o The issue is definitely triggered when one of the tiles,
      probably 'child window' is resized to zero on either W or H.
      (I never saw negative numbers, so that's not an issue)

      I determined this by modifying resize() in
      src/Fl_Double_Window.cxx to print the W/H values.
      Errors only occur when W or H is zero.

    o I could easily prevent the problem by adding the following
      two lines of code to src/Fl_Double_Window.cxx's resize():

void Fl_Double_Window::resize(int X,int Y,int W,int H) {
  W = (W<=0)?1:W; // <-- ADDED THIS
  H = (H<=0)?1:H; // <-- ADDED THIS
  int ow = w();
[..]
     ..a hack which just prevents windows from possibly being
     resized to zero or less on W or H.

Hopefully one of our X gurus can figure this out; it's hard to trace
the problem down, due to X buffering the errors.
 
 
#2 ianmacarthur
02:13 Dec 21, 2011
Just some additional notes culled from the ref'd thread:

It appears, based on testing by the OP (David) and by me, that the crux may be in the Fl_Double_Window flush() method.

If XDBE is inhibited, then at line 338 of r9209, we have an fl_offscreen created for the double buffer, which is then assigned to other_xid:

       myi->other_xid = fl_create_offscreen(w(), h());

Now, it is clear that the offscreen is created without first checking that the dimensions are non-zero, and that appears to be what triggers the subsequent crash...

David's workaround was to do:

   myi->other_xid = ( w() && h() ? fl_create_offscreen(w(),h()) : 0 );

instead, i.e. only create the offscreen surface for the double buffering of the window if the window has non-zero size. Otherwise, other_xid is set to NULL.

It looks like *most* other places where other_xid is used, it is checked for being NULL first, so this ought to be safe.

David reports good results with this workaround in his tests, though I was initially sceptical.
I'm now of the opinion that this workaround is probably good, though we need to check there are no places where other_xid is actually used without first being checked for NULL, just to be sure!
 
 
#3 greg.ercolano
06:08 Dec 21, 2011
Great -- whatever we do, sounds like fl_create_offscreen()
is a possible culprit, and since it's a public (documented)
function, we should probably document the w|h == 0 issue.

Currently the docs don't mention a w/h of zero is bad,
or if NULL is a possible return value:
http://fltk.org/doc-1.3/group__fl__drawings.html#ga22259d434be43b30f74bfb3e96c5fdab

So I imagine one of the following should be changed in fl_create_offscreen():

    1) Document current behavior to indicate w|h of zero causes
       "undefined behavior", make the change you show at line 338,
       and make sure we handle other_xid == NULL correctly.

    2) Change fl_create_offscreen()'s code to check for w|h == 0
       and return NULL, document that, and warn that in versions
       previous to 1.3.1 there was undefined behavior for w|h == 0.
       And then NOT make any change to line 338, and make sure
       we handle other_xid == NULL correctly.

    3) Allow a w|h of zero, and return a pointer to 'something'
       so that it doesn't crash, and document that w|h can be
       zero (but warn versions previous to 1.3.1 had undefined behavior)
       and check to make sure related offscreen functions won't crash
       when working with a zero sized offscreen buffer. And make no
       change to line 338, and make sure we handle other_xid == NULL
       correctly anyway (see below).

fl_create_offscreen() should probably return NULL if w|h is negative
and document that. (Not that that's an issue here, but it probably should)
 
 
#4 greg.ercolano
11:02 Dec 21, 2011
FYI: looks like our fl_create_offscreen() function
is just a macro wrapper around XCreatePixmap().

The docs for XCreatePixmap()'s docs say:

    "The width and height arguments must be nonzero,
     or a BadValue error results."

So sounds like we better check w/h values in all implementations
of fl_create_offscreen() and return NULL.
 
 
#5 greg.ercolano
11:55 Dec 21, 2011
I researched what the other implementations of fl_create_offscreen() do:

    MAC: calls calloc() to allocate a buffer of w*h*4 in size,
         then calls GBitmapContextCreate(). The latter doesn't
         say one way or the other what happens if w|h are zero:
         http://developer.apple.com/library/mac/documentation/graphicsimaging/reference/CGBitmapContext/Reference/reference.html#//apple_ref/c/func/CGBitmapContextCreate
         I'm not sure what calloc() does if the bytes requested are 0,
         I don't think the man page says.
         I imagine the overall behavior is 'undefined' on the Mac.

    WINDOWS: calls CreateCompatibleBitmap() which says if w|h are zero,
             it acts as if a 1x1 window was requested:
             http://msdn.microsoft.com/en-us/library/dd183488%28v=vs.85%29.aspx

    X: Calls XCreatePixmap() which is explicit that w|h must not be 0.
       Not sure what the return value is.

So we have a little of everything:
    X explicitly doesn't want w|h==0,
    Mac seems undefined
    Win tries to be nice by assuming you're crazy, and makes a 1x1
        so that a valid buffer is returned.

While I think Win's behavior is prudent, it's perhaps being too kind.

I kinda think we should return NULL, document it, and make sure we
check for NULL everywhere. That would be harder, but perhaps more
correct.
 
 
#6 ianmacarthur
13:45 Dec 21, 2011
Yup, that sounds like the best deal...

Also, why am I not getting any of these posts in my mail???

Other fltk mail seems to be arriving OK...
 
 
#7 ianmacarthur
13:49 Dec 21, 2011
Side note: This STR may also have relevance to STR 2791, where the discussion is about what happens to Fl_Tile if you resize the window to 0x0...  
 
#8 greg.ercolano
14:40 Dec 21, 2011
> Also, why am I not getting any of these posts in my mail???

    Hmm, just looked at the site code..
    apparently just adding text to an existing STR does not
    put you on its mailing list.

    Perhaps devs should have permission to add email addresses
    of an STR's participants to the cc list of STR's, if not
    having it automatic.
 
 
#9 greg.ercolano
15:35 Dec 21, 2011
> Also, why am I not getting any of these posts in my mail???

   Looks like when you modify someone else's STR, you can specify your
   email at the "Notification Update" prompt, and you'll get emails.
 
 
#10 fabien
06:46 Apr 24, 2012
Agreed that we should return NULL and document it;
as thinking about the consequences of being permisse as windows is, I would say that if I specify anywhere in my app a (0,0) dim offscreen surface, I must bug somewhere and would like to know about it one way or another.
Creating even a 1 pixel square dimension from a 0 square dim. specification does not make much sense for an offscreen_surface.
 
 
#11 ianmacarthur
16:30 Mar 11, 2014
All.

Did we progress this?

Can we close this STR now, or...?
 
 
#12 greg.ercolano
17:49 Mar 11, 2014
No progress other than to proceed with the change described
at the bottom of Comment #4 and #5, namely:

#4
    So sounds like we better check w/h values in all
    implementations of fl_create_offscreen() and return NULL.

#5
    ..we should return NULL, document it, and make sure we
    check for NULL everywhere. That would be harder,
    but perhaps more correct.
 
 
#13 AlbrechtS
08:28 Oct 16, 2023
Some notes:

1. In FLTK 1.4 XDBE has been removed and the described behavior still persists (as was to be expected).

2. The bad behavior seen on X11 has extended to the Wayland platform (even worse, crashing the program). I reported this on issue 798 as well.

3. I "moved" this STR to GitHub issue #798. Please post all follow-up messages to the GitHub issue (status of this STR is now "Pending").

4. The dev maintaining GitHub issue #798 should please close this STR when done with the "Fix Commit" and status as applicable.

Thanks to all that have contributed to this STR / issue and those that will do in the future.
 
 
#14 AlbrechtS
02:56 Oct 17, 2023
Fixed in Git repository.

Thanks to Manolo for fixing this. Please see GitHub issue 798 for more info.
https://github.com/fltk/fltk/issues/798
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.