Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current > 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. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current > 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. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] coredump on Fl_Browser resize
On 12/21/11 13:54, mattes wrote:
> for ( int i=0; i< sizeof(data_colpercent); i++ ) {
>data_widths[i] = w * data_colpercent[i] /100;
> }
You're overrunning memory here.
sizeof() returns the number of bytes in the array,
not the number of elements.
Change the sizeof(data_colpercent) to 9,
and it won't crash.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] coredump on Fl_Browser resize
I re-compiled some code (initially developed under Fedora11 and fltk-1.1.9-4)
now rebuild under Fedora15 with fltk-1.1.10-6.
I am a newbee to fltk. Anything my code is doing wrong?
Unfortunately the Fedora 15 coredumps, It opens up fine and displays. When I
resize the window, the window is updated promptly. But when I release the mouse
it coredumps:
gdb fltest core.
#0 0x00c4 in ?? ()
#1 0x080512ef in fl_fix_focus() ()
#2 0x080514d9 in Fl::handle(int, Fl_Window*) ()
#3 0x0806cf50 in fl_handle(_XEvent const&) ()
#4 0x0806df5e in do_queued_events() ()
#5 0x0806e191 in fl_wait(double) ()
#6 0x08052680 in Fl::wait(double) ()
#7 0x080527ee in Fl::run() ()
#8 0x0804f281 in main (argc=1, argv=0xbf849f24) at
/home/mattes/src/amb/fltest/main.cpp:977
Here the code that makes it dump:
#include
#include
#include
static int data_colpercent[] = {4, 7, 10, 17, 6, 10, 6, 10, 12};
static int data_widths[] = {50, 50, 50, 70, 70, 40, 40, 70, 70};
class myBrowser : public Fl_Browser {
public:
myBrowser( int X,int Y,int W,int H,const char*L=0) : Fl_Browser(X,Y,W,H,L)
{};
protected:
//If window reshapes, readjust columns width in browser
void resize( int x, int y, int w, int h ) {
// adjust all columns
for ( int i=0; i< sizeof(data_colpercent); i++ ) {
data_widths[i] = w * data_colpercent[i] /100;
}
Fl_Browser::column_widths( data_widths );
//printf("d wh=%dx%d\n", w,h );
Fl_Browser::resize(x,y,w,h);
}
};
int main( int argc, char **argv)
{
Fl_Window *w = new Fl_Window(900,300);
myBrowser *b = new myBrowser(5,5,w->w()-5,w->h()-5);
b->column_widths( data_widths );
b->column_char('\t');
b->type(FL_MULTI_BROWSER);
b->add("P\t##\tclass\tTEAM\tLaps\tbestTime\tbl\tlastLap\tdiff");
b->add("4\t13l\tF200\twunder\t134\t39.981\t35\t40.66\t1L 15.55");
b->add("5\t3p\tWF\tSunshine\t133\t40.859\t123\t41.23\t2L 7.30");
b->add("7\t23\tclone\tARC\t129\t43.723\t17\t44.300\t6L 31.50");
b->add("8\t17\tWF\tsandflats\t125\t41.076\t67\t41.836\t10L 39.31");
//b->textsize(17);
b->has_scrollbar(0);
w->resizable(b);
w->end();
w->show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2791: Minmum size for tiles in an Fl_Tile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2791 Version: 1.3-feature Note for others: this STR might be tangentially related to STR 2797, where it turns out that if you resize a double window to 0x0 AND are not using XDBE then you can get a segfault from the X11 system... Link: http://www.fltk.org/str.php?L2791 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2676: fl_alert dialogs etc crashes in XftTextExtents32 on Solaris
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current OK. So... are we going to close this one as "not a fltk bug" and move on, or... Link: http://www.fltk.org/str.php?L2676 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Note: fixed in fltk 3 as well (svn -r 9212). Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled+ Fl_Double_Windows resized to zero on W or H
>
> 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
> checkedfor 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!
>
I double check, and find an global variable initialize with this value.
Using nested double window using box can trigger X error. (PolySegment, and
PolyText).
Here my full patch :
// Checking against 0 is not enough
myi->other_xid = ( w() >= 0 && h() >= 0 ? fl_create_offscreen(w(), h()) : 0
);
and (near line 416 of Fl_Double_Window.cxx)
#else // X:
fl_window = myi->other_xid;
draw();
fl_window = myi->xid;
#endif
is replaced by
#else // X:
if ( myi->other_xid ) {
// global init of the current X window
fl_window = myi->other_xid;
draw();
}
fl_window = myi->xid;
#endif
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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) Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Fixed in Subversion repository. Now it is. Sorry for the long delay, I've been too busy... I removed the two statements setting and resetting the line style, since this was not necessary to fix STR #2615. I tested this with the old test case on Linux, and I couldn't see any regressions. I also tested the new version on Windows with the mentioned test case (test/buttons.cxx and resizing the window), and everything looks well again on Windows. Please test, if you can see any other effects, I'll leave the STR open for now to await feedback. Thanks. Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2735: fl_utf_toupper() and Eszett
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current Responding to Torsten's question, I don't think other languages are likely to be affected? The sharp-s thing is more of a Germanic languages thing, and I don't think it occurs at all in (for example) the Romance languages? It doesn't even occur in English, which is (in large part) like a Germanic language... I do find it odd that native German speakers who responded seem to think that the Unicode recommendations are out of sync with real world usage, though! (Or maybe I am not so surprised...) Link: http://www.fltk.org/str.php?L2735 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 I can't remember - did this ever get fixed? Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2771: Turkic locales and str(n)casecmp, toupper, tolower
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2771 Version: 1.3-current Also, for the record, that's: http://www.fltk.org/newsgroups.php?gfltk.general+v:33811 In our own archive... And I still don't know what the best fix is. Upper case dotted I is always going to be tricky for us I think. In the specific case of "--scheme plastic" we maybe don't care? If you explicitly type --scheme PLASTIC it *will* work OK! The kicker is that we force the word plastic to upper case, then compare it against PLASTIC (in effect) but with a Turkic locale set, then plastic does NOT become PLASTIC when you upper case it... Conversely, lower-casing the word PLASTIC does not become plastic, since the I converts to a lower-case non-dotted i instead... Yup. Painful stuff. Link: http://www.fltk.org/str.php?L2771 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 Fix Version: 1.3-current (r9210) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 Fix Version: 1.3-current (r9210) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 OK - r9210 should do it... Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 OK - this is odd. I never got any update emails form this STR, but I now see that Matt said, on the 20th Sept., that we should try removing the code and see what falls out... Then Greg bumped that yesterday (20th Dec) which I never got either... (Hmm, I wonder how many other STR posts I've missed?) The "proper" way to do this would be to restructure the files a bit and tidy up the Makefile accordingly (the WIN32 implementation is #included via the file I'd like to remove, for example...) and I don't have the tools to build all the assorted targets. So, until we ascertain that actually nobody still uses this code, I'll leave in the stub, but take away the suspect/offending code, and see how that flies! Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current 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! Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
