freezes when activating satellites

This one might be related to bug #894752, which had a fix made already. Please could you try the 0.11.2 release candidate and report here if it fixes / does not fix the problem?

M

There is no release candidate for Ubuntu. The closest we have is the daily builds packages:
https://launchpad.net/~stellarium/+archive/daily

Andreas, could you please try the following:
- Go to the /home/andreas/.stellarium/modules/Satellites/ directory.
- Open the "satellites.json" file in it.
- In the file, look for "SL-16 R/B". and delete all entries with this name. The entries should look like this:

  "SL-16 R/B":
  {
   "comms": [],
   "groups": ["visual"],
   "hintColor": [0.5, 0.5, 0.5],
   "lastUpdated": 2011-08-31T11:22:02,
   "orbitVisible": false,
   "tle1": "1 31793U 07029B 11242.86769896 .00000249 00000-0 15607-3 0 2136",
   "tle2": "2 31793 70.9757 155.6015 0001550 248.5190 111.5769 14.14077429215369",
   "visible": true
  },

Make sure to delete the trailing coma - there should be only one coma between entries.

Please report if this fixes the problem, so that we know if we should mark this bug as duplicate.

The changing of the file doesn´t helped, it freezes anyway.

With the daily builds i could activate the option but it shows me none satellites. Looks like that it don´t get updates from the internet. In the config, it shows me 0/700 satellites updated and 61 errors.

On my other PC with Ubuntu 11.04 and Stellarium 0.10.5 it works fine without freezes but shows me only a few of the selected satellites. Atmosphere and ground were disabled.

Hope that helps you!

Greetings Andreas

I've just committed some fixes to the Satellites code to better handle orbit exceptions (e.g. re-entry), and catch some GUI problems which could happen after a satellite was deinitialized due to an orbital calculation exception.

These changes will be available for testing in the RC2 binaries (which will be released next weekend if all goes to plan), or you can build the code in the lp:stellarium/0.11 branch if you want to try them right away (NOTE: these changes are not yet merged into trunk).

If you are still having a problem, one thing which has been a problem in the past is non-default locate settings. Try running Stellarium like this:

  LANC=C stellarium

Another thing to try if all the above don't help:

First backup your ~/.stellarium/modules/Satellites/satellites.json file.

Don't select the toolbar to show satellites, but open the Satellites config dialog (alt-Z). Go to the Satellites tab select all items in the list and hit the - button to remove them all. Now add just one satellite using the + button. The ISS is a good one.

If this works, try adding other satellites. And see if you can replicate the problem this way.

Let me know how you get on.

M

It looks like that the bug has something to do with unity. I have now kubuntu installed to test KDE an Stellarium works fine and I think all selected satellites are displayed (I don´t have count but the screen is full of them).

Version 0.11.0

I have the same problem here with Ubuntu Studio (xfce)
I'll try to do the last suggestion cause I didn't understand the other.... I'm quite new to linux....

Removing all satellites and only leave the ISS in the file results in the ISS being 6300 km away and always in the same spot, other satellites also are totally wrong, not moving at all or sometimes dozens of satellites in the same spot with totally crazy distances and also sometimes stellarium will just freeze.

There seem to be two problems.

(1) It seems it is parsing the numbers in the json wrongly. I have a german localized xubuntu 11.10 (by default I have LC_ALL=de_DE.UTF-8) and the satellite positions will be completely wrong. In Germany we have the period as thousands grouping and the comma as decimal separator:

pi = 3,1415926
million = 1.000.000

Probably the plugin is using some parsing functions from the standard library, something like sscanf() but is not telling it explicitly that "." should be the decimal separator, its probably using the current locale settings (german in my case) by default and interpreting the "." completely wrong.

Starting stellarium this way:
LC_ALL=en stellarium

will fix this. Now all orbits are ok.

(2) If I enable *all* satellites, not just the default ones (select the entire list and then check visible and orbit) then it seems there are still some satellites with invalid data and it will crash completely as soon as I enable the plugin.

I am using stellarium 0.11.2 from sourceforge, compiled it myself. Previously I had 0.11.0 from the Ubuntu repositories, same error. I have not yet tried svn.

just checked out latest version from bzr from today and it still won't work without explicitly setting LC_ALL=C

Bernd, what is your usual locale setting?

