zoom in on Saturn causes crash

[Howard Shaw]

Running 0.12.1 on Windows XP SP3 whenever I zoom in on Saturn when the field of view gets to 5.38 degrees the program crashes. This happens even if Saturn is below the horizon and the screen actually shows the ground. It is the same whether I zoom by mouse, PAGE-UP button, or enabling an ocular. 0.12.0 also crashed in the same way, but I didn't report it since I thought it might be fixed in 0.12.1. Nothing else I have tried to zoom in on crashes the program.
Howard.

[Alexander Wolf (alexwolf)]

I cannot reproduce this issue. Can you test it on fallback mode too?

[Howard Shaw (howard-shaw)]

What is fallback mode? Please explain what I should do to test for the problem.
The bug is so specific to Saturn at a particular zoom level that I think that there is something wrong with a config file or somewhere so it is unlikely that you can reproduce it. Stellarium positions Saturn correctly and shows it as a dot correctly, and if I select it, the marker comes up and its information is shown correctly. It is absolutely to do with the rendering of Saturn at the first zoom level where it is shown as a disc. If I position Saturn just off the screen, zoom in to less than 5 degrees FOV and then move to bring Saturn on screen then it crashes with Saturn at the extreme edge of the screen. I think the underlying bug could be that Stellarium is not checking things like the validity of the data it uses to render textured objects. The process of rendering obviously works, or other things would crash Stellarium as well, but the data used for Saturn on my PC fails in some way. I don't think it is a problem with Saturn as such, invalid data for any object would cause a similar crash for that object. I just happen to have bad data for Saturn. If someone else had bad data for something else then their Stellarium would crash on that object. I guess that Stellarium is not checking for a null pointer, or running off the end of an array. Perhaps the library you use to display JPEGs or whatever assumes the images are valid and does not check for filesize or validity when filling buffers. If a config somewhere said that Saturn's texture was, say, 100x100 and the file was actually 99x99 then would Stellarium handle that OK?
I think the real problem is that Stellarium is assuming something is valid and not bounds checking it. It should either use a default value, automatically correct, or bring up an error message about what is wrong. I have not intentionally changed anything but perhaps the update from pre 0.12.0 to 0.12.0 left some mess in a file somewhere. What would happen if Saturn's texture file (or however planet surfaces are created) was not a valid JPEG (or whatever it is supposed to be)? What config file might be at fault? Where should I look? I uninstalled the old version (but unticked the various "remove files" checkboxes in the uninstall dialog) before installing 0.12.0 and I didn't change any of the defaults when doing the install, so if you tell me where a particular file is that you want to see I should be able to find it.

It is interesting that it fails even if Saturn won't actually be rendered because it is under the ground image. Unless you use painter's algorithm in which case it is being rendered and then covered up. If not painter's algorithm then it might be something in the preparation of the data for rendering before the rendering process is aborted because the object is under ground. Again this points to a bounds checking bug in a data structure somewhere.

