openvrml-develop

[openvrml-develop] Re: 64MB limit

[Damian M. <da...@er...>]

On Sun, 25 Nov 2001 ope...@li... wrote:

> Date: Sun, 25 Nov 2001 16:51:31 +1100 (EST)
> From: Damian McGuckin <da...@er...>
> To: <ope...@li...>
> Subject: [openvrml-develop] 64MB limit
>
> I have a large VRML file that I am trying to display with GTKLOOKAT.  It
> core dumps before it seriously displays anything.  It reads the files OK.
> However, I suspects some system setting as it dumps a core file of size
>
> 	67186688 Nov 25 15:40 core
>
> This factors to 65536 * ( 65536 + 76 ) which is too close to 64MB and too
> neat for my liking.  I am quite happy to send the ( 13MB uuencoded ) file
> to somebody else if you want to try it.

Being a bit more intelligent and trying some other big files, I am sure
that problem is not a 64MB limit.

I can get problems with other ( sort of ) smaller executable sizes ( 27MB
or so ) which also dump core as a result of a malloc() problem from within
the OpenGL library.

> The program dumps core where a 'where' in gdb with OpenVRML 0.11.2 and
> GTKlookat 0.9.1 compiles with '-g',  shows up
>
> 	#0  0x405b6f7a in malloc () from /lib/libc.so.6
> 	#1  0x405b6d3e in malloc () from /lib/libc.so.6
> 	#2  0x404c4a78 in gluTessVertex () from /usr/X11R6/lib/libGLU.so.1

As to what the problem really is, that remains to be solved.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Re: 64MB limit ( Damian McGuckin )

[Damian M. <da...@er...>]

> I have a large VRML file that I am trying to display with GTKLOOKAT.  It
> core dumps before it seriously displays anything.  It reads the files OK.
> However, I suspects some system setting as it dumps a core file of size
>
> 	67186688 Nov 25 15:40 core

Solution - Upgrade version of Linux.

Problem goes away.

Probably somebody else's dud library.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Tracking down wrong value of d_relativeUrl

[Damian M. <da...@er...>]

With 'GTKLOOKAT', I am reading a ( boring but small sample ) file

	a.wrl

which 'inlines' a URL file

	model/c.wrl

which in turn reads a URL (image) files

	image/asp.jpg

The file a.wrl resides in the current directory, as does the
directory 'model'.  Directory 'image' resides within 'model'.

In the first pass through the VRML nodes, done with readWwl ( which is
associated with a Doc ), the part of each included file, i.e. the
d_relativeUrl, is correct.  It uses

	VrmlNodeInline::addToScene
		which (calls) VrmlNodeInline::load
			which (calls) VrmlScene::readWrl


However, on a second pass through, the 2nd level nested file, sky.jpg,
thinks its parent is a.wrl, not model/c.wrl. As a result, the nested image
cannot be found. I do not know where these nodes are being processed.  It
is definitely not readWrl.  If I ensure that the directory image is in the
same directory as 'a.wrl', this solves the problem but that isn't the
point.  I don't have control like this all the time.  VRML is supposed to
take care of nesting.

I can't even figure out which routine is used to make the second pass
but it isn't the same as the first pass.  There seem like there are
many routines that do fundamentally the same thing and I am lost.

The offending (underlying) variable is d_relativeUrl.  This is a field
of

	VrmlNodeTexture
	....AudioClip
	....Background


To track this down, I need some help on understanding the structure
of these heavily nested classes.

1)
	How, from a VrmlNodeTexture node, get the d_url that belongs to
	its associated VrmlNodeImageTexture ( I have one image associated
	with each texture ).  Note that d_url belongs in

		VrmlNodeImageTexture
		........MovieTexture
		........AudioClip
		........Anchor
		........Inline

2)
	Where would the actual URL ( filename in my case ) of

		url "filename.jpg"

	be actually copied into ( what appears to be the VrmlMFString )
	d_url in VrmlNodeImageTexture which is later extracted as
	an array of URLs with the method

		d_url.get()
	or
		(char *) d_url.getElement(0)

	This might help me to isolate where the corruption is occuring.

3)
	Any other suggestions are welcomed.

Don't tell me to use 'GDB' because to use that effectively assumes you
know something about the structure and where to jump to.  I'm hoping that
somebody out there already knows the structure.  My UNIX data files are
included.

I am not a VRML expert.  I just want to view files created by anther
programs.  Before this exercise, I thought I knew something about
object-oriented programming and C++ and reusability. I am starting to
doubt that now.

As an aside, and while I marvel at this body of work, has anybody ever
pulled apart 'vrm97node.cpp' to work with each class.  10,000 lines is a
nightmare.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Tracking down wrong value of d_relativeUrl

