[ mesa3d-Bugs-1002030 ] Memory Leaks in Mesa 6.0.1

Bugs item #1002030, was opened at 2004-08-02 07:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1002030&group_id=3

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leaks in Mesa 6.0.1

Initial Comment:
From: Roy Walmsley
E-Mail: royw <at> chemringcm.com
Tel: +44 1722 428762

While incorporating the Mesa Version 6.0.1 into our 
Windows application I came across a number of 
memory leaks as follows:

context.c line 829 - ss->DefaultVertexProgram is 
allocated but not freed.

context.c line 834 - ss->DefaultFragmentProgram is 
allocated but not freed.

context.c line 841 - ss->Default1D is created but not 

Re: [Dri-users] [dri_util.o] Error 1

Fredrik Allerstam wrote:
> In file included from dri_util.c:49:
> dri_util.c: In function `driCalculateSwapUsage':
> dri_util.c:1640: warning: ANSI C forbids nested functions
> dri_util.c:1640: syntax error before `get_msc_rate'
> dri_util.c:1647: `get_msc_rate' undeclared (first use in this function)
> dri_util.c:1647: (Each undeclared identifier is reported only once
> dri_util.c:1647: for each function it appears in.)
> dri_util.c:1648: `PFNGLXGETMSCRATEOMLPROC' undeclared (first use in this
> function)

This error is afaics caused by changes in glxext.h, namely the test for 
__STDC__VERSION has moved above GLX_OML_sync_control macro definition. 
This __STDC__VERSION test will fail when compiling from the dri tree, as 
it defines a different stdc version than what is expected by that macro 
(?). Thus in dri_util.c GLX_OML_sync_control macro will already be 
defined, but 'PFNGLXGETMSCRATEOMLPROC' won't (previously the 
GLX_OML_sync_control was not defined, and dri_util.c just defined 
'PFNGLXGETMSCRATEOMLPROC' on its own in that case).
I've tried to just kill the __stdc__version test, but compilation just 
failed in a different place (singlesize.c, GL_FOG_COORD_SOURCE 
undeclared). Since the dri tree is now officially dead, there probably 
won't be a fix for that.
You should probably switch to the xorg tree, and compile the mesa 
hardware drivers in the mesa tree directly.

Roland

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on

Re: Re: [Dri-users] [dri_util.o] Error 1

On Tuesday 03 August 2004 08:35, Roland Scheidegger wrote:
> Fredrik Allerstam wrote:
> > In file included from dri_util.c:49:
> > dri_util.c: In function `driCalculateSwapUsage':
> > dri_util.c:1640: warning: ANSI C forbids nested functions
> > dri_util.c:1640: syntax error before `get_msc_rate'
> > dri_util.c:1647: `get_msc_rate' undeclared (first use in this function)
> > dri_util.c:1647: (Each undeclared identifier is reported only once
> > dri_util.c:1647: for each function it appears in.)
> > dri_util.c:1648: `PFNGLXGETMSCRATEOMLPROC' undeclared (first use in this
> > function)
>
> This error is afaics caused by changes in glxext.h, namely the test for
> __STDC__VERSION has moved above GLX_OML_sync_control macro definition.
> This __STDC__VERSION test will fail when compiling from the dri tree, as
> it defines a different stdc version than what is expected by that macro
> (?). Thus in dri_util.c GLX_OML_sync_control macro will already be
> defined, but 'PFNGLXGETMSCRATEOMLPROC' won't (previously the
> GLX_OML_sync_control was not defined, and dri_util.c just defined
> 'PFNGLXGETMSCRATEOMLPROC' on its own in that case).
> I've tried to just kill the __stdc__version test, but compilation just
> failed in a different place (singlesize.c, GL_FOG_COORD_SOURCE
> undeclared). Since the dri tree is now officially dead, there probably
> won't be a fix for that.
> You should probably switch to the xorg tree, and compile the mesa
> hardware drivers in the mesa tree directly.
>

I was able to get Mesa and DRI compiling properly from inside xc with the 
attached patches.

[ mesa3d-Bugs-1003026 ] Missing IEEE_ONE on MIPS