I stopped writing software some years ago and switched to just hardware design because I used to spend days trying to find software bugs like this :-(

[Alexander Wolf (alexwolf)]

We don't changed texture for Saturn since branch 0.10, but we change rendering engine. Fallback mode (Start -> Programs -> Stellarium -> Stellarium (Fallback mode)) disable shaders and OpenGL2+ features - this mode switch the Stellarium for using OpenGL1 backend. From log I see that your GPU support OpenGL2 but don't support some shaders (Fragment shader not supported by HW of your GPU) and Stellarium try use mixed mode.

[Howard Shaw (howard-shaw)]

In fallback mode all is OK. I will try it on other PCs (In addition to the self-build I am using now, I have a access to a DELL laptop and a DELL PC at work). I will install Stellarium on them and try it.

[Alexander Wolf (alexwolf)]

Just for experience: please try disable shadows and run it again in OpenGL2 mode.

[Howard Shaw (howard-shaw)]

What are shadows? I can't find anything about "disable shadows" in the "Configuration" or "Sky and Viewing" dialogs and the help is not searchable so I'm a bit stuck.

[Alexander Wolf (alexwolf)]

Please look at F2 -> Tools -> Render Solar Shadows

[Howard Shaw (howard-shaw)]

Thanks,
Render Solar Shadows was not ticked when I found it. I ticked it and saved the configuration. I then restarted Stellarium and zooming in on Saturn still crashed the program. In fallback mode it still does not crash the program. I still wonder why it is just Saturn.

[Howard Shaw (howard-shaw)]

I just installed 0.11.0 in parallel (different installation directory) and that version works OK. However it displays text wrongly with my graphics adaptor. Would it be worth trying 0.12.2dev5 or any other version?

[Alexander Wolf (alexwolf)]

You can test latest beta because we fix some errors which gave crashes but it's was not for Saturn especially.

[Hans Pulina (hans-67)]

I've got the same problem with a program crash while zooming in to Saturn.
Have made a fallback mode protocol too and my operating system (Win Vista SP2) made some dump files and I got some information from the automatical problem analysis of Vista. Here a directoy view (made by dir>dir.txt on the command line) of the files:

08.07.2013 02:01 24.214 AppCompat.txt
08.07.2013 02:02 194.841.519 memory.hdmp
08.07.2013 02:02 3.656.950 minidump.mdmp
08.07.2013 01:04 639 Stellarium CD2.txt
08.07.2013 01:26 1.324 Stellarium CD3.txt
08.07.2013 02:01 468 Version.txt

(Date/time format is dd.mm.jjjj hh.mm)
The Stallarium CDx.txt files I got via control panel-"problem reports and solutions". (Don't know, if the englisch name is really this; it's just a translation of the german name "Problemberichte und Lösungen".) If you want, I can send you the "*.?dmp"-files via email, because I think they are a bit too large for sending them as attachments.

Also I made some screenshots. While making the screenshots, I found out, that the point which shall show Saturn won't be shown anymore after the screenshot. - (I used the Windows hotkey Alt-Print_Screen for it. Later I thought, could have used the programm's print function...)

At least I tried to zoom to the other planets a found out the following:

Saturn: crash at FOV 6.36
Uranus: crash at FOV 2.04
Neptun: crash at FOV 0.961
Pluto: is not shown and I have not found out yet, why. (Should read the manual, I think. ;-) )
To the other planets the zoom works without crash.

So far my discoveries ;-)
Hans

[Alexander Wolf (alexwolf)]

Hans, can you test in fallback mode too?

[Hans Pulina (hans-67)]

Yes, I can... - Done.

There were no crashes while zooming to the planets and the moon. Just because of new moon there was more a big black circle than a pic of the moon. The same was with mercury. But I think, that's because of the light rendering depending on their positions to the sun. (During the time, this message was written, there was new moon and mercury was more or less directly on the line from earth to the sun.)
There was also a little flicker sometimes, but I think, that's because of using OpenGL 1 - just found out, that stellarium always produces a new log file while it overwrites the previous one.

Do you need the crash dump's? - If not, I will delete them, because they need a lot of disk space. I have 6 specimen of them each of around 200 MegaByte.

[Alexander Wolf (alexwolf)]

If you can give crash dump's then please do it.

[Hans Pulina (hans-67)]

Okay, I sent you a dump vie email. It's cut in 3 parts because a mail server didn't like files with attachments bigger than 480 MB. now I'm looking for 7-zip in the hope it will compress a bit better. Then I'll send another crash dump.

[Hans Pulina (hans-67)]

okay, comes a crash dump, third try...
It's 7z compressed and consists of 4 parts. The Launchpad server didn't
accept my further mails because they were too long; 45, 45 and 19 MB. The
Server just accepts 10 MB. Have made parts of 7700000 Byte so that the
message will keep below 10 MB, together with the base64 coded attachment.

This is part 1 of 4

Alexander Wolf schrieb:
> If you can give crash dump's then please do it.
>

[Hans Pulina (hans-67)]

okay, comes a crash dump, third try...
It's 7z compressed and consists of 4 parts. The Launchpad server didn't
accept my previous (not further, as I wrote before) mails because they were
too long; 45, 45 and 19 MB. The Server just accepts 10 MB. Have made parts
of 7700000 Byte so that the message will keep below 10 MB, together with the
base64 coded attachment.

This is part 2 of 4

Alexander Wolf schrieb:
> If you can give crash dump's then please do it.
>

[Hans Pulina (hans-67)]

okay, comes a crash dump, third try...
It's 7z compressed and consists of 4 parts. The Launchpad server didn't
accept my previous mails because they were too long; 45, 45 and 19 MB. The
Server just accepts 10 MB. Have made parts of 7700000 Byte so that the
message will keep below 10 MB, together with the base64 coded attachment.

