Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2000 |
Jan
(8) |
Feb
(5) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(19) |
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(10) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(81) |
Nov
(25) |
Dec
(49) |
2003 |
Jan
(39) |
Feb
(33) |
Mar
(47) |
Apr
(11) |
May
(33) |
Jun
(224) |
Jul
(266) |
Aug
(132) |
Sep
(329) |
Oct
(385) |
Nov
(244) |
Dec
(256) |
2004 |
Jan
(73) |
Feb
(170) |
Mar
(188) |
Apr
(149) |
May
(94) |
Jun
(6) |
Jul
(15) |
Aug
(76) |
Sep
(36) |
Oct
(31) |
Nov
(8) |
Dec
(19) |
2005 |
Jan
(141) |
Feb
(27) |
Mar
(25) |
Apr
(98) |
May
(110) |
Jun
(38) |
Jul
(77) |
Aug
(48) |
Sep
(13) |
Oct
(35) |
Nov
(13) |
Dec
(18) |
2006 |
Jan
(9) |
Feb
(12) |
Mar
(7) |
Apr
(18) |
May
(41) |
Jun
(48) |
Jul
(17) |
Aug
(5) |
Sep
(119) |
Oct
(40) |
Nov
(34) |
Dec
(7) |
2007 |
Jan
(24) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(3) |
Sep
(34) |
Oct
(11) |
Nov
(31) |
Dec
(8) |
2008 |
Jan
(5) |
Feb
(15) |
Mar
(8) |
Apr
(8) |
May
(11) |
Jun
(10) |
Jul
(30) |
Aug
(6) |
Sep
(22) |
Oct
(34) |
Nov
(31) |
Dec
(9) |
2009 |
Jan
(1) |
Feb
(59) |
Mar
(57) |
Apr
(37) |
May
(13) |
Jun
(17) |
Jul
(19) |
Aug
(13) |
Sep
(6) |
Oct
(25) |
Nov
(205) |
Dec
(85) |
2010 |
Jan
(46) |
Feb
(5) |
Mar
(2) |
Apr
(20) |
May
(3) |
Jun
(1) |
Jul
(22) |
Aug
|
Sep
(29) |
Oct
(14) |
Nov
(6) |
Dec
(9) |
2011 |
Jan
(20) |
Feb
(63) |
Mar
(93) |
Apr
(39) |
May
(15) |
Jun
(49) |
Jul
(10) |
Aug
(6) |
Sep
(28) |
Oct
(37) |
Nov
(66) |
Dec
(54) |
2012 |
Jan
(114) |
Feb
(117) |
Mar
(309) |
Apr
(57) |
May
(81) |
Jun
(74) |
Jul
(61) |
Aug
(18) |
Sep
(6) |
Oct
(9) |
Nov
(60) |
Dec
(13) |
2013 |
Jan
(19) |
Feb
(25) |
Mar
(37) |
Apr
(81) |
May
(8) |
Jun
(18) |
Jul
(5) |
Aug
(19) |
Sep
(20) |
Oct
(3) |
Nov
(13) |
Dec
(5) |
2014 |
Jan
(13) |
Feb
|
Mar
(11) |
Apr
|
May
(4) |
Jun
(31) |
Jul
(19) |
Aug
(4) |
Sep
(30) |
Oct
(60) |
Nov
(19) |
Dec
(51) |
2015 |
Jan
(7) |
Feb
(24) |
Mar
(60) |
Apr
(13) |
May
(18) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(14) |
Nov
(2) |
Dec
(15) |
2016 |
Jan
(19) |
Feb
(8) |
Mar
|
Apr
(14) |
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(18) |
May
(15) |
Jun
(44) |
Jul
(11) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
2018 |
Jan
(1) |
Feb
|
Mar
(9) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
|
2
|
3
|
4
|
5
(1) |
6
|
7
|
8
|
9
(3) |
10
(3) |
11
(2) |
12
(2) |
13
(10) |
14
(16) |
15
(3) |
16
|
17
(5) |
18
|
19
(4) |
20
(3) |
21
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
31
(1) |
From: John F. Fay <johnffay@cy...> - 2011-12-31 04:35:18
|
Gentlemen, I propose to push "freeglut" 2.8.0 out the door this weekend. If any of you should know of just cause as to why this should not happen, speak now or else forever hold your peace. - John F. Fay |
From: John F. Fay <johnffay@cy...> - 2011-12-22 04:28:15
|
Folks, Release Candidate 4 is now officially out. Given that Christmas is this Sunday, I propose to hold off on a formal release until New Year's Eve if nothing more is found that needs changing. - John -------- Original Message -------- Subject: [Freeglut-cvs] SF.net SVN: freeglut:[964] tags/FG_2_6_0_RC4/ Date: Thu, 22 Dec 2011 04:07:05 +0000 From: fayjf@... Reply-To: A Read-only list for tracking CVS activity <freeglut-cvs@...> To: freeglut-cvs@... Revision: 964 http://freeglut.svn.sourceforge.net/freeglut/?rev=964&view=rev Author: fayjf Date: 2011-12-22 04:07:05 +0000 (Thu, 22 Dec 2011) Log Message: ----------- Creating freeglut 2.6.0 Release Candidate 4 Added Paths: ----------- tags/FG_2_6_0_RC4/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Freeglut-cvs mailing list Freeglut-cvs@... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: John Tsiombikas <nuclear@me...> - 2011-12-20 10:23:02
|
On Mon, Dec 19, 2011 at 09:32:59PM -0600, John F. Fay wrote: > OK, that's gotten that fix in, again in two pieces. One piece is the > innocuous parenthesis clarification and the comment correction. The > other piece is the actual "xrandr" fix itself. > > I'm a little troubled by the "xrandr" fix. You specified the nvidia > "xrandr" implementation but the fix is for all the Linux configurations. > Are we taking out a valuable capability that another chipset would have a > great need for? No. First of my change only modifies the behaviour of freeglut when the user does NOT request a particular refresh rate, i.e. when the gamemode string is something like "1024x768:32". In case the user DOES request a refresh rate like "1024x768:32@...", the code continues as usual to request that refresh rate (if possible). Now then, in case the user didn't request a refresh rate, what we used to do is[1]: query the current refresh rate and then proceed to request that refresh rate from the X server. What I did instead is make it so we never *touch* the refresh rate, unless the user asks us to. We don't ask the X server for it and we allow it to pick one for us. Now that I come to think of it there's another problem with always requesting the current rate. If we're in 1024x768 at 85hz, and the user requests a switch to 1600x1200, it's not at all necessary that the monitor supports an 85hz refresh rate at that higher resolution. So if we explicitly request that rate regardless of the fact that the user hasn't asked for it, the mode switch will fail when it shouldn't. [1] The above description of the previous behaviour of the code is a slight simplification. In fact the previous code would do all that problematic refresh-rate meddling without being requested, the *second time* its called. So, if the user just called glutEnterGameMode directly it would work fine, buf if the user first called glutGameModeGet(GLUT_GAME_MODE_POSSIBLE) to validate the particular game mode and *then* went on to call glutEnterGameMode, the first call would have trampled our "don't care" default value (-1) in the refresh variable with the "current rate", making the second call invariably request a particular rate which happens to be wrong due to the nvidia bug. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. Fay <johnffay@cy...> - 2011-12-20 03:33:13
|
OK, that's gotten that fix in, again in two pieces. One piece is the innocuous parenthesis clarification and the comment correction. The other piece is the actual "xrandr" fix itself. I'm a little troubled by the "xrandr" fix. You specified the nvidia "xrandr" implementation but the fix is for all the Linux configurations. Are we taking out a valuable capability that another chipset would have a great need for? - John On 12/19/2011 7:14 AM, John Tsiombikas wrote: > There is an issue with the game mode on linux. > > The refresh-rate patch for the xrandr code which went in a few months > ago makes it so the current refresh rate is requested when the user > doesn't specify any particular refresh rate. > > That's a reasonable thing to do, but unfortunately nvidia's xrandr > implementation doesn't report refresh rates correctly. So the "current > refresh rate" returned is not really a valid refresh rate to ask for. > That in turn makes the code to always fail in the xrandr path, and > fallback to the old XF86VidMode path for switching the resolution. > > Here's a small patch that works around this issue by making sure that if > the user didn't ask for any particular refresh rate, we also refrain > from asking the X server for the "current" one. > > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > > > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John F. Fay <johnffay@cy...> - 2011-12-20 03:21:59
|
OK, I've put in your two changes as two SVN updates. - John On 12/19/2011 7:07 AM, John Tsiombikas wrote: > On Sat, Dec 17, 2011 at 07:21:59AM -0600, John F. Fay wrote: > >> (2) I put in Martin's conditional compilation for >> "atexit(fgDeinitialize)". We should probably take it out right after >> the release. >> >> Everybody please do a bit of testing and I'll see about Release >> Candidate 3 tomorrow. >> > Just got around to test this, and apparently this conditional > compilation patch was wrong. TARGET_HOST_MS_WINDOWS is defined > irrespective of if we're on windows or not. Just on windows it will be > defined to 1 while otherwise it'll be defined as 0. > > Here's a patch to fix this problem. > > I've also modified the deinit function to explicitly call > glutLeaveGameMode if we're in it. > > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > > > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Fay, John F Dr CTR USAF AFMC AAC/XRS <john.fay.ctr@eg...> - 2011-12-19 14:47:02
|
(insert appropriate expletive here) John F. Fay Technical Fellow, Modeling and Simulation Jacobs Technology / TEAS Group P.O. Box 1935, Eglin AFB, FL 32542-5000 850-883-3496 -----Original Message----- From: John Tsiombikas [mailto:nuclear@...] Sent: Monday, December 19, 2011 7:08 AM To: freeglut-developer@... Subject: Re: [Freeglut-developer] Access violation on CRT exit(). On Sat, Dec 17, 2011 at 07:21:59AM -0600, John F. Fay wrote: > > (2) I put in Martin's conditional compilation for > "atexit(fgDeinitialize)". We should probably take it out right after > the release. > > Everybody please do a bit of testing and I'll see about Release > Candidate 3 tomorrow. Just got around to test this, and apparently this conditional compilation patch was wrong. TARGET_HOST_MS_WINDOWS is defined irrespective of if we're on windows or not. Just on windows it will be defined to 1 while otherwise it'll be defined as 0. Here's a patch to fix this problem. I've also modified the deinit function to explicitly call glutLeaveGameMode if we're in it. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John Tsiombikas <nuclear@me...> - 2011-12-19 13:15:04
|
There is an issue with the game mode on linux. The refresh-rate patch for the xrandr code which went in a few months ago makes it so the current refresh rate is requested when the user doesn't specify any particular refresh rate. That's a reasonable thing to do, but unfortunately nvidia's xrandr implementation doesn't report refresh rates correctly. So the "current refresh rate" returned is not really a valid refresh rate to ask for. That in turn makes the code to always fail in the xrandr path, and fallback to the old XF86VidMode path for switching the resolution. Here's a small patch that works around this issue by making sure that if the user didn't ask for any particular refresh rate, we also refrain from asking the X server for the "current" one. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John Tsiombikas <nuclear@me...> - 2011-12-19 13:07:57
|
On Sat, Dec 17, 2011 at 07:21:59AM -0600, John F. Fay wrote: > > (2) I put in Martin's conditional compilation for > "atexit(fgDeinitialize)". We should probably take it out right after > the release. > > Everybody please do a bit of testing and I'll see about Release > Candidate 3 tomorrow. Just got around to test this, and apparently this conditional compilation patch was wrong. TARGET_HOST_MS_WINDOWS is defined irrespective of if we're on windows or not. Just on windows it will be defined to 1 while otherwise it'll be defined as 0. Here's a patch to fix this problem. I've also modified the deinit function to explicitly call glutLeaveGameMode if we're in it. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. Fay <johnffay@cy...> - 2011-12-19 02:36:19
|
OK, Release Candidate 3 is out. - John -------- Original Message -------- Subject: [Freeglut-cvs] SF.net SVN: freeglut:[957] tags/FG_2_8_0_RC3/ Date: Mon, 19 Dec 2011 02:14:33 +0000 From: fayjf@... Reply-To: A Read-only list for tracking CVS activity <freeglut-cvs@...> To: freeglut-cvs@... Revision: 957 http://freeglut.svn.sourceforge.net/freeglut/?rev=957&view=rev Author: fayjf Date: 2011-12-19 02:14:33 +0000 (Mon, 19 Dec 2011) Log Message: ----------- Creating freeglut 2.8.0 Release Candidate 3 Added Paths: ----------- tags/FG_2_8_0_RC3/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Freeglut-cvs mailing list Freeglut-cvs@... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: John Tsiombikas <nuclear@me...> - 2011-12-17 13:54:17
|
On Sat, Dec 17, 2011 at 10:43:26AM +0000, Martin Payne wrote: > > The crash in the Windows atexit callback happens because the freeglut > deinitialize function is making calls to functions in modules which have > been unloaded. When the deinitialize atexit callback is executed on > Windows, we can only guarantee that kernel32.dll is loaded, so we can't > attempt any kind of video cleanup without the risk of causing a crash. So where is the proper place to do cleanup on windows? The whole point of atexit is that it can be used to register cleanup functions to be called *before* the process is torn down and destroyed. If on windows atexit callbacks are called after parts of the address space are removed then I think that's a pretty big libc bug. Bug or no bug, we must work around the limitations of the implementation, but I'm just curious. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. Fay <johnffay@cy...> - 2011-12-17 13:22:10
|
OK, I've done two things this morning. (1) I fixed the thing that was making my code crash when my timer called "glutPostRedisplay" with no current window. My "cancel red alert" message last night was ill-founded; a crash is never an acceptable error message as far as I'm concerned. (2) I put in Martin's conditional compilation for "atexit(fgDeinitialize)". We should probably take it out right after the release. Everybody please do a bit of testing and I'll see about Release Candidate 3 tomorrow. - John On 12/17/2011 5:20 AM, Diederick C. Niehorster wrote: > Hi Martin and John, > > While I will not pretend to be knowledgable about this issue, that > sounds sensible. > > Best, > Dee > > On Sat, Dec 17, 2011 at 18:43, Martin Payne<lists@...> wrote: > >> Hi John, >> >> >> On 15/12/2011 09:46, John Tsiombikas wrote: >> >>> If you are positive that on (all supported versions of) windows there >>> are no ill effects from never returning the video mode to the original >>> setting, then feel free to make the atexit conditional, but don't change >>> it for other platforms. >>> >> >> This is what I am proposing. The atexit wasn't present in the previous >> version, so making it conditional leaves us no worse off than we were >> before--I'm not aware of any specific issues related to this in any version >> of Windows, and I do my tests from Windows 98 and Windows NT 4 upwards. >> >> >> >>> The correct approach however would be to just see what's causing the >>> crash on exit and avoid doing just that. For instance instead of calling >>> the full deinitialize function from the atexit handler, just switch the >>> video mode back without calling any OpenGL functions. >>> >> >> The crash in the Windows atexit callback happens because the freeglut >> deinitialize function is making calls to functions in modules which have >> been unloaded. When the deinitialize atexit callback is executed on Windows, >> we can only guarantee that kernel32.dll is loaded, so we can't attempt any >> kind of video cleanup without the risk of causing a crash. >> >> I'm not suggesting that we shouldn't attempt to leave everything in the >> state we found it when a freeglut application exits, it's just that the >> atexit callback seems to partly solve an issue on one platform and introduce >> an issue on another platform. With 2.8.0 on the horizon, I think there's not >> much else we can do in the meantime other than add a conditional to not >> compile that code on Win32. I've attached a patch to do just that. >> >> Regards, >> Martin >> >> ------------------------------------------------------------------------------ >> Learn Windows Azure Live! Tuesday, Dec 13, 2011 >> Microsoft is holding a special Learn Windows Azure training event for >> developers. It will provide a great way to learn Windows Azure and what it >> provides. You can attend the event by watching it streamed LIVE online. >> Learn more at http://p.sf.net/sfu/ms-windowsazure >> _______________________________________________ >> Freeglut-developer mailing list >> Freeglut-developer@... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Diederick C. Niehorster <dcnieho@gm...> - 2011-12-17 11:20:43
|
Hi Martin and John, While I will not pretend to be knowledgable about this issue, that sounds sensible. Best, Dee On Sat, Dec 17, 2011 at 18:43, Martin Payne <lists@...> wrote: > Hi John, > > > On 15/12/2011 09:46, John Tsiombikas wrote: >> >> If you are positive that on (all supported versions of) windows there >> are no ill effects from never returning the video mode to the original >> setting, then feel free to make the atexit conditional, but don't change >> it for other platforms. > > > This is what I am proposing. The atexit wasn't present in the previous > version, so making it conditional leaves us no worse off than we were > before--I'm not aware of any specific issues related to this in any version > of Windows, and I do my tests from Windows 98 and Windows NT 4 upwards. > > >> The correct approach however would be to just see what's causing the >> crash on exit and avoid doing just that. For instance instead of calling >> the full deinitialize function from the atexit handler, just switch the >> video mode back without calling any OpenGL functions. > > > The crash in the Windows atexit callback happens because the freeglut > deinitialize function is making calls to functions in modules which have > been unloaded. When the deinitialize atexit callback is executed on Windows, > we can only guarantee that kernel32.dll is loaded, so we can't attempt any > kind of video cleanup without the risk of causing a crash. > > I'm not suggesting that we shouldn't attempt to leave everything in the > state we found it when a freeglut application exits, it's just that the > atexit callback seems to partly solve an issue on one platform and introduce > an issue on another platform. With 2.8.0 on the horizon, I think there's not > much else we can do in the meantime other than add a conditional to not > compile that code on Win32. I've attached a patch to do just that. > > Regards, > Martin > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Martin Payne <lists@ma...> - 2011-12-17 10:43:31
|
Hi John, On 15/12/2011 09:46, John Tsiombikas wrote: > If you are positive that on (all supported versions of) windows there > are no ill effects from never returning the video mode to the original > setting, then feel free to make the atexit conditional, but don't change > it for other platforms. This is what I am proposing. The atexit wasn't present in the previous version, so making it conditional leaves us no worse off than we were before--I'm not aware of any specific issues related to this in any version of Windows, and I do my tests from Windows 98 and Windows NT 4 upwards. > The correct approach however would be to just see what's causing the > crash on exit and avoid doing just that. For instance instead of calling > the full deinitialize function from the atexit handler, just switch the > video mode back without calling any OpenGL functions. The crash in the Windows atexit callback happens because the freeglut deinitialize function is making calls to functions in modules which have been unloaded. When the deinitialize atexit callback is executed on Windows, we can only guarantee that kernel32.dll is loaded, so we can't attempt any kind of video cleanup without the risk of causing a crash. I'm not suggesting that we shouldn't attempt to leave everything in the state we found it when a freeglut application exits, it's just that the atexit callback seems to partly solve an issue on one platform and introduce an issue on another platform. With 2.8.0 on the horizon, I think there's not much else we can do in the meantime other than add a conditional to not compile that code on Win32. I've attached a patch to do just that. Regards, Martin |
From: John F. Fay <johnffay@cy...> - 2011-12-17 04:53:06
|
OK, we can cancel the alert on the "glutDestroyWindow" crashing the code. I was calling "glutPostRedisplay" with no current window. I'm still not sure what to do about the "glutDeinitialize" call. With some fear and trembling I put a segfault into the "one" demo and crashed it with my screen resolution changed. The operating system was able to change the resolution back to what it had been, but one of my other windows that had been open was moved to somewhere else on the screen. Barring screams of pain and outrage, I'm inclined to put out Release Candidate 3 this weekend. - John On 12/13/2011 9:45 PM, John F. Fay wrote: > Folks, > > I've put in John T's fix of the memory leak (thank you, John). > > In trying to chase down the "close" function, I found where I can > crash "freeglut" by mixing timers with window closures. I added code > to the Lorenz demo program to have "freeglut" continue execution when > a window is closed, duplicated the window creation code to make a > total of four windows, and added support for a "q" key in the keyboard > callback that would get the current window and call > "glutDestroyWindow" with that window handle as the argument. When I > ran the code, I got a crash on a call to "glutPostRedisplay" from the > timer callback. > > Since nobody has complained about this happening (at least, not > that I know of), I propose to get the release out the door and then > work on fixing the bug in the next release. > > Please check the SVN head again and if there aren't any other > issues, I'll try putting out a third release candidate tomorrow night. > > - John F. > > On 12/13/2011 6:22 PM, John Tsiombikas wrote: >> On Tue, Dec 13, 2011 at 08:13:53PM +0100,cx-Tech@... wrote: >> >>> dear all, >>> >>> first of all, I have to report a bug: if I define a function >>> >>> void close(void) >>> >>> this function will be executed when closing the window, EVEN if I did >>> NOT gave freeglut the callback glutCloseFunc(&close)! the function >>> is just in the same .c file as the main function. renaming it with >>> "closeme" solved the problem (see the following code). >>> >> This has nothing to do with freeglut. You are overriding a standard >> POSIX function. >> >> man close >> >> >>> ==2570== 265 (4 direct, 261 indirect) bytes in 1 blocks are definitely lost in loss record 87 of 114 >>> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >>> ==2570== by 0x40772A2: fgHintPresent (freeglut_init.c:217) >>> ==2570== by 0x4077959: glutInit (freeglut_init.c:291) >>> ==2570== by 0x804880E: main (main.c:15) >>> >> This is indeed a small leak every time fgHintPresent gets called. >> >> The code at this point is really wrong. Someone was really confused >> about the last argument of fghGetWindowProperty. >> >> Attached patch hintpresent.patch to fix it. >> >> >>> ==2570== 4,028 (2,072 direct, 1,956 indirect) bytes in 1 blocks are definitely lost in loss record 110 of 114 >>> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >>> ==2570== by 0x42A19CD: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x42A1E01: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427D285: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427A26E: glXGetFBConfigs (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427C402: glXChooseFBConfig (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x407F7F3: fgChooseFBConfig (freeglut_window.c:205) >>> ==2570== by 0x407F9FF: fgOpenWindow (freeglut_window.c:768) >>> ==2570== by 0x407DC3C: fgCreateWindow (freeglut_structure.c:106) >>> ==2570== by 0x407F1A4: glutCreateWindow (freeglut_window.c:1183) >>> ==2570== by 0x804881A: main (main.c:16) >>> >> This might be a leak in freeglut or it might be a leak in glx. In any >> case it's an one-off leak during init, it shouldn't matter much. I'll >> look into it some other time. >> >> >> >> >> ------------------------------------------------------------------------------ >> Cloud Computing - Latest Buzzword or a Glimpse of the Future? >> This paper surveys cloud computing today: What are the benefits? >> Why are businesses embracing it? What are its payoffs and pitfalls? >> http://www.accelacomm.com/jaw/sdnl/114/51425149/ >> >> >> _______________________________________________ >> Freeglut-developer mailing list >> Freeglut-developer@... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> |
From: John Tsiombikas <nuclear@me...> - 2011-12-15 09:47:09
|
On Thu, Dec 15, 2011 at 07:24:12AM +0000, Martin Payne wrote: > I personally think the cleanup > should be done by the application which links to freeglut. If you enter > game mode, then you should leave game mode before exiting. The atexit() > callback might catch the case that someone calls exit() whilst in game > mode, but it doesn't catch other cases such as an unhandled exception or > a segfault. The issue doesn't seem to be specific to freeglut either, as > every Linux game I've used which crashes whilst in a different video > mode does not reset it--Quake II included. The fact that freeglut (and some other programs) don't handle segfaults correctly and switch the video mode back is a bug, not a golden standard to strive for. It is simply unacceptable for an X client to change the video mode, and quit without changing it back unless the express and documented purpose of that client is to do just that (like the xrandr program). Take SDL for instance as a good example of proper X behaviour: unless explicitly instructed to do otherwise by the SDL_INIT_NO_PARACHUTE flag, by default catches all fatal signals and exits gracefully. If you are positive that on (all supported versions of) windows there are no ill effects from never returning the video mode to the original setting, then feel free to make the atexit conditional, but don't change it for other platforms. The correct approach however would be to just see what's causing the crash on exit and avoid doing just that. For instance instead of calling the full deinitialize function from the atexit handler, just switch the video mode back without calling any OpenGL functions. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Martin Payne <lists@ma...> - 2011-12-15 07:24:19
|
Hi Dee, On 14/12/2011 14:43, Diederick C. Niehorster wrote: > But the purpose of this shouldn't be just that. When freeglut exits, > there is stuff to be freed. If there are still open windows, that is > part of the stuff to free. Indeed, atexit seems to be late to close > windows in some cases, depending on order in which modules get > unloaded I suppose. I read the old thread and it was added because, on > Linux at least, windows need to be closed orderly by the freeglut code > instead of being left open for the OS to deal with. While this > normally works fine, if a video mode switch has occurred while > entering gamemode, the freeglut code needs to undo this change before > it exits, the OS doesn't do that. Through fgDeInitialize we take care > of this as its one of the steps in closing a window. Perhaps it's a candidate for conditional compilation, at least until we've had some time to think about it. I personally think the cleanup should be done by the application which links to freeglut. If you enter game mode, then you should leave game mode before exiting. The atexit() callback might catch the case that someone calls exit() whilst in game mode, but it doesn't catch other cases such as an unhandled exception or a segfault. The issue doesn't seem to be specific to freeglut either, as every Linux game I've used which crashes whilst in a different video mode does not reset it--Quake II included. Regards, Martin |
From: czc.tmp czc <czc.tmp@gm...> - 2011-12-15 02:36:39
|
Hi, John, VC6 does support CArray. Just try to add #include "afxtempl.h" in the 2nd line of layoutHelper.h. There is no additional pre-processor definitions in the project. Layouthelper is a very simple window management class. By this class, we divide the parent window into four regions and attach the child window in one of them. This program will show you 1. glut/freeglut doesn't attach the window in the proper position. 2. resizing behavior is not correct BR, CZC On Mon, Dec 12, 2011 at 10:22 AM, John F. Fay <johnffay@...>wrote: > ** > OK, it gets worse: the "CArray" is not supported any earlier than > Microsoft ".Net" 2003. I am running MSVC 6.0 vintage 1998. > > As they may say in France, "je suis dans le potage." ("I am in the > soup.") I have a fair idea that I will not be able to do anything about > this problem. > > - John > > > On 12/11/2011 3:57 PM, John F. Fay wrote: > > OK, I am not much closer even to reproducing the problem, let alone > solving it. I've gotten the files (thank you, CZC), downloaded and > installed 7-zip to unlock the files, and found that the project files are > from a later version of Visual Studio. I've tried creating an MFC project > using my MSVC 6.0 and have evidently missed a definition somewhere as > several files (glutwinDlg, LayoutHelper, and triplanes) were missing and > there are a couple that are extra. When I try to build, I get 127 errors, > many of them revolving around an undefined type called "CArray". > > What kind of MFC application is this? What options are supposed to be set > or unset when creating it? > > - John > > > On 11/25/2011 2:55 AM, czc.tmp czc wrote: > > Hi, > > I explain more details. > > I have a main MFC window whose handle is denoted as hParent. Then I > create a thread inside which the glut window opens. I attach the glut > window to the MFC window as a child in the thread. Below is the attached > codes. They are all related to the window style configuration. > > ============ code =============== > glutCreateWindow(GLUT_WINDOW_TITLE); > > hOglWnd = FindWindow(NULL, GLUT_WINDOW_TITLE); > > LONG style = ::GetWindowLong(hWnd , GWL_STYLE); > style = style | WS_CHILD|WS_CLIPCHILDREN|WS_CLIPSIBLINGS; > style = style &~ (WS_CAPTION | WS_BORDER); > ::SetWindowLong(hWnd , GWL_STYLE, style); > ::SetWindowPos( m_hOpenglWin, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | > SWP_NOZORDER | SWP_FRAMECHANGED); > > ::SetParent(hOglWnd , hParent); > ============ code =============== > > OK. Now I got the glut window successfully attached to the mfc window. > The glut runs inside the thread till I send WM_CLOSE message. > > BUT 2 problems happen: > > 1. The child window is not properly attached to the correct position > > In freeglut 2.6, the right boundary is larger than the actual attached > area and the upper boundary is one caption size lower. > In freeglut 2.8, the right boundary is correct but the upper boundary is > still one caption size lower. > It happens also in the original glut. > > I then tested using GLFW (another candidate of freeglut). The window is > attached OK. > > 2. The child window is resizing incorrectly. > > When I slowly resize the main window, the child window immediately > correctly attached to the correct position with the correct size, but then > suddenly jumps to the incorrect position. > > It'll be great helpful if you can provide any advice. > > Thanks. > > > On Thu, Nov 24, 2011 at 7:59 PM, Diederick C. Niehorster < > dcnieho@...> wrote: > >> resizing and such shouldn't lead to a change of style. Check out the >> freeglut code for glutcreatewindow in freeglut_window.c. Style is set >> there once in the functions it calls and not changed again. The >> various operation triggered from the windowproc should not result in a >> change of style. Style is not stored internally either, unless going >> fullscreen so it can be restored correctly. >> >> Hope that helps! >> >> Best, >> Dee >> >> On 24/11/2011, czc.tmp czc <czc.tmp@...> wrote: >> > haha, still far away, I think. >> > >> > Regarding the window style (bordless, captionless, etc.), are there any >> > differences between glut API and windows API? >> > >> > I'm afraid that settings through windows api may cause strange behaviors >> > when resizing, restoring, .... >> > >> > On Thu, Nov 24, 2011 at 6:03 PM, Diederick C. Niehorster >> > <dcnieho@...>wrote: >> > >> >> Ah, so you're getting closer to what you need? >> >> >> >> did you use/set GLUT_BORDERLESS in glutInitDisplayMode()? >> >> >> >> Otherwise I'm not too sure what could be going wrong. It seems you are >> >> knowledgeable about the windows API, if you want to have a look at the >> >> freeglut code related to opening, resizign and positioning windows, >> >> that'd be very welcome! >> >> >> >> Best, >> >> Dee >> >> >> >> On Thu, Nov 24, 2011 at 17:12, czc.tmp czc <czc.tmp@...> wrote: >> >> > The attached window is different in this version (2.8 rc2, vs 2.6). >> >> > The initial position is partially correct. There is a caption bar gap >> >> though >> >> > the style indicates it's been ignored. >> >> > The resizing is incorrect. The attached window will jump to a fixed >> >> position >> >> > which is associated with the parent window position. But the window >> size >> >> > seems correct. Maybe client rect is wrong? I guess. >> >> > >> >> > On Thu, Nov 24, 2011 at 4:36 PM, czc.tmp czc <czc.tmp@...> >> wrote: >> >> >> >> >> >> Thanks. >> >> >> Actually we're developing a software. It's not designed to involve >> big >> >> 3D >> >> >> features. We just simply need a small function unit to show sth. >> >> >> The design is to firstly create a glut window, and then attach it to >> >> >> the >> >> >> main window built by MFC. >> >> >> "glutCreateSubWindow" seems to create a child window for an existing >> >> glut >> >> >> window. But our purpose is to create a child window for an existing >> MFC >> >> >> window. >> >> >> Actually we attached it. But the initial positions, sizes and >> resizing >> >> >> behaviors are all incorrect. >> >> >> I will update the latest freeglut codes. >> >> >> >> >> >> On Thu, Nov 24, 2011 at 4:20 PM, Diederick C. Niehorster >> >> >> <dcnieho@...> wrote: >> >> >>> >> >> >>> Hi, >> >> >>> >> >> >>> Freeglut does child windows already, you don't have to do it >> yourself. >> >> >>> See glutCreateSubWindow >> >> >>> >> >> >>> This doesn't have the SetParent() call however. Just for personal >> >> >>> curiosity, could you tell me what thats for? >> >> >>> >> >> >>> Also, please get the latest trunk version, there have been some >> >> >>> changes in window creation internally. There were some small >> problems >> >> >>> with child windows before. >> >> >>> >> >> >>> Best, >> >> >>> Dee >> >> >>> >> >> >>> On Thu, Nov 24, 2011 at 16:13, czc.tmp czc <czc.tmp@...> >> wrote: >> >> >>> > Hi, >> >> >>> > I'm using freeglut 2.6 in windows 7. >> >> >>> > I want to create a window using glut and attach it to an existing >> >> >>> > window. I >> >> >>> > think this scenario may be common. However, I found very strange >> >> >>> > behaviors >> >> >>> > when calling following codes. >> >> >>> > ====================== >> >> >>> > glutCreateWindow(GLUT_WINDOW_TITLE); // i create a window using >> glut >> >> >>> > hWnd = FindWindow(NULL, GLUT_WINDOW_TITLE); // then I get the >> hwnd >> >> >>> > using API >> >> >>> > LONG style = ::GetWindowLong(hWnd , GWL_STYLE); // get and change >> >> style >> >> >>> > style = style | WS_CHILD|WS_CLIPCHILDREN|WS_CLIPSIBLINGS; >> >> >>> > style = style &~ (WS_CAPTION | WS_BORDER); >> >> >>> > ::SetWindowLong(hWnd , GWL_STYLE, style); // set style >> >> >>> > ::SetWindowPos( m_hOpenglWin, 0, 0, 0, 0, 0, SWP_NOSIZE | >> SWP_NOMOVE >> >> | >> >> >>> > SWP_NOZORDER | SWP_FRAMECHANGED); >> >> >>> > ::SetParent(m_hOpenglWin, hParent); >> >> >>> > .... >> >> >>> > >> >> >>> > >> >> >> ------------------------------------------------------------------------------ >> >> >>> > All the data continuously generated in your IT infrastructure >> >> >>> > contains a definitive record of customers, application >> performance, >> >> >>> > security threats, fraudulent activity, and more. Splunk takes >> this >> >> >>> > data and makes sense of it. IT sense. And common sense. >> >> >>> > http://p.sf.net/sfu/splunk-novd2d >> >> >>> > _______________________________________________ >> >> >>> > Freeglut-developer mailing list >> >> >>> > Freeglut-developer@... >> >> >>> > https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> >>> > >> >> >>> > >> >> >>> >> >> >>> >> >> >>> >> >> >> ------------------------------------------------------------------------------ >> >> >>> All the data continuously generated in your IT infrastructure >> >> >>> contains a definitive record of customers, application performance, >> >> >>> security threats, fraudulent activity, and more. Splunk takes this >> >> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> _______________________________________________ >> >> >>> Freeglut-developer mailing list >> >> >>> Freeglut-developer@... >> >> >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> >> >> >> > >> >> > >> >> > >> >> >> ------------------------------------------------------------------------------ >> >> > All the data continuously generated in your IT infrastructure >> >> > contains a definitive record of customers, application performance, >> >> > security threats, fraudulent activity, and more. Splunk takes this >> >> > data and makes sense of it. IT sense. And common sense. >> >> > http://p.sf.net/sfu/splunk-novd2d >> >> > _______________________________________________ >> >> > Freeglut-developer mailing list >> >> > Freeglut-developer@... >> >> > https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> > >> >> > >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> All the data continuously generated in your IT infrastructure >> >> contains a definitive record of customers, application performance, >> >> security threats, fraudulent activity, and more. Splunk takes this >> >> data and makes sense of it. IT sense. And common sense. >> >> http://p.sf.net/sfu/splunk-novd2d >> >> _______________________________________________ >> >> Freeglut-developer mailing list >> >> Freeglut-developer@... >> >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> >> > >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Freeglut-developer mailing list >> Freeglut-developer@... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense.http://p.sf.net/sfu/splunk-novd2d > > > _______________________________________________ > Freeglut-developer mailing listFreeglut-developer@...nethttps://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: John Tsiombikas <nuclear@me...> - 2011-12-14 18:18:22
|
On Wed, Dec 14, 2011 at 03:31:42PM +0100, cx-Tech@... wrote: > > sorry again, but i don't have any idea how to use this patch. > i'm using the dll from martin payne one can download here > http://freeglut.sourceforge.net/index.php#download. under ubuntu, i > got freeglut via the package manager... so there is no freeglut_init.c > file. The code from our patches is commited by John Fay into the freeglut svn source repository. If you really need this fix (you don't) you can get the latest code from the repository itself, compile it and install it on your system. Otherwise this change among others will find its way to your ubuntu system at some point in the future when they decide to update their freeglut package. Probably, but not necessarily, after we release the next "stable" version. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. Niehorster <dcnieho@gm...> - 2011-12-14 14:44:07
|
Hi Martin, >From a distance, it indeed seems that settin atexit(fgDeinitialize) is dangerous and never helpful. It also doesn't seem to line up with the purpose John said, as it shouldn't be serving that purpose as you pointed out. But the purpose of this shouldn't be just that. When freeglut exits, there is stuff to be freed. If there are still open windows, that is part of the stuff to free. Indeed, atexit seems to be late to close windows in some cases, depending on order in which modules get unloaded I suppose. I read the old thread and it was added because, on Linux at least, windows need to be closed orderly by the freeglut code instead of being left open for the OS to deal with. While this normally works fine, if a video mode switch has occurred while entering gamemode, the freeglut code needs to undo this change before it exits, the OS doesn't do that. Through fgDeInitialize we take care of this as its one of the steps in closing a window. This is a nasty side effect though. I'm not sure what would be the right course to take for fixing it... Simply removing it leaves other problems... Best, Dee On Wed, Dec 14, 2011 at 22:02, Martin Payne <lists@...> wrote: > Hi John, all, > > > On 14/12/2011 13:00, John F. Fay wrote: > > The "fgDeinitialize" was added because we added the possibility of > "freeglut" returning cleanly from "glutMainLoop" and the program continuing > its execution. Somebody wanted to be able to reinitialize "freeglut" and > start the whole process over again. > > > If this is all it is doing, then I don't think it even needs to be > registered as an atexit callback--if you have called exit() or ExitProcess() > then there is no chance of reinitialising freeglut anyway. Does anyone see a > reason why we shouldn't remove the "atexit(fgDeinitialize)"? If not, it > might take quite some effort to ensure that only freeglut and CRT functions > are being called when fgDeinitialize() is called after exit(). > > Regards, > Martin > > ------------------------------------------------------------------------------ > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Diederick C. Niehorster <dcnieho@gm...> - 2011-12-14 14:37:09
|
Dear Clemens, We're currently in the process of getting out a new release of freeglut. It'll hopefuly happen before the end of the year, but there is still some discussion on the list that'll need to be fixed first. When 2.8.0 is out, an announcement will be made on this list, and you'll be able to get your hands on it soon after, hopefully. Best, Dee On Wed, Dec 14, 2011 at 22:31, <cx-Tech@...> wrote: > Dear John, > >>On Tue, Dec 13, 2011 at 08:13:53PM +0100, cx-Tech@... wrote: >>> dear all, >>> >>> first of all, I have to report a bug: if I define a function >>> >>> void close(void) >>> >>> this function will be executed when closing the window, EVEN if I did >>> NOT gave freeglut the callback glutCloseFunc(&close)! the function >>> is just in the same .c file as the main function. renaming it with >>> "closeme" solved the problem (see the following code). >> >>This has nothing to do with freeglut. You are overriding a standard >>POSIX function. >> >>man close >> > > oh sorry for that, I'm mainly working with windows... > >>> ==2570== 265 (4 direct, 261 indirect) bytes in 1 blocks are definitely lost in loss record 87 of 114 >>> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >>> ==2570== by 0x40772A2: fgHintPresent (freeglut_init.c:217) >>> ==2570== by 0x4077959: glutInit (freeglut_init.c:291) >>> ==2570== by 0x804880E: main (main.c:15) >> >>This is indeed a small leak every time fgHintPresent gets called. >> >>The code at this point is really wrong. Someone was really confused >>about the last argument of fghGetWindowProperty. >> >>Attached patch hintpresent.patch to fix it. > > sorry again, but i don't have any idea how to use this patch. i'm using the dll from martin payne one can download here http://freeglut.sourceforge.net/index.php#download. under ubuntu, i got freeglut via the package manager... so there is no freeglut_init.c file. > >>> ==2570== 4,028 (2,072 direct, 1,956 indirect) bytes in 1 blocks are definitely lost in loss record 110 of 114 >>> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >>> ==2570== by 0x42A19CD: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x42A1E01: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427D285: ??? (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427A26E: glXGetFBConfigs (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x427C402: glXChooseFBConfig (in /usr/lib/mesa/libGL.so.1.2) >>> ==2570== by 0x407F7F3: fgChooseFBConfig (freeglut_window.c:205) >>> ==2570== by 0x407F9FF: fgOpenWindow (freeglut_window.c:768) >>> ==2570== by 0x407DC3C: fgCreateWindow (freeglut_structure.c:106) >>> ==2570== by 0x407F1A4: glutCreateWindow (freeglut_window.c:1183) >>> ==2570== by 0x804881A: main (main.c:16) >> >>This might be a leak in freeglut or it might be a leak in glx. In any >>case it's an one-off leak during init, it shouldn't matter much. I'll >>look into it some other time. >> >>-- >>John Tsiombikas >>http://nuclear.mutantstargoat.com/ > > > best wishes > clemens > ___________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > > ------------------------------------------------------------------------------ > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: <cx-Tech@we...> - 2011-12-14 14:31:49
|
Dear John, >On Tue, Dec 13, 2011 at 08:13:53PM +0100, cx-Tech@... wrote: >> dear all, >> >> first of all, I have to report a bug: if I define a function >> >> void close(void) >> >> this function will be executed when closing the window, EVEN if I did >> NOT gave freeglut the callback glutCloseFunc(&close)! the function >> is just in the same .c file as the main function. renaming it with >> "closeme" solved the problem (see the following code). > >This has nothing to do with freeglut. You are overriding a standard >POSIX function. > >man close > oh sorry for that, I'm mainly working with windows... >> ==2570== 265 (4 direct, 261 indirect) bytes in 1 blocks are definitely lost in loss record 87 of 114 >> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >> ==2570== by 0x40772A2: fgHintPresent (freeglut_init.c:217) >> ==2570== by 0x4077959: glutInit (freeglut_init.c:291) >> ==2570== by 0x804880E: main (main.c:15) > >This is indeed a small leak every time fgHintPresent gets called. > >The code at this point is really wrong. Someone was really confused >about the last argument of fghGetWindowProperty. > >Attached patch hintpresent.patch to fix it. sorry again, but i don't have any idea how to use this patch. i'm using the dll from martin payne one can download here http://freeglut.sourceforge.net/index.php#download. under ubuntu, i got freeglut via the package manager... so there is no freeglut_init.c file. >> ==2570== 4,028 (2,072 direct, 1,956 indirect) bytes in 1 blocks are definitely lost in loss record 110 of 114 >> ==2570== at 0x4025BD3: malloc (vg_replace_malloc.c:236) >> ==2570== by 0x42A19CD: ??? (in /usr/lib/mesa/libGL.so.1.2) >> ==2570== by 0x42A1E01: ??? (in /usr/lib/mesa/libGL.so.1.2) >> ==2570== by 0x427D285: ??? (in /usr/lib/mesa/libGL.so.1.2) >> ==2570== by 0x427A26E: glXGetFBConfigs (in /usr/lib/mesa/libGL.so.1.2) >> ==2570== by 0x427C402: glXChooseFBConfig (in /usr/lib/mesa/libGL.so.1.2) >> ==2570== by 0x407F7F3: fgChooseFBConfig (freeglut_window.c:205) >> ==2570== by 0x407F9FF: fgOpenWindow (freeglut_window.c:768) >> ==2570== by 0x407DC3C: fgCreateWindow (freeglut_structure.c:106) >> ==2570== by 0x407F1A4: glutCreateWindow (freeglut_window.c:1183) >> ==2570== by 0x804881A: main (main.c:16) > >This might be a leak in freeglut or it might be a leak in glx. In any >case it's an one-off leak during init, it shouldn't matter much. I'll >look into it some other time. > >-- >John Tsiombikas >http://nuclear.mutantstargoat.com/ best wishes clemens ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 |
From: Martin Payne <lists@ma...> - 2011-12-14 14:02:16
|
Hi John, all, On 14/12/2011 13:00, John F. Fay wrote: > The "fgDeinitialize" was added because we added the possibility of > "freeglut" returning cleanly from "glutMainLoop" and the program > continuing its execution. Somebody wanted to be able to reinitialize > "freeglut" and start the whole process over again. If this is all it is doing, then I don't think it even needs to be registered as an atexit callback--if you have called exit() or ExitProcess() then there is no chance of reinitialising freeglut anyway. Does anyone see a reason why we shouldn't remove the "atexit(fgDeinitialize)"? If not, it might take quite some effort to ensure that only freeglut and CRT functions are being called when fgDeinitialize() is called after exit(). Regards, Martin |
From: John F. Fay <johnffay@cy...> - 2011-12-14 13:00:41
|
Martin, The "fgDeinitialize" was added because we added the possibility of "freeglut" returning cleanly from "glutMainLoop" and the program continuing its execution. Somebody wanted to be able to reinitialize "freeglut" and start the whole process over again. - John On 12/14/2011 4:30 AM, Martin Payne wrote: > Hi Dee, all, > > On 13/12/2011 11:36, Diederick C. Niehorster wrote: >> I didn't see any errors in the debugger output. Also no problem with a >> release build with everything unchanged from their defaults. >> > > Interesting. I have found the same problem whether I use VS 2008, > 2010, or MinGW, release or debug build. It only happens in 2.8.0, not > 2.6.0. > > I've done some more digging, and I found the access violation happens > when fgCloseWindow() is called *after* the CRT exit() function has > been called. It happens on the call wglMakeCurrent(NULL, NULL) on line > 1540 of "freeglut_window.c", but any OpenGL call seems to cause an > access violation at this point. The call stack is as follows: > > freeglut.dll!fgCloseWindow(tagSFG_Window * window=0x00171d88) > Line 1539 > freeglut.dll!fgDestroyWindow(tagSFG_Window * window=0x00171d88) > Line 224 + 0x9 bytes > freeglut.dll!fgDestroyStructure() Line 377 + 0xb bytes > freeglut.dll!fgDeinitialize() Line 424 > freeglut.dll!_CRT_INIT(void * hDllHandle=0x72120000, unsigned long > dwReason=0, void * lpreserved=0x00000001) Line 449 > freeglut.dll!__DllMainCRTStartup(void * hDllHandle=0x72120000, > unsigned long dwReason=0, void * lpreserved=0x00000001) Line 560 > + 0x11 bytes > freeglut.dll!_DllMainCRTStartup(void * hDllHandle=0x72120000, > unsigned long dwReason=0, void * lpreserved=0x00000001) Line 510 > + 0x11 bytes > ntdll.dll!77499930() > [Frames below may be incorrect and/or missing, no symbols loaded > for ntdll.dll] > ntdll.dll!774b8fba() > ntdll.dll!774b8e5c() > kernel32.dll!750a79f5() > msvcr90d.dll!__crtExitProcess(int status=0) Line 732 > msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) > Line 644 + 0x9 bytes > msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes > > I think the problem is that we are making calls to the OpenGL library > after it has been unloaded from the process' virtual address space. > Comparing 2.8.0 with 2.6.0 I see that we have added a > "atexit(fgDeinitialize)" on line 393 of "freeglut_init.c" (revision > 897). Commenting the atexit() out results in the application exiting > cleanly, and explains why the issue happens only in 2.8.0. I don't > have a proposed fix as I don't know what exactly needs to be cleaned > up at this point, and what the consequences of not cleaning it up > would be. > > Regards, > Martin > > > ------------------------------------------------------------------------------ > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > > > _______________________________________________ > Freeglut-developer mailing list > Freeglut-developer@... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Martin Payne <lists@ma...> - 2011-12-14 10:36:19
|
Hi Dee, all, On 13/12/2011 11:36, Diederick C. Niehorster wrote: > I didn't see any errors in the debugger output. Also no problem with a > release build with everything unchanged from their defaults. Interesting. I have found the same problem whether I use VS 2008, 2010, or MinGW, release or debug build. It only happens in 2.8.0, not 2.6.0. I've done some more digging, and I found the access violation happens when fgCloseWindow() is called *after* the CRT exit() function has been called. It happens on the call wglMakeCurrent(NULL, NULL) on line 1540 of "freeglut_window.c", but any OpenGL call seems to cause an access violation at this point. The call stack is as follows: freeglut.dll!fgCloseWindow(tagSFG_Window * window=0x00171d88) Line 1539 freeglut.dll!fgDestroyWindow(tagSFG_Window * window=0x00171d88) Line 224 + 0x9 bytes freeglut.dll!fgDestroyStructure() Line 377 + 0xb bytes freeglut.dll!fgDeinitialize() Line 424 freeglut.dll!_CRT_INIT(void * hDllHandle=0x72120000, unsigned long dwReason=0, void * lpreserved=0x00000001) Line 449 freeglut.dll!__DllMainCRTStartup(void * hDllHandle=0x72120000, unsigned long dwReason=0, void * lpreserved=0x00000001) Line 560 + 0x11 bytes freeglut.dll!_DllMainCRTStartup(void * hDllHandle=0x72120000, unsigned long dwReason=0, void * lpreserved=0x00000001) Line 510 + 0x11 bytes ntdll.dll!77499930() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!774b8fba() ntdll.dll!774b8e5c() kernel32.dll!750a79f5() msvcr90d.dll!__crtExitProcess(int status=0) Line 732 msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644 + 0x9 bytes msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes I think the problem is that we are making calls to the OpenGL library after it has been unloaded from the process' virtual address space. Comparing 2.8.0 with 2.6.0 I see that we have added a "atexit(fgDeinitialize)" on line 393 of "freeglut_init.c" (revision 897). Commenting the atexit() out results in the application exiting cleanly, and explains why the issue happens only in 2.8.0. I don't have a proposed fix as I don't know what exactly needs to be cleaned up at this point, and what the consequences of not cleaning it up would be. Regards, Martin |
From: John Tsiombikas <nuclear@me...> - 2011-12-14 04:10:11
|
On Tue, Dec 13, 2011 at 09:45:39PM -0600, John F. Fay wrote: > > Please check the SVN head again and if there aren't any other > issues, I'll try putting out a third release candidate tomorrow night. Everything looks fine from where I'm standing. Go ahead with the RC3. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |