[Gvsig_english] HELP - Fatal Java Error generated by Large / Complex Project File

[Simon Cropper]

Hi all,

Attached is an error file generated by gvSIG and OADE 2010. It appears to be 
caused by a particular project file that is either too big or doing something 
that causes a memory leak or whatever.

Initially I noted the error when loading a current version of OADE 2010 but 
have found that gvSIG in general is causing an error.

I have reattached an error file, this time created with gvSIG v1.9 (BN 1253).

I have increased my VM memory allocation to 2000M but the error still occurs.

What confuses me, is what I can be doing in a project that could bleed outside 
the Java VM and throw an error. If I am not filling up the VM and crashing due 
to running out of memory then the error is due to gvSIG. The program is doing 
something it shouldn't or not cleaning up properly before closing.

Ben suggested something to do with ECW files, and the error log does appear to 
suggest the problem occurs in the driver. To me it looks as if the ERMapper 
driver has not closed a file properly. Am I reading this correctly? If this is 
the case could it be a corrupt file or maybe too many files.

I appear to be able to open all the files so maybe the problem is the number.

When I load the layer I notice if I select all the files the input routine 
baulks. The error dialog says gvSIG there was an "error opening layer" - it 
puts this up 40 times. No particular file is named and if I open in small 
groups all files can be opened.

The total number of ECW files in the project files that causes the error is 142 
files. I created a new project file with 240 ECW files, grouped 105 and opened a 
20GB ECW file (similar to the corrupted file) but was unable to trigger the 
error. I also created new maps with grids and image files included but again no 
luck.

Essentially apart from the myriad of shapefiles (several hundred) and the 
associated formatting I nearly recreated the file, but still can not identify 
the cause of the error.

ANY SUGGESTIONS WOULD BE APPRECIATED as recreating these large complex files, 
especially the formatting and labelling is a nightmare.

******* RESPONSE TO BEN REGARDING HIS FEEDBACK *******

On Friday 16 July 2010 02:42:04 Benjamin Ducke wrote:

> This baffles me a little. There is virtually no difference between
> the "old" and "new" project files, except that gvSIG now writes
> "1.10" into the version tag instead of "1.9". This was done to comply
> with the changes in the new 1.10 beta release from CIT.

Ben, manually changed

     <property key="VERSION" value="1.9"/>

to 

     <property key="VERSION" value="1.10"/>

using gedit and the file opened using OADE. It still caused an error.

> I have "converted" some fairly complex project files, but never had
> this problem. If you want, you could try to manually change the version
> tag value of your old project files so that gvSIG won't do any resaving
> on them when you open them with the new version.

Making a comparison of the project files, what I can see straight away is that 
more than the above line was changed in the new file. Hundreds of lines have 
changed. 

Although a lot represent changes in order there are some unusual changes, e.g. 
colour strings changing.

     255,255,255,255 changing to 60,235,235,255

In some areas large chunks of XML describing layer properties have disappeared 
for a number of shapefiles.

As I meander through the 100s of changes I am totally baffled by differences 
between  the versions. I could understand changes in tags or attribute names 
but random changes in values (like the colour values above) have me scratching 
my head. These changes are not even consistent.

In regards to ECW files being the potential cause - none of the changes in the 
file occurred on a line that specifically referenced an ECW file. 

I also created a new file, added a range of ECW files, grouped them, used them 
in  maps, etc BUT could not recreate the fatal java error. By this I mean I 
could not get OADE (gvSIG v1.10) to open a OADE (gvSIG v1.9) file, save it in 
the new format and create an error. When I look at the two versions I note 
minor changes through  the file but most are logical/expected changes.

*** STOP PRESS ***

Ben, yesterday, following the error shown in the dialog kicked up following 
installation, I ferreted around collecting data to help explain what had 
happened. After a bit of searching I uncovered the fatal error described in 
the multitude of error logs sent yesterday.

Today, as I work through the sequence of actions trying to identify the 
trigger for the error I tried saving the same project file in gvSIG 1.9 (BN 
1253) and OADE 2010 beta -- BOTH GENERATED THE SAME FATAL ERROR.

In fact in the normal gvSIG_1.9 directory I have logs going back to 5 July 
2010.

I reopened another large project but it does not generate the error so I can 
safely say that the problem is a corrupt project file or should I actually say 
a project file works but causes java to crash (it states in the log the error 
is outside the VM).

-- 
Cheers Simon

	Simon Cropper
	Botanicus Australia Pty Ltd
	PO Box 160 Sunshine 3020
	P: 03 9311 5822. M: 041 830 3437
	W: http://www.botanicusaustralia.com.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid6084.log
Type: text/x-log
Size: 66537 bytes
Desc: not available
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100716/c2a15d76/attachment.bin