Bugs item #1003026, was opened at 2004-08-04 12:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1003026&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Kaz Sasayama (kazssym_nn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing IEEE_ONE on MIPS

Initial Comment:
On my MIPS machine, IEEE_ONE definition was missing and
make linux-solo failed early.  I believe MIPS also uses
IEEE floating point format.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1003026&group_id=3

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

[ mesa3d-Bugs-1003026 ] Missing IEEE_ONE on MIPS

Bugs item #1003026, was opened at 2004-08-03 23:22
Message generated for change (Comment added) made by jonsmirl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1003026&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Kaz Sasayama (kazssym_nn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing IEEE_ONE on MIPS

Initial Comment:
On my MIPS machine, IEEE_ONE definition was missing and
make linux-solo failed early.  I believe MIPS also uses
IEEE floating point format.

----------------------------------------------------------------------

Comment By: Jon Smirl (jonsmirl)
Date: 2004-08-03 23:38

Message:
Logged In: YES 
user_id=39063

This may need to be adjusted for your MIPS machine. 

[ mesa3d-Bugs-1003171 ] problem with glXGetProcAddressARB

Bugs item #1003171, was opened at 2004-08-04 03:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1003171&group_id=3

Category: demos
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with glXGetProcAddressARB

Initial Comment:
Tru64 OSF V5.1

Mesa 6.0.1

gmake osf1-nothreads

Libaries are made, but no demo program is compiled:

gmake[2]: Entering directory 
`/home/markus/todo/mesa/Mesa-6.0.1/progs/demos'
gcc322 -I../../include -O2 -DUSE_XSHM arbfplight.c -
L../../lib -lglut -lGLU -lGL -lX11 -lXext -lXmu -lXi -lm -o 
arbfplight
glXGetProcAddressARB
collect2: ld returned 1 exit status

BeOS port: patch

Hi guys,

I finally find some free spare time to work on the Mesa BeOS port:

a) Moved to new makefile-based config and build. That means src/mesa/
Makefile.BeOS can be removed, BTW.
b) Updated the docs/README.BeOS
c) Fixed some bugs in src/mesa/drivers/beos/GLView.cpp about 
constructor flags and make ASAP current context. Two guys awake me on 
these issues, thanks!
e) Expanded support to mklib on BeOS: now it'll set ressource version 
infos and set mimetype. Usefull to know which version it is. 

On bad news front, still not included/unbroken in the build (and 
currently disabled) :
- GLUT for BeOS 
- SGI GLU version (gnupro BeOS-specific issue here  )
- BeOS native samples and GLUT-based demos/samples apps.

Anyway, here the patch, done via this command, against uo-to-date CVS

$ cvs diff -R -c > beos.diffs.

I hope it can be applied without issue.

- Philippe Houdoin.

? beos.diffs

Re: BeOS port: patch

I feel stupid for posting 60Kb of encoded patch on this mailing.
Sorry, my mistake.

- Philippe

--
Fortune Cookie Says:

First Law of Socio-Genetics:
	Celibacy is not hereditary.

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

[ mesa3d-Support Requests-887092 ] Errors during make

Support Requests item #887092, was opened at 2004-01-29 08:37
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200003&aid=887092&group_id=3

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Errors during make

Initial Comment:
I am trying to compile Mesa3D 6.0 on a x86 running RH
9. Upon executing "make linux" or make linux-x86" the
compile and library generation appears, at first to
proceed correctly. However, eventually I get errors
that look related to glx, such as (there is much more,
but all similar to below):

drivers/x11/glxapi.c: At top level:
drivers/x11/glxapi.c:247: `glXGetCurrentDrawable'
declared as function returning a function
drivers/x11/glxapi.c: In function `glXGetCurrentDrawable':
drivers/x11/glxapi.c:248: `gc' undeclared (first use in
this function)
drivers/x11/glxapi.c:248: parse error before ')' token
drivers/x11/glxapi.c: At top level:

CVS server down?

I just got back from vacation yesterday so I don't know what's going 
on, but it looks like the freedesktop CVS server is down.  Can anyone 
shed some light on this?

-Brian

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com