This is part 3 of 4

Alexander Wolf schrieb:
> If you can give crash dump's then please do it.
>

[Hans Pulina (hans-67)]

okay, comes a crash dump, third try...
It's 7z compressed and consists of 4 parts. The Launchpad server didn't
accept my former mails because they were too long; 45, 45 and 19 MB. The
Server just accepts 10 MB. Have made parts of 7700000 Byte so that the
message will keep below 10 MB, together with the base64 coded attachment.

This is part 4 of 4

There is also a batch file (RESTOREcr0907131317.BAT) to connect the parts
together to the compete 7-ZIP file.

Alexander Wolf schrieb:
> If you can give crash dump's then please do it.
>

[Hans Pulina (hans-67)]

Very interessting! Just wanted to send the text below, but clicked on reload before sending and learned, that my mails have just found a way into this board.

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

Oh. such a sh... shame! - The Launchpad mail server just accepts mail up to 10MB but my previous ones were 45, 45 and 19 MB. So I have compressed them again, this time with 7-zip. To keep the messages including attachments smaller than 10MB I cut it in 4 parts of 7700000 or less Byte. (7.7MB because of the base64 encoding of the attachments.) So you got 4 messages. The last one contains also a short batch file to put the parts together to the whole file.

[Hans Pulina (hans-67)]

Test, test...
This time I try to send a whole file via the Web interface.

[Hans Pulina (hans-67)]

Ja Bravo! - Konnte man das nicht vorher irgendwo hinschreiben, dass die Einschränkungen des mailservers hier beim Webinterface nicht bestehen?

To the admins: There should be an information here, that long files should be send via the web interface and not via email, because of the mail server restrictions. If I had known that before I could have saved the time for parting the dump-archive before sending it in 4 pieces.

[Hans Pulina (hans-67)]

I've discovered a new kind of this crash: it happend during a "journey" coming from West moving to south with a FOV of 1.69°.
The "journey" went from 95 Vir over 96 Vir to κ Vir (kappa Vir; HIP 69427) every time centering the star. When centering kappa Vir, the planet Saturn came also into the picture, resp. it should. But before that happend, the program crashed. I've put the data of the crashdump, a screenshot, the logfile and a short information together for analyzing the problem. Hope, this will help. BTW, did my former crashdumps help?

[Alexander Wolf (alexwolf)]

No, crash dumps didn't help because it not contains needed chars. :( Please try download stellarium-0.12.2RC1-wdbg-win32.exe (https://launchpad.net/stellarium/0.12/0.12.2/+download/stellarium-0.12.2RC1-wdbg-win32.exe) and catch crash dump with it.

[Hans Pulina (hans-67)]

Sad thing! (for saying nothing worse... ;-) ) - I think, that's probably because of the different local settings, right? - Is there a possibility to add the chars? - Or does that call problems with copyrights? - If so, I will send new dumps with the RC-1 build.

[Alexander Wolf (alexwolf)]

I'm added debug info for 0.12.1RC1-wdbg and now crash dumps should contains needed chars ;)

[Hans Pulina (hans-67)]

Okay, I hope you're right with this point of view, but I have some doubts. That's because the new dumps I produdced this morning with the 0.12.2 RC1 Version are also just around 200 MB large. I attached the last one of them together with a screen shot and two logfiles (one in save-mode, the other from after the crash) here, hoping it will be useful. Using the program I made the same watching tour as decribed above, hence went from the star HIP68398 to kappa Vir which was to find near to Saturn on tuesday, July the 16th, 2013. But before Saturn became visible the program crashed.
If it doesn't help just tell me and I'll look, if I can add the needed Informations. But that will probably need time until tomorrow.

[Alexander Wolf (alexwolf)]

Sorry, I'm not be able to get required info from dump, but I'll be try resolve this bug.

[Hans Pulina (hans-67)]

Well, I've some basic knowlege in programming and software developement. But my biggest project up to now consists of something like 1000 lines of code in GNU-coding style with many comments. Anyway I also tried to find the error. But up to now I didn't manage to install WinDbg which seems me to be neccessary to analyse the crashdump files.

