[ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #2797

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.

[ Return to Bugs & Features | Post Text | Post File ]