[Thomas F. <tf...@us...>]

Damian McGuckin wrote:

>With 'GTKLOOKAT', I am reading a ( boring but small sample ) file
>
>	a.wrl
>
>which 'inlines' a URL file
>
>	model/c.wrl
>
>which in turn reads a URL (image) files
>
>	image/asp.jpg
>
>The file a.wrl resides in the current directory, as does the
>directory 'model'.  Directory 'image' resides within 'model'.
>
>In the first pass through the VRML nodes, done with readWwl ( which is
>associated with a Doc ), the part of each included file, i.e. the
>d_relativeUrl, is correct.  It uses
>
>	VrmlNodeInline::addToScene
>		which (calls) VrmlNodeInline::load
>			which (calls) VrmlScene::readWrl
>
>
>However, on a second pass through, the 2nd level nested file, sky.jpg,
>thinks its parent is a.wrl, not model/c.wrl. As a result, the nested image
>cannot be found. I do not know where these nodes are being processed.  It
>is definitely not readWrl.  If I ensure that the directory image is in the
>same directory as 'a.wrl', this solves the problem but that isn't the
>point.  I don't have control like this all the time.  VRML is supposed to
>take care of nesting.
>
>I can't even figure out which routine is used to make the second pass
>but it isn't the same as the first pass.  There seem like there are
>many routines that do fundamentally the same thing and I am lost.
>
The second pass is being made in NodeInline::addToScene() on the call to 
NodeGroup::addToScene() ... the relative URL passed into both methods is 
null (which makes sense as the inline is at the root)  The problem is 
that NodeGroup::addToScene resets the current relative URL (the correct 
one determined in the first pass!) with the null URL that has just been 
passed in.

Commenting out the following lines will allow the image to be correctly.

    if (currentRel.length() == 0 || relativeUrl.length() == 0
            || currentRel != relativeUrl) {
        this->d_relative.set(relativeUrl);
    }

This probably isn't a good fix as it likely breaks something somewhere 
else, I'll look into this a little more and see what I come up with.

Later,
Tom

Re: [openvrml-develop] Tracking down wrong value of d_relativeUrl

[Thomas F. <tf...@us...>]

Patch #488262 has been submitted for this problem. This patch fixes bug 
#225694 as well.

I've done some regression testing using the NIST conformance tests of 
the different grouping nodes and no new problems have appeared. I'd 
appreciate it though if others could take a look at the patch to verify 
the sanity of the change.

Later,
Tom

Thomas Flynn wrote:

> Damian McGuckin wrote:
>
>> With 'GTKLOOKAT', I am reading a ( boring but small sample ) file
>>
>>     a.wrl
>>
>> which 'inlines' a URL file
>>
>>     model/c.wrl
>>
>> which in turn reads a URL (image) files
>>
>>     image/asp.jpg
>>
>> The file a.wrl resides in the current directory, as does the
>> directory 'model'.  Directory 'image' resides within 'model'.
>>
>> In the first pass through the VRML nodes, done with readWwl ( which is
>> associated with a Doc ), the part of each included file, i.e. the
>> d_relativeUrl, is correct.  It uses
>>
>>     VrmlNodeInline::addToScene
>>         which (calls) VrmlNodeInline::load
>>             which (calls) VrmlScene::readWrl
>>
>>
>> However, on a second pass through, the 2nd level nested file, sky.jpg,
>> thinks its parent is a.wrl, not model/c.wrl. As a result, the nested 
>> image
>> cannot be found. I do not know where these nodes are being 
>> processed.  It
>> is definitely not readWrl.  If I ensure that the directory image is 
>> in the
>> same directory as 'a.wrl', this solves the problem but that isn't the
>> point.  I don't have control like this all the time.  VRML is 
>> supposed to
>> take care of nesting.
>>
>> I can't even figure out which routine is used to make the second pass
>> but it isn't the same as the first pass.  There seem like there are
>> many routines that do fundamentally the same thing and I am lost.
>>
> The second pass is being made in NodeInline::addToScene() on the call 
> to NodeGroup::addToScene() ... the relative URL passed into both 
> methods is null (which makes sense as the inline is at the root)  The 
> problem is that NodeGroup::addToScene resets the current relative URL 
> (the correct one determined in the first pass!) with the null URL that 
> has just been passed in.
>
> Commenting out the following lines will allow the image to be correctly.
>
>    if (currentRel.length() == 0 || relativeUrl.length() == 0
>            || currentRel != relativeUrl) {
>        this->d_relative.set(relativeUrl);
>    }
>
> This probably isn't a good fix as it likely breaks something somewhere 
> else, I'll look into this a little more and see what I come up with.
>
> Later,
> Tom
>