But there is another program which is called a post-mortem debugger, however I haven't understood yet, why. It is called "Dr. Watcom" and part of the Open Watcom developement tools (http://www.openwatcom.org/index.php/Main_Page). It cannot read the crashdump files, but identify the reason for the crash: an access violation which occurres inside the OpenGL driver. Okay, then is the question, why? - Up to now I don't know it.
I've attached the output file of the Dr. Watcom program with some added declarations (for myself) of the loaded DLL-files.

[Alexander Wolf (alexwolf)]

Hmm... looks like crash was generated from some function inside atioglxx.dll - just for check hypothesis: can you install unofficial drivers for ATi (http://www.omegadrivers.net ) and check work Stellarium again.

[Hans Pulina (hans-67)]

To be honest: I'd prefer to build the program myself, resp. run it under control of another debugger or other tool for run-time analysis than installing other drivers.

[Hans Pulina (hans-67)]

Some more information about this crash:

Found out (with some help from other ones) that the crash only happens at those planets where Stellarium shows rings. If I set the rings-parameter in ssystem.ini to false, no crash happens.

Also I was introduced to the program "GPU Caps Viewer", which scans the OpenGL possibilities of the GPU. During these tests I got the following error messages because these things were missed:

* vertex texture unit für Vertex displacement Mapping
* support of GL_EXT_gpu_shader4
  GL_ARB_draw_instanced
  GL_EXT_draw_instanced
  for HW Geometry Instancing
* Fragment Shader not supported by HW

I've attached a report file of GPU Caps Viewer also, which tells much more about my graphics hardware. - Anyway I think, the program crash mainly depends on the elderly hardware.

[Alexander Wolf (alexwolf)]

Howard and Hans, can you check this issue on latest 0.13.0 betas? I guess we already fix this issue.

[Hans Pulina (hans-67)]

Well, I just tested the stellarium-0.13.0dev10-win32 built, but not very successful. When the program starts, it first shows everything as expected, but after a few scrollings I get a black screen.

In a second try the black screen disapeared after some "key presses" on the F-keys (Function-Keys) and moving the mouse downwards. But that didn't work a second time, so I don't know, why the picture came back. Anyway I could check for a crash, if I zoomed to Saturn. The good news is, that there was no crash. The bad news ist, there was no saturn visible when I zoomed in. Maybe the picture will tell you something more. BTW, the green stripes at the right border I have really often, especially when I move very fast through the sky view. But I think, that's another problem of the graphics adapter, which isn't able to calculate as fast as neccessary.
So far my first impressions.

[Alexander Wolf (alexwolf)]

I'll close this bug. Hans, can you fill new bug report for "green lines" and attach log.txt?

[Hans Pulina (hans-67)]

Oh, also interessting, I think: the log file of the last run.
To keep it a bit shorter, I cut the following 2 lines, which were repeated for 810 times, if I counted/calculated right:

QOpenGLShader::link: "Fragment shader(s) failed to link, vertex shader(s) linked.
Fragment Shader not supported by HW "

Made it also visible inside the log file at line 276 and followings. Line 281 in the attached file is number 1897 in the original logfile.

[Alexander Wolf (alexwolf)]

Looks like your graphics card didn't support shaders (or drivers). Can you check 0.13.0dev10-MESA?

[Hans Pulina (hans-67)]

Well, at least, before you close it here a some Information, that I got with WinDbg some time ago while trying to analyze the crashdump file I sent with post #28. Hope it is more useful for someone of you than it was for me... ;-)
Anyway with that information I found out, that the crash happens in function Ring::draw() but the exact position I haven't identified. There is also some of the assembly which WinDbg put out.

[Hans Pulina (hans-67)]

Anyway may hardware doesn't support Fragment Shaders; - have you taken a look to comment #33?
Will now test the MESA-Version...

[Hans Pulina (hans-67)]

Well, now I've tested the MESA-Version and found no problems up to now.
If you like to see the screenshots, (they are from Saturn, Uranus and Neptune) which are documented in the logfile, let me know it. But I will probably not send them before tonight.
---
Off Topic questions about Pluto: Where did you get that surface-pic - or is it an artistic artwork? - And what about Styx and Kerberos, the moons around Pluto, discovered in 2011 and '12?

[Hans Pulina (hans-67)]

Well, the MESA-Version dosen't crash up to now, but it takes much too much CPU-Power. If that Version runs, the Task Manager shows CPU-Time around 85 to 92 Percent used by Stellarium. Also the CPU-fan starts to make noise after a minute or more, when it runs.