Hi all , been a bit but i have an odd bug in my github code

for me it i click on " refresh" in the celesta browser ( in the solar system tab) i get a hard CRASH - Seg Fault
BUT

one other person using a different linux OS did not have this issue

so

i need a few linux users to do a git clone
https://github.com/JohnVV/MyCelestiaBuild

and build using qt5

this is bug is present using gcc4.8 , 7 , and 8

MY build code


you will need to still edit the celestia.pro to point to your cspice install and the qmake line above to match YOUR install testing location

my system is
OpenSUSE tumbleweed
nvidia gtx 550 ti
8 gig ram
and using KDE desktop

all software is up to date

PS
"scan-build" and "scan-view" nor strace are telling me anything , nor is dmesg

.

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15.1 & CentOS 7.8

Sorry to read about this problem in your code.

I just pushed the corresponding 'Refresh' button in celestia.Sci: All fine.
[Please, click on image for an improved display]


The problem is not so much to reproduce the crash, but rather to analyze
by what it is triggered

We use the clang 5.02 and/or clang 6.0 compiler with very useful results about finding bugs. Clang finds many more bugs than gcc x.y_64!
So e.g. clang spots memory issues by checking for missing or wrong types of 'delete' ... after 'new' along with many other issues.

Clang is easy to apply. Clang 5 is already part of Qt 5.10.1 which we currently use by default.

Cheers & good luck,
Fridger

PS: we mostly "live" in Github these days . I hope that also Andrew (ajtribick) and Dawoon (DW, dirkpitt) are passing by here soon.

_________________

the main reason i am asking about my git fork is that one person did not have this issue where i AM

scan-view informs me i have 88 bugs , 4 are unused variables - very easy to fix

there are a few mem leaks and a few wrong conversion types
most are the same warnings i get with gcc in the terminal

right now my thinking is this is KDE related
time to install gnome and Enlightenment and see what happens


PS. i am learning a lot and that is the point of all this

also did you keep 3ds support in celestia.scl ? i just removed that last night and is in the current git code

3ds had CAUSED more PROBLEMS than it is worth to have in the program

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15.1 & CentOS 7.8

For me and the team warnings are like errors!
We started with NO warnings from gcc_64 e.g. in Open SuSE Leap.42.3 and in MacOS. Still Clang found subsequently about 80 (!) further issues! Meanwhile all these issues are gone as well.
Our code performs VERY stable indeed.

My suspicions rather concern Tumbleweed + KDE. Some time ago, I had it installed with lots of bad experiences.

No in celestia.Sci .3ds has remained untouched (because of many community add-ons). So far this has not caused any problems.

Cheers,
Fridger

_________________

John,

I have some good news for you: After cloning your code from GitHub, fixing the Spice location in the .pro file and compiling in QtCreator 4.6.0 with Clang and Qt5.10.1, Clang came up with 90 warnings but NO errors. These warnings should be fixed, of course.

After telling QtCreator the WorkingDirectory, the program started fine.

After loading the Celestial Browser and playing a bit with it around the Solar System, I pushed the Refresh button :
All fine, no crash

I used OpenSuse Leap 42.3 + KDE Plasma5 with all updates included (kernel default ==> 4.4.132-53.1.x86_64) and Qt5.10.1 along with Clang 5 and mkspecs: linux-clang

Cheers,
Fridger

PS: Are you aware that Leap and Tumbleweed versions have been repeatedly reported to undergo random freezes (could be what you called a hard crash)! I experienced them also regularly. Typical signature: All GUI stuff stopped reacting, but CTRL+Alt F2 keeps working. After some recent updates the freezes have now vanished in my system.

_________________

so it is MY system causing it

that is good news ( and bad )

Thanks for testing

this will be a short post do to still drinking my FIRST cup of coffee of the day

time to run memtest from a dvd

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15.1 & CentOS 7.8

John,

here is a shader bug in your code that announced itself as follows:

With the Earth being selected and the observer close by, I typed
5 g

to go to Jupiter. The latter appeared however as a uniformly red ball, indicating the crash.
Then going to /tmp and typing
ls -l celestia-shaders.log
revealed that the log file had just been generated . Here is the error part:


Fixing this is not entirely easy...
I still have HD3000 on-board Intel graphics in my laptop and so has Dawoon.
A year ago, we spent quite some time fixing this sort of bugs since the intel HD3000 drivers still tend to be very buggy.
You may simply not encounter this bug for your NVIDIA setting. Fingers crossed

Cheers,
Fridger

_________________

that dose not effect me
i hit "5g" from earth orbit all the tme and even from the near the ground

right now i am looking for OLD qt links that might still point to the wrong header or lib
and rebuild the ld database


this is looking like a issue with my os and the custom install i have


but as a break from this i am getting close to having cmodview and cmodedit build in qt5 , right now it needs qt4

slow progress but i am learning a lot from solving this type of complex puzzle

for me a puzzle HAS to be solved , might take a while but i like solving them


and LEARNING is the point

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15.1 & CentOS 7.8

But other users of your code may still encounter this problem...

Moreover,
6 g
7 g
8 g
also give red balls with my graphics (the rings are OK).

Presumably you remember that I made it compile in 64bit & qt5 quite a while ago.
viewtopic.php?f=11&t=910&start=15#p15000

Certainly a good approach!

Cheers,
Fridger

_________________

John,

sorry, I need to somewhat differentiate my above statements about the occurrence of "red ball bugs":

I cloned another completely untouched copy of your code from GitHub and built it again.
This time Spice is NOT configured, i.e the directory 'SpiceSolarSystem' is not known to the system! Furthermore, in the .pro file I commented out
# SPICE support
# EPHEM_SOURCES += $$SPICE_SOURCES
# EPHEM_HEADERS += $$SPICE_HEADERS
# DEFINES += USE_SPICE

It turns out that the command '5g' (jupiter) now does NOT trigger a red ball and Jupiter is displayed correctly. However, '6g', '7g' and '8g' trigger "red balls" as before! Moreover, typing 'pluto <return>g' on the command line, displays Pluto correctly as before.

Cheers,
Fridger

_________________