Crashes with ISS and 32K VT's

[Chuft-Captain]

I've been experiencing a few fatal errors when using Linuxman's ISS in conjunction with 32K virtual textures. The crash always seems to happen in the same place in code, and the circumstances seem to be when either time rate is sped up by maybe 100 - 1000x, or I'm zooming the viewpoint out from the ISS's location to a wider view of Earth.
This appears to be related to a problem with the drawing of tiles, as whenever it happens the surface displays a black square where the tile should be, and the crash occurs.
I'll update this thread if I can narrow down the circumstances / cause further, but as it appears to occur always at the same address in memory, in the meantime I'll post the details here as this information may be useful to the devs. (see below)
UPDATE: Actually, it appears to be the cloud texture that it's having trouble with, at least in this case. (see screenshot below with missing cloud tile on the right)

The addons are:
Linuxman's ISS
JVV 32K earth with his 16K clouds
or
Jesters 32K earth with JVV's clouds

Render path: OpenGL 2.0
Windows 7 (native mode)

Code: Select all

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   celestia.exe
  Application Version:   1.6.1.0
  Application Timestamp:   4dc70009
  Fault Module Name:   MSVCR90.dll
  Fault Module Version:   9.0.30729.4940
  Fault Module Timestamp:   4ca2ef57
  Exception Code:   40000015
  Exception Offset:   0007352f
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:   5129

CLOUD CRASH.jpg

[Fenerit]

Which programs do you use to extract the zip-pack?

[Chuft-Captain]

you mean unzipping the VT? ... Long time ago, so not sure if I can remember, but probably winzip.
Why? Does it matter?

[Fenerit]

