[Freeglut-developer] New release this weekend?

[John F. Fay <johnffay@cy...>]

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

[Freeglut-developer] Fwd: [Freeglut-cvs] SF.net SVN: freeglut:[964] tags/FG_2_6_0_RC4/

[John F. Fay <johnffay@cy...>]

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

Re: [Freeglut-developer] small xrandr fix

[John Tsiombikas <nuclear@me...>]

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/

Re: [Freeglut-developer] small xrandr fix

[John F. Fay <johnffay@cy...>]

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
>    

Re: [Freeglut-developer] Access violation on CRT exit().

[John F. Fay <johnffay@cy...>]

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
>    

Re: [Freeglut-developer] Access violation on CRT exit().

[Fay, John F Dr CTR USAF AFMC AAC/XRS <john.fay.ctr@eg...>]

(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/

[Freeglut-developer] small xrandr fix

[John Tsiombikas <nuclear@me...>]

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/

Re: [Freeglut-developer] Access violation on CRT exit().

[John Tsiombikas <nuclear@me...>]

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/

[Freeglut-developer] Fwd: [Freeglut-cvs] SF.net SVN: freeglut:[957] tags/FG_2_8_0_RC3/

[John F. Fay <johnffay@cy...>]

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

Re: [Freeglut-developer] Access violation on CRT exit().

[John Tsiombikas <nuclear@me...>]

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/

Re: [Freeglut-developer] Access violation on CRT exit().

[John F. Fay <johnffay@cy...>]

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
>    

Re: [Freeglut-developer] Access violation on CRT exit().

[Diederick C. Niehorster <dcnieho@gm...>]

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
>

Re: [Freeglut-developer] Access violation on CRT exit().

[Martin Payne <lists@ma...>]

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

Re: [Freeglut-developer] freeglut - close function bug, valgrind memory issue

[John F. Fay <johnffay@cy...>]

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
>>    

Re: [Freeglut-developer] Access violation on CRT exit().

[John Tsiombikas <nuclear@me...>]

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/

Re: [Freeglut-developer] Access violation on CRT exit().

[Martin Payne <lists@ma...>]

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

Re: [Freeglut-developer] question about attaching a child window created by glutCreateWindow

[czc.tmp czc <czc.tmp@gm...>]

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
>
>

Re: [Freeglut-developer] freeglut - close function bug, valgrind memory issue

[John Tsiombikas <nuclear@me...>]

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/

Re: [Freeglut-developer] Access violation on CRT exit().

[Diederick C. Niehorster <dcnieho@gm...>]

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
>

Re: [Freeglut-developer] freeglut - close function bug, valgrind memory issue

[Diederick C. Niehorster <dcnieho@gm...>]

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

Re: [Freeglut-developer] freeglut - close function bug, valgrind memory issue

[<cx-Tech@we...>]

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

Re: [Freeglut-developer] Access violation on CRT exit().

[Martin Payne <lists@ma...>]

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

Re: [Freeglut-developer] Access violation on CRT exit().

[John F. Fay <johnffay@cy...>]

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
>    

Re: [Freeglut-developer] Access violation on CRT exit().

[Martin Payne <lists@ma...>]

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

Re: [Freeglut-developer] freeglut - close function bug, valgrind memory issue

[John Tsiombikas <nuclear@me...>]

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/