I read it above now, sorry for the redundant question. LC_ALL=de_DE.UTF-8. I cannot replicate the problem setting this. Perhaps there is something in your settings which I do not have. Please can you attach a .zip with your ~/.stellarium/config.ini and ~/.stellarium/modules/Satellites/*

Thanks

Attached is config.ini and satelllites.json. It contains only one satellite, namely the ISS.

I don't think too much time should be used to investigate my configuration, it was created yesterday after completely removing the old ~/.stellarium/ folder, so it should not contain any strange old settings left over from previous versions.

Maybe you cannot replicate the bug because it depends on the version of your libc or other runtime standard libs, maybe it needs more than only LC_ALL to fully switch the system to german. My system is xubuntu 11.10. I did not have this problem on my old laptop which had an ancient version of Kubuntu Hardy (with kde3 and manually installed Qt4). Maybe you can replicate it by doing a complete german xubuntu install from scratch in a virtual machine.

Somewhere else I read about LC_NUMERIC, maybe your system is sensitive to LC_NUMERIC for numbers parsing and ignoring LC_ALL, I don't have LC_NUMERIC myself and my system will ignore it but you could try to set LC_NUMERIC=de_DE.UTF-8 and there is also LANG and LANGUAGE

The problem is definitely something sscanf() (or similar) and locale related and the difference is NOT in our stellarium settings, it is most likely that stellarium does not properly set the locale to english prior to parsing the configs. Can you tell me the source files where it is parsing the satellites orbital elements, so I don't have to search them manually? I will try to investigate it myself and try to provide a patch.

Maybe it would even be a good idea to force the number parsing locale to english by default for the *entire* program since all it will ever do is parsing config files anyways. The few places where the user is allowed to interactively enter a decimal number formatted in his own locale could be treated separately.

If you have some experimental patches for me to try and experiment, I have now set up everything here to be able to apply, compile and test it myself if this is of any help.

I have seen there is a setlocale(LC_NUMERIC, "C"); in main.cpp but this does not seem to have the desired effect. Either it is too early or something else will reset it to default again later. I have not found any other explicit setlocale doing this in the code, maybe its a side effect of something hidden somewhere much deeper.

Setting LC_NUMERIC explicitely *again* right before it will parse the satellite data will fix the problem for me. The following patch will set it right before the gSatTEME constructor will parse the two tle lines. This patch would completely fix the problem for me:

=== modified file 'plugins/Satellites/src/gSatWrapper.cpp'
--- plugins/Satellites/src/gSatWrapper.cpp 2012-01-11 10:50:37 +0000
+++ plugins/Satellites/src/gSatWrapper.cpp 2012-04-19 13:23:22 +0000
@@ -55,7 +55,8 @@
  // we have a mal-formed input, we will truncate here to be safe
  t1.truncate(130);
  t2.truncate(130);
-
+
+ setlocale(LC_NUMERIC, "C");
  pSatellite = new gSatTEME(designation.toAscii().data(),
                            t1.data(),
                            t2.data());

This is only a quick hack to debug the problem, It should be moved to somewhere a little bit earlier in the plugin so it does not have to be called again and again for every satellite, also maybe somehow it is possible to identify what exactly is responsible for undoing and messing up the setlocale() that was done in main.cpp

Its happening during initialization of OpenGL

Inserting this into StelMainGraphicsView.cpp, Line 204

 qDebug() << "!!! locale before " << setlocale(LC_NUMERIC, NULL);
 glWidget = new StelQGLWidget(glContext, this);
 qDebug() << "!!! locale after" << setlocale(LC_NUMERIC, NULL);

will print the following to the console:

!!! locale before C
DRM version 1.10 too old to support HyperZ, disabling.
!!! locale after de_DE.UTF-8

This means initializing OpenGL on some (maybe buggy) Systems will cause
LC_NUMERIC being reset to the value of LC_ALL. Therefore I propose the
following patch:

=== modified file 'src/StelMainGraphicsView.cpp'
--- src/StelMainGraphicsView.cpp 2012-02-25 14:13:20 +0000
+++ src/StelMainGraphicsView.cpp 2012-04-19 20:32:06 +0000
@@ -212,6 +212,14 @@

  backItem = new QGraphicsWidget();
  backItem->setFocusPolicy(Qt::NoFocus);
+
+ // Workaround (see Bug #940638) Although we have already explicitly set
+ // LC_NUMERIC to "C" in main.cpp there seems to be a bug in OpenGL where
+ // it will silently reset LC_NUMERIC to the value of LC_ALL during OpenGL
+ // initialization. This has been observed on Ubuntu 11.10 under certain
+ // circumstances, so here we set it again just to be on the safe side.
+ setlocale(LC_NUMERIC, "C");
+ // End workaround
 }

 StelMainGraphicsView::~StelMainGraphicsView()

I have attached the patch as a file to this bug report.

I think more correct rewrite code for gsatellite library for drop sscanf lines.

So is this confirmed? Is someone taking ownership of it?

I can confirm this issue

This bug seems to appear once a KDE application gets installed (I tried Krusader and K3b), but affects only non-KDE environments, namely Unity, Gnome Panel, Xfce and MATE. KDE Plasma session does not produce the bug. I've been able to reproduce this behavior in Virtualbox machine, on my notebook (both running Ubuntu 12.04), and on my desktop (with Linux Mint 12, based on Oneiric).

The bug does not appear in a fresh Ubuntu install.

It also doesn't always result in an immediate freeze, sometimes it takes a few seconds, sometimes it keeps running until I exit the application.
All the satellites are always drawn in one spot on the sky, which is visible if one is looking in the right direction when turning them on, or when one manages to find it before the freeze comes.
Maybe the freeze and the wrong position of satellites are two different bugs, but I never had a freeze when the satellites were placed correctly (or at least spread around the sky).

Debian Testing with the same version of Stellarium does not seem to have this bug.

I don't think satellites have anything to do with the Stellarium freezing bug. I don't have that plugin loaded and it crashes quite often, just a few seconds after launch, mostly when I'm fast forwarding or rewinding time.
I'm using Ubuntu 12.04 with Unity 3D, all packages up-to-date (2012-jun-08).

Glauco: try starting it with

LC_ALL=C stellarium

and see if the freezing is gone.

The bug is triggered in StelMainGraphicsView.cpp, Line 204 as I have already shown in comment #14. Qt or OpenGL or whatever will reset the locale settings exactly during this constructor call.

Stellarium already forces LC_NUMERIC to C somewhere very early in main() but this is too early since it will be reset in exactly the above mentioned line. The fix is easy: Move the setlocale(LC_NUMERIC, "C"); to somewhere later *after* this line (or call it again a second time right after this line) and all these problems will be gone. I don't understand why this fix is not yet committed.

>I don't understand why this fix is not yet committed.

Because this is dirty hack, not fix

> Because this is dirty hack, not fix

This "dirty" hack is already present in the sources, but its broken. Stellarium *does* already set the LC_NUMERIC to C but does it too early. This fix simply makes your "dirty" hack work as intended. And it doesn't break anything, so it can safely be applied.

Diff: http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5422