Sometime can happen a bad extraction even with Winzip; although the name of the skipped tile(s) is displayed within the log windows (it depend on options' settings). OS's internal extraction can fail once more. Do you have check out whether the cloudmap's tiles are all?
level0 = 2
level1 = 8
level2 = 32
level3 = 128
level4 = 256

[Chuft-Captain]

Thanks, but all tile appear to be present, although some wide variation in filesize in higher levels (eg. level 4 ranges from 16 - 468K, L3: 108-561K, L2: 299-563K, L1: 427-519K )
(I guess that's normal as some will have more details than others at the higher levels.)
How does that compare with yours (assuming you have these addons).

I think it's likely that the Intel HD4000 graphics in this chipset is probably a bit buggy, because it's very new. (Might take a few revisions of the driver to work out the bugs.)

Cheers
CC

[Fenerit]

The cloudmap on my system is just that, apart ISS. It work fine. No clues, then.

[Chuft-Captain]

OK,

Next I'll try removing ISS to see if maybe the combination of the 2 addons is the cause.

Thanks for your help.

[Chuft-Captain]

Confirmed: ISS gone, still crashes at exact same piece of code...

Code: Select all

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   celestia.exe
  Application Version:   1.6.1.0
  Application Timestamp:   4dc70009
  Fault Module Name:   MSVCR90.dll
  Fault Module Version:   9.0.30729.4940
  Fault Module Timestamp:   4ca2ef57
  Exception Code:   40000015
  Exception Offset:   0007352f
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:   5129

I think this new iGPU is just having some difficulty with Virtual Textures.

Cheers
CC

[selden]

cc,

If I understand you correctly, your computer is using Intel graphics. You might try reporting the problem to them. In the past they've been quite helpful in pointing out a bug in Celestia's code which was causing problems on Intel chipsets. In this case, it looks like it might be a bug in their code, though: calling a system routine with bad arguments shouldn't cause a program to crash like that.

[Chuft-Captain]

cc,

If I understand you correctly, your computer is using Intel graphics. You might try reporting the problem to them. In the past they've been quite helpful in pointing out a bug in Celestia's code which was causing problems on Intel chipsets. In this case, it looks like it might be a bug in their code, though: calling a system routine with bad arguments shouldn't cause a program to crash like that.

Thanks Selden,
Good idea.

Just had a quick chat with Intel support, but didn't find them to be very helpful on this occasion.
Summary of the discussion:

... issues with OpenGL* applications are not handled by the technical department.
OpenGL* is a feature that is included on the graphics controller, controlled by the graphics drivers.
for assistance on it, you will need to take a look at: http://www.opengl.org/
..... issues related to OpenGL* is handled through your software developer or OpenGL.org

UPDATE:Had another chat with Intel. The second person was more helpful and has referred this issue to their "Research" dept.... so hopefully thye may be able to shed some light on this. Will have to wait and see....

It appears that the problem's not replicated in other peoples setups, so I don't see that it's an issue with OpenGL itself. It's got to be something specific to the implementation in the specific Intel chipset I'm using.

Do you agree?

[John Van Vliet]

--- edit ---

[Chuft-Captain]

that would be this ISS
http://celestiasws.free.fr/ISS/ISS.html

Yes, the 2009 version. (TELECHARGEMENT Version 2009 ICI)

and Jesters 32K the MS dds map ? or the jpg map

I have...
1. your 32K png texture, using tiles for both day and night:

Code: Select all

AltSurface "John van Vilet 32K" "Sol/Earth"
{
   Texture "Earth.ctx"
   NightTexture "EarthNight.ctx"
}

2. your "darknight" texture, using the same tiles for day, and a JPG (1K) for night:

Code: Select all

AltSurface "John van Vilet 32K DARK NIGHT" "Sol/Earth"
{
      Texture "Earth.ctx"
   NightTexture "earthnight.jpg"
}

3. Jester's DDS version.

(I sometimes switch between all three in a session, but that's not a required action to replicate the crash.)

Note that I have also applied your texture to 3 fictional planets at Castor:

Code: Select all

AltSurface "John van Vilet 32K" "Castor A/Earth@Castor A"
{
   Texture "Earth.ctx"
   NightTexture "EarthNight.ctx"
}


AltSurface "John van Vilet 32K" "Castor B/Earth@Castor B"
{
   Texture "Earth.ctx"
   NightTexture "EarthNight.ctx"
}


AltSurface "John van Vilet 32K" "Castor C/Earth@Castor C"
{
   Texture "Earth.ctx"
   NightTexture "EarthNight.ctx"
}

I don't know if this would have any effect on the amount of memory used.
ie. I doubt that this would cause the tiles to load multiple times, especially as I'm not even visiting Castor.
However, it might be worth disabling those instances to see if it makes a difference.

CC

[John Van Vliet]

--- edit ---

[Chuft-Captain]

I am also with you and Selden.

That is the procedure I'm following... I've already determined that it happens WITHOUT the ISS.

And it is independent of which Earth VT is used (Jesters or yours).

Next step I think will be to use your IO 8K VT and try and replicate the crash at that location.
If it happens at IO, I'll then disable all VT's, and see if I can crash with just the default textures.

So, at the end of all this, it may be either an issue with VT's. or an issue with LARGE VT's, or an issue with ANY textures,
but in any case (as you say) it appears to only happen when using this Intel chipset.

[John Van Vliet]

--- edit ---

[Chuft-Captain]

OK,

No problems encountered with the IO 8K.
No problems with linuxman's ISS and default earth texture.

So, as I originally concluded, it seems that this new hardware is having difficulty with the handling of LARGE VT's.

OK, I think I now know what's going on here...

I noticed that as ISS travels around Earth and more and more tiles get loaded, memory usage increases towards 45-50%:

meter.jpg

...and then weird rendering artifacts occur, missing tiles, black screen, non-responsiveness, etc, and then it crashes.

Now,... I have 8GB of RAM, and 50% of 8GB = 4GB (which coincidentally happens to be the maximum amount of memory that a 32bit program can address in Windows 7).

I wonder if this truly is just a coincidence?

Anyone know what the current state of C++ development tools in Windows 7 is?
I would think it should be relatively easy for one of the DEV's to debug this if it truly is just a matter of running out of address space.

CC

ps. Cloud speed is already set to 0 John.

[Chuft-Captain]

Further investigation reveals that there is no MSVCR90.dll in my System32 folder.
There are however many other versions of this DLL (it's the Microsoft C Runtime Library) used by quite a few programs on my computer, all of which seem to be more recent versions than the one used by Celestia (it's in the main Celestia install folder and is dated 29/7/2008.)

All other programs seem to use more recent incarnations of this DLL, so it looks like it's just a matter of the old library used by Celestia being in-compatible with Windows 7.
eg.

Intel's SSD Toolbox utility uses an MSVCR90.dll version: 9.0.21022.8 which is 641KB (similar to the Celestia version)
OpenOffice uses a smaller version (only 613 KB), but strangely withe the same version: 9.0.21022.8 (maybe compiled with different switches??)
The OpenCL SDK uses yet another version 9.0.30729.4926, which is 637KB.

I wonder if one of the DEV's would like to spend a little time investigating compatibility of the old library used by Celestia with Windows 7/64bit OS. An upgrade to a later version seems to be in order here.

CC

[Chuft-Captain]

*bump*

Hi.

I know that development efforts are focused on QT at this time, however it would be nice at least to get a comment from someone familiar with the code as to whether my conclusions about a 3-4 year old DLL, and/or 32bit program running in 64bit OS are the "likely" cause of this problem(see previous posts).
I'm not asking for a patch necessarily, as I'm sure the QT version will resolve any crashes like this, however it would be nice to get an opinion on whether I'm correct.

If these factors ARE the cause of this crash, then I would expect that other people running Celestia in Windows7 would be seeing this as well. I'm sure I'm not the only person running Windows 7, and yet no-one else has reported this.
In that case, it could be a hardware fault on my side. - This is something I'd very much like to rule-out.

Regards
CC

[selden]

msvc90.dll is the redistributable C language runtime library for Microsoft Visual C v9.0. I.e. Microsoft allows it to be included with any program compiled using that version of their compiler. The varying dates on copies of it just mean that whoever built the software that it accompanies happened to copy the file without preserving its creation date stamp.

When watching Celestia's memory usage, you need to look at the size of Celestia itself, not your system's total memory usage. 32-bit applications like Celestia usually fail when their memory usage exceeds 2GB. That's when address pointers use the sign bit and cause problems for code which (inappropriately) uses signed arithmetic.

My suspicion is that the problem isn't so much in Celestia itself but in how much use is being made of the memory associated with the graphics hardware. Celestia makes no attempt to do any memory management for the GPU. If its memory fills up, problems will ensue. Since other programs use it, too, the amount of GPU memory that's available depends on what other programs are running. The Windows image viewer is particularly greedy. You might want to consider installing GPU Caps Viewer to watch your GPU's memory utilization. It's available for free at http://www.ozone3d.net/gpu_caps_viewer/

[Fenerit]

Next step I think will be to use your IO 8K VT and try and replicate the crash at that location.
If it happens at IO, I'll then disable all VT's, and see if I can crash with just the default textures.

OK,

No problems encountered with the IO 8K.
No problems with linuxman's ISS and default earth texture.

So, as I originally concluded, it seems that this new hardware is having difficulty with the handling of LARGE VT's.

Chuft, in doing so you don't have tried with the Earth VT's cloudmap, right? Do replace the Earth texture with the Io's one... Your graphic cards could have problem on transparencies.