Stellarium

stellarium 0.14.3 on FreeBSD 11-CUR amd64 crashes on start

Bug #1608180 reported by Matthias Apitz
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Stellarium
Invalid
High
Unassigned

Bug Description

The system is:

$ uname -a
FreeBSD c720-r292778-amd64 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292778: Mon Dec 28 05:45:37 CET 2015 root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC amd64

and stallarium 0.14.3 crashes on start; the file ~/.stellarium/log.txt contains:

2016-07-31T09:02:54
FreeBSD 11.0-CURRENT amd64
Compiled using Clang 3.7.1
Qt runtime version: 5.5.1
Qt compilation version: 5.5.1
Addressing mode: 64-bit
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
real memory = 4301258752 (4102 MB)
avail memory = 1917730816 (1828 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
vtvga0: <VT VGA driver> on motherboard
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
vgapci0: <VGA-compatible display> port 0x1800-0x183f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff at device 2.0 on pci0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
SMP: AP CPU #1 Launched!
stellarium
 -------------------------------------------------------
[ This is Stellarium 0.14.3 - http://www.stellarium.org ]
[ Copyright (C) 2000-2016 Fabien Chereau et al. ]
 -------------------------------------------------------
Writing log file to: "/home/guru/.stellarium/log.txt"
File search paths:
  0 . "/home/guru/.stellarium"
  1 . "/usr/local/share/stellarium"
Config file "/home/guru/.stellarium/config.ini" does not exist. Copying the default file.
Config file is: "/home/guru/.stellarium/config.ini"
Creating directory "/home/guru/Pictures/Stellarium"
Detected: OpenGL "3.0"
Driver version string: "3.0 Mesa 11.1.2"
GL vendor is "VMware, Inc."
GL renderer is "Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)"
GL Shading Language version is "1.30"
MESA Version Number detected: 11.1
Mesa version is fine, we should not see a graphics problem.
GLSL Version Number detected: 1.3
GLSL version is fine, we should not see a graphics problem.
Cache directory is: "/home/guru/.cache/stellarium/stellarium"
Sky language is "es_ES"
Application language is "es_ES"
Loading Solar System data ...
Could not find the starsConfig.json file: will copy the default one.
Creating directory "/home/guru/.stellarium/stars/default"
Creates file "/home/guru/.stellarium/stars/default/starsConfig.json"
Loading star data ...
"Loading \"/usr/local/share/stellarium/stars/default/stars_0_0v0_5.cat\": 0_0v0_2; 4963"
"Loading \"/usr/local/share/stellarium/stars/default/stars_1_0v0_5.cat\": 1_0v0_2; 21598"
"Loading \"/usr/local/share/stellarium/stars/default/stars_2_0v0_5.cat\": 2_0v0_2; 150090"
"Loading \"/usr/local/share/stellarium/stars/default/stars_3_1v0_3.cat\": 3_1v0_3; 428466"
Finished loading star catalogue data, max_geodesic_level: 3
navigation/preset_sky_time is a double - treating as jday: "2451514.25001"
Reloading DSO data...
Loaded 10756 DSO records
Loading DSO name data ...
Loaded 221 / 297 DSO name records successfully
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Loading star names from "/usr/local/share/stellarium/skycultures/western/star_names.fab"
Loaded 339 / 339 common star names
Loading star names from "/usr/local/share/stellarium/stars/default/name.fab"
Loaded 4506 / 4506 scientific star names
Loading variable stars from "/usr/local/share/stellarium/stars/default/gcvs_hip_part.dat"
Loaded 6916 / 6916 variable stars
Loading cross-index data from "/usr/local/share/stellarium/stars/default/cross-index.dat"
Loaded 108279 / 108279 cross-index data records
Loaded 88 / 88 constellation records successfully for culture "western"
Loaded 85 / 85 constellation art records successfully for culture "western"
Loaded 88 / 88 constellation names
Loading constellation boundary data ...
Loaded 782 constellation boundary segments
Initializing basic GL shaders...
Creating GUI ...
libpng warning: iCCP: known incorrect sRGB profile
Loaded plugin "Exoplanets"
Creating directory "/home/guru/.stellarium/modules/Exoplanets"
Exoplanets: no Exoplanets section exists in main config file - creating with defaults
Exoplanets: exoplanets.json does not exist - copying default catalog to "/home/guru/.stellarium/modules/Exoplanets/exoplanets.json"
Exoplanets: default exoplanets.json to "/home/guru/.stellarium/modules/Exoplanets/exoplanets.json"
Exoplanets: loading catalog file: "/home/guru/.stellarium/modules/Exoplanets/exoplanets.json"
Loaded plugin "FOV"
FOV: no fov section exists in main config file - creating with defaults
Loaded plugin "MeteorShowers"
libpng warning: iCCP: known incorrect sRGB profile
Creating directory "/home/guru/.stellarium/modules/MeteorShowers"
MeteorShowersMgr: Loading catalog file: "/home/guru/.stellarium/modules/MeteorShowers/showers.json"
MeteorShowersMgr: Trying to restore the default catalog to "/home/guru/.stellarium/modules/MeteorShowers/showers.json"
MeteorShowersMgr: The default catalog was copied!
MeteorShowersMgr: Starting to update the catalog...
Loaded plugin "Novae"
Creating directory "/home/guru/.stellarium/modules/Novae"
Novae: no Novae section exists in main config file - creating with defaults
Novae: novae.json does not exist - copying default file to "/home/guru/.stellarium/modules/Novae/novae.json"
Novae: copied default novae.json to "/home/guru/.stellarium/modules/Novae/novae.json"
Novae: loading catalog file: "/home/guru/.stellarium/modules/Novae/novae.json"
Loaded plugin "Oculars"
Ocular plugin - press Command-O to toggle eyepiece view mode. Press ALT-o for configuration.
Creating directory "/home/guru/.stellarium/modules/Oculars"
Oculars::validateIniFile copied default_ocular.ini to "/home/guru/.stellarium/modules/Oculars/ocular.ini"
Loaded plugin "Satellites"
Creating directory "/home/guru/.stellarium/modules/Satellites"
Satellites::init satellites.json does not exist - copying default file to "/home/guru/.stellarium/modules/Satellites/satellites.json"
Satellites::init copied default satellites.json to "/home/guru/.stellarium/modules/Satellites/satellites.json"
Satellites::init copied default qs.mag to "/home/guru/.stellarium/modules/Satellites/qs.mag"
Satellites: loading catalog file: "/home/guru/.stellarium/modules/Satellites/satellites.json"
Satellite has invalid orbit: "DELTA 1 R/B" "08063"
Satellite has invalid orbit: "SL-8 R/B" "12389"
Satellite has invalid orbit: "SL-8 R/B" "14484"
Satellite has invalid orbit: "FLOCK 1B-27" "40422"
Satellite has invalid orbit: "FLOCK 1B-28" "40423"
Satellite has invalid orbit: "FLOCK 1B-21" "40427"
Satellite has invalid orbit: "FLOCK 1B-22" "40428"
Satellite has invalid orbit: "FLOCK 1B-10" "40429"
Satellite has invalid orbit: "FLOCK 1B-9" "40430"
Satellite has invalid orbit: "FLOCK 1D-1" "40451"
Satellite has invalid orbit: "FLOCK 1D-2" "40452"
Satellite has invalid orbit: "FLOCK 1B-5" "40453"
Satellite has invalid orbit: "FLOCK 1B-6" "40454"
Satellite has invalid orbit: "GEARRS-1" "40456"
Satellite has invalid orbit: "MICROMAS" "40457"
Satellite has invalid orbit: "FLOCK 1B-11" "40459"
Satellite has invalid orbit: "FLOCK 1B-12" "40460"
Loaded plugin "SolarSystemEditor"
Trying to copy ssystem.ini to "/home/guru/.stellarium/data/ssystem.ini"
Unable to find module called "TimeZoneConfiguration"
Loaded plugin "TimeZoneConfiguration"

and on the terminal it says in addition:

...
Illegal instruction ('core' generated).

Please, let me know if you need more information.

Tags: crash freebsd
Mo Sommer (msom)
Changed in stellarium:
status: New → Confirmed
Revision history for this message
Alexander Wolf (alexwolf) wrote :

Please try run stellarium -d and attach log.txt here.

tags: added: crash freebsd
Revision history for this message
Mo Sommer (msom) wrote :

file ~/.stellarium/log.txt is attached

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks! Bad news - can you build stellarium from source code in debug mode and run it through gdb?

Revision history for this message
gzotti (georg-zotti) wrote :

EXT_gpu_shader4 MISSING!

This test result may indicate that the GPU driver reporting GLSL1.3 is not enough. We do not have enough samples yet, but https://en.wikipedia.org/wiki/OpenGL#OpenGL_3.0 indicates this extension is essential, therefore we test for it explicitly at least in the -d test.

Did any previous version of Stellarium (0.13 or later) run on this system? The processor graphics is reported to support Intel HD (OpenGL4?) on Windows, but I don't know capabilities of BSD Mesa GPU drivers.

Revision history for this message
Matthias Apitz (gubu) wrote :

I'm using on the identical hardware (Acer C720) and the same version of FreeBSD (r292778) the stellarium version 0.14.1 whichout any crash; a log.txt of -d is attached; please let me know if I should recompile 0.14.3 with any additional (debug) flags or with gcc option -g to gather a bt in gdb;

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

Can you show us your C[XX]FLAGS? Perhaps your CPU does not support some instruction(s) that compiler is generating due to presence of -march=<wrong-cpu> or even -march=native. Version 0.14.1's code might not trigger this particular code generation logic (optimization) in the compiler.

You might also want to set -O0 to disable all optimizations, or try GCC instead of Clang (default compiler on contemporary FreeBSD versions) and see if it changes anything.

Revision history for this message
Matthias Apitz (gubu) wrote :

I'm attaching the log file of the build with clang; and the build with gcc and -O0; with the latter stellarium crashes without saying any line;

Revision history for this message
Matthias Apitz (gubu) wrote :
Alexander Wolf (alexwolf)
Changed in stellarium:
importance: Undecided → High
Revision history for this message
Matthias Apitz (gubu) wrote :

I compiled a version with clang, CFLAGS=-O0 -g and without strip the binaries to get a better gdb bt, without any luck; a bt does not show any symbol names; ideas?

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (3.9 KiB)

I checked the build log of poudriere for the port astro/stellarium; poudriere installs into the build jail 117 existing other packages (see the list below); I will remove them all to force poudriere to rebuild them and it dependencies with -g and without strip the binaries; maybe this will get us a backtrace with better information:

Installing cmake-3.5.2...
Installing expat-2.1.0_3...
Installing cmake-modules-3.5.2...
Installing curl-7.48.0_2...
Installing ca_root_nss-3.22.2...
Installing libarchive-3.1.2_6,1...
Installing lzo2-2.09...
Installing jsoncpp-0.6.0.r2_2...
Installing gettext-tools-0.19.7...
Installing indexinfo-0.2.4...
Installing gettext-runtime-0.19.7...
Installing qt5-buildtools-5.5.1...
Installing perl5-5.20.3_12...
Installing qt5-concurrent-5.5.1...
Installing qt5-core-5.5.1...
Installing icu-55.1...
Installing pcre-8.38_1...
Installing glib-2.46.2...
Installing libiconv-1.14_9...
Installing python27-2.7.11_2...
Installing libffi-3.2.1...
Installing readline-6.3.8...
Installing qt5-gui-5.5.1...
Installing encodings-1.0.4_3,1...
Installing font-util-1.3.1...
Installing harfbuzz-1.2.3...
Installing cairo-1.14.6,2...
Installing dri2proto-2.8...
Installing fontconfig-2.11.1_1,1...
Installing freetype2-2.6.3...
Installing glproto-1.4.17...
Installing libXext-1.3.3_1,1...
Installing xproto-7.0.28...
Installing libXau-1.0.8_3...
Installing libX11-1.6.3,1...
Installing kbproto-1.0.7...
Installing libXdmcp-1.1.2...
Installing libxcb-1.11.1...
Installing libxml2-2.9.3...
Installing libpthread-stubs-0.3_6...
Installing xextproto-7.3.0...
Installing libEGL-11.1.2...
Installing libdevq-0.0.2_1...
Installing libXdamage-1.1.4_3...
Installing libXfixes-5.0.1_3...
Installing fixesproto-5.0...
Installing damageproto-1.2.1...
Installing libxshmfence-1.2...
Installing gbm-11.1.2...
Installing libglapi-11.1.2...
Installing libXvMC-1.0.9...
Installing libXv-1.0.10_3,1...
Installing videoproto-2.3.2...
Installing libdrm-2.4.66,1...
Installing libpciaccess-0.13.4...
Installing pciids-20160412...
Installing llvm37-3.7.1_2...
Installing libedit-3.1.20150325_2...
Installing png-1.6.21...
Installing libXrender-0.9.9...
Installing renderproto-0.11.1...
Installing libGL-11.1.2...
Installing libXxf86vm-1.1.4_1...
Installing xf86vidmodeproto-2.3.1...
Installing pixman-0.34.0...
Installing xcb-util-renderutil-0.3.9_1...
Installing xcb-util-0.4.0_1,1...
Installing graphite2-1.3.8...
Installing libSM-1.2.2_3,1...
Installing libICE-1.0.9_1,1...
Installing xcb-util-image-0.4.0_1...
Installing xcb-util-wm-0.4.1_3...
Installing libxkbcommon-0.5.0_1...
Installing xcb-util-keysyms-0.4.0_1...
Installing libXi-1.7.6,1...
Installing inputproto-2.3.1...
Installing qt5-dbus-5.5.1...
Installing dbus-1.8.20...
Installing gnome_subr-1.0...
Installing jpeg-turbo-1.4.2...
Installing xorg-fonts-truetype-7.7_1...
Installing font-misc-meltho-1.0.3_3...
Installing mkfontdir-1.0.7...
Installing mkfontscale-1.1.2...
Installing libfontenc-1.1.3...
Installing font-bh-ttf-1.0.3_3...
Installing font-misc-ethiopic-1.0.3_3...
Installing dejavu-2.35...
Installing xdg-utils-1.1.1...
Installing hicolor-icon-theme-0.15...
Installing xset-1.2.3_1...
Installing libXfontcache-1.0.5_3...
Ins...

Read more...

Revision history for this message
Matthias Apitz (gubu) wrote :

I'm attaching a photo taken in the moment short before the crash to show how far the GUI went; in the left upper part of the display is already a small window, knowing the position Paris; it crashes before going fullscreen.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Please try set video/fullscreen = false in ~/.stellarium/config.ini and check it again.

Revision history for this message
Matthias Apitz (gubu) wrote :

Setting fullscreen = false does not avoid the crash, only the target window for resizing the small one in the left upper part now has a frame and title bar.

I recompiled some 120 packages with debug info, forced installed them, copied the stellarium sources in place and can set a break point in main, list etc. but when I let it run the bt after the crash does not show any function names;

there was a hint in freebsd-ports@ about mixture of clang's libc++.so and gcc's libstdc++.so but only libc++ is loaded as ldd shows;

Revision history for this message
Matthias Apitz (gubu) wrote :

Re/ the backtrace: I forgot that stellarium is threaded and I have to use "thread apply all bt" to get the bt; now attached;

Revision history for this message
Alexander Wolf (alexwolf) wrote :

astro/stellarium port on FreeBSD has been updated to version 0.15.0_1 - please check it.

Revision history for this message
Matthias Apitz (gubu) wrote :

I've checked this already on the weekend, but only updated this singular port to 0.15.0_1. I was even surprised that it compiled against all other ports in that jail with a tree being from 1st of May. I started yesterday in a new jail the compilation of all ports based on SVN head of August 6. The will take a few more days and I will report back.

Revision history for this message
Matthias Apitz (gubu) wrote :

I have updated the complete system to ports from head as of August 6, which brings among others stellarium 0.15.0_1; the crash remains the same with the same symtoms: the GUI comes up as a small window in the upper right corner, than it crashes;

Revision history for this message
Matthias Apitz (gubu) wrote :

I have built a memstick with 12-CURRENT (r303343) and installed into it the packages pkg, xorg, kde and stellarium (and all its ~800 dependencies) of a ports build of July 16 (r418627), stellarium is 0.14.3 at this level; the memstick works nice on my Dell Latitude E6330 and Acer C720; on the Dell stellarium works fine, on the Acer C720 it crashes with the known simptoms: it starts and when it will bring the GUI to full screen, it crashes.

Revision history for this message
Matthias Apitz (gubu) wrote :

log file from Dell E6330 (stellarium -d), no crash

Revision history for this message
Matthias Apitz (gubu) wrote :

log file from Acer C720 (stellarium -d), crashed

Revision history for this message
Matthias Apitz (gubu) wrote :

I have update the OS to FreeBSD 12-CURRENT r314251 (2017-02-25) and stellarium to 0.15.1; the crash in the moment to bring the GUI on screen remains the same:

...
Loading constellation boundary data ...
Loaded 782 constellation boundary segments
Initializing basic GL shaders...
Creating GUI ...
Loaded plugin "Oculars"
Ocular plugin - press Command-O to toggle eyepiece view mode. Press ALT-o for configuration.
Oculars::validateIniFile ocular.ini exists at: "/home/guru/.stellarium/modules/Oculars/ocular.ini" . Checking version...
Oculars::validateIniFile found existing ini file version 3.1
Loaded plugin "Satellites"
[Satellites] loading catalog file: "/home/guru/.stellarium/modules/Satellites/satellites.json"
Satellite has invalid orbit: "CADRE" "41475"
Loaded plugin "SolarSystemEditor"
Using the ssystem.ini file that already exists in the user directory...
Illegal instruction (core dumped)

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Please attach a log and could you build it in debug mode and get a trace?

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Hmm... could you remove ~/.stelarium/data/ssystem.ini file and check it again?

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (29.6 KiB)

removing ~/.stellarium does not help;

I recompiled it with -O0 -g and here is the 'bt' from gdb:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `work/stellarium-0.15.1/src/stellarium'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done.
done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/qt5/libQt5Concurrent.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Concurrent.so.5
Reading symbols from /usr/local/lib/qt5/libQt5OpenGL.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5OpenGL.so.5
Reading symbols from /usr/local/lib/qt5/libQt5PrintSupport.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5PrintSupport.so.5
Reading symbols from /usr/local/lib/qt5/libQt5MultimediaWidgets.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5MultimediaWidgets.so.5
Reading symbols from /usr/local/lib/qt5/libQt5Script.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Script.so.5
Reading symbols from /usr/local/lib/qt5/libQt5SerialPort.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5SerialPort.so.5
Reading symbols from /usr/local/lib/qt5/libQt5Multimedia.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Multimedia.so.5
Reading symbols from /usr/local/lib/qt5/libQt5Network.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Network.so.5
Reading symbols from /usr/local/lib/qt5/libQt5Widgets.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Widgets.so.5
Reading symbols from /usr/local/lib/qt5/libQt5Gui.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Gui.so.5
Reading symbols from /usr/local/lib/libGL.so.1...done.
Loaded symbols for /usr/local/lib/libGL.so.1
Reading symbols from /usr/local/lib/qt5/libQt5Core.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Core.so.5
Reading symbols from /usr/lib/libc++.so.1...Reading symbols from /usr/lib/debug//usr/lib/libc++.so.1.debug...done.
done.
Loaded symbols for /usr/lib/libc++.so.1
Reading symbols from /lib/libcxxrt.so.1...Reading symbols from /usr/lib/debug//lib/libcxxrt.so.1.debug...done.
done.
Loaded symbols for /lib/libcxxrt.so.1
Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done.
done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...Reading symbols from /usr/lib/debug//lib/libgcc_s.so.1.debug...done.
done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done.
done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done.
done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libpr...

Revision history for this message
Alexander Wolf (alexwolf) wrote :

It's weird. FreeBSD has a specific key for compiler (see -pthread in cmake script). Could you attach output data from 'ldd stellarium'?

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (3.7 KiB)

# ldd work/stellarium-0.15.1/src/stellarium
work/stellarium-0.15.1/src/stellarium:
 libz.so.6 => /lib/libz.so.6 (0x801602000)
 libQt5Concurrent.so.5 => /usr/local/lib/qt5/libQt5Concurrent.so.5 (0x80181a000)
 libQt5OpenGL.so.5 => /usr/local/lib/qt5/libQt5OpenGL.so.5 (0x801a1f000)
 libQt5PrintSupport.so.5 => /usr/local/lib/qt5/libQt5PrintSupport.so.5 (0x801c76000)
 libQt5MultimediaWidgets.so.5 => /usr/local/lib/qt5/libQt5MultimediaWidgets.so.5 (0x801edd000)
 libQt5Script.so.5 => /usr/local/lib/qt5/libQt5Script.so.5 (0x8020fb000)
 libQt5SerialPort.so.5 => /usr/local/lib/qt5/libQt5SerialPort.so.5 (0x8024ce000)
 libQt5Multimedia.so.5 => /usr/local/lib/qt5/libQt5Multimedia.so.5 (0x8026e3000)
 libQt5Network.so.5 => /usr/local/lib/qt5/libQt5Network.so.5 (0x8029c1000)
 libQt5Widgets.so.5 => /usr/local/lib/qt5/libQt5Widgets.so.5 (0x802e00000)
 libQt5Gui.so.5 => /usr/local/lib/qt5/libQt5Gui.so.5 (0x803800000)
 libGL.so.1 => /usr/local/lib/libGL.so.1 (0x803e92000)
 libQt5Core.so.5 => /usr/local/lib/qt5/libQt5Core.so.5 (0x804200000)
 libc++.so.1 => /usr/lib/libc++.so.1 (0x8048b7000)
 libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b76000)
 libm.so.5 => /lib/libm.so.5 (0x804d95000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804fc0000)
 libthr.so.3 => /lib/libthr.so.3 (0x8051d5000)
 libc.so.7 => /lib/libc.so.7 (0x8053fc000)
 libproxy.so.1 => /usr/local/lib/libproxy.so.1 (0x8057bb000)
 libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x8059dd000)
 libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x805c7e000)
 libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x805eb8000)
 libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x8060e2000)
 libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x8062e4000)
 libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x8064e6000)
 libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x8066ec000)
 libglapi.so.0 => /usr/local/lib/libglapi.so.0 (0x8068ed000)
 libXext.so.6 => /usr/local/lib/libXext.so.6 (0x806b41000)
 libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x806d52000)
 libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x806f54000)
 libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x807159000)
 libX11.so.6 => /usr/local/lib/libX11.so.6 (0x80735a000)
 libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x807696000)
 libxcb-glx.so.0 => /usr/local/lib/libxcb-glx.so.0 (0x8078bb000)
 libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x807ad4000)
 libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x807cd8000)
 libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x807edc000)
 libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8080eb000)
 libicui18n.so.58 => /usr/local/lib/libicui18n.so.58 (0x808400000)
 libicuuc.so.58 => /usr/local/lib/libicuuc.so.58 (0x8088aa000)
 libpcre16.so.0 => /usr/local/lib/libpcre16.so.0 (0x808c65000)
 libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x808ed5000)
 libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8091de000)
 libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x8093e9000)
 libgraphite2.so.3 => /usr/local/lib/libgraphite2.so.3 (0x80968f000)
 libXau.so.6 => /usr/local/lib/libXau.so.6 (0x8098c2000)
 libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 (0x809ac4000)
 libXdmcp.so.6 => ...

Read more...

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks! Looks good. Could you please show 'lspci | grep VGA' and 'glxinfo | grep "OpenGL renderer string"' (or 'lshw -numeric -c video')?

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (3.2 KiB)

seems we neither have 'lspci' nor 'lshw' in FreeBSD; I have here:

# pciconf -lv
hostb0@pci0:0:0:0: class=0x060000 card=0x0a111025 chip=0x0a048086 rev=0x09 hdr=0x00
    vendor = 'Intel Corporation'
    device = 'Haswell-ULT DRAM Controller'
    class = bridge
    subclass = HOST-PCI
vgapci0@pci0:0:2:0: class=0x030000 card=0x0a111025 chip=0x0a068086 rev=0x09 hdr=0x00
    vendor = 'Intel Corporation'
    device = 'Haswell-ULT Integrated Graphics Controller'
    class = display
    subclass = VGA
hdac0@pci0:0:3:0: class=0x040300 card=0x0a111025 chip=0x0a0c8086 rev=0x09 hdr=0x00
    vendor = 'Intel Corporation'
    device = 'Haswell-ULT HD Audio Controller'
    class = multimedia
    subclass = HDA
xhci0@pci0:0:20:0: class=0x0c0330 card=0x0a111025 chip=0x9c318086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series USB xHCI HC'
    class = serial bus
    subclass = USB
none0@pci0:0:21:0: class=0x080102 card=0x0a111025 chip=0x9c608086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series Low Power Sub-System DMA'
    class = base peripheral
    subclass = DMA controller
ig4iic_pci0@pci0:0:21:1: class=0x0c8000 card=0x0a111025 chip=0x9c618086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series I2C Controller'
    class = serial bus
ig4iic_pci1@pci0:0:21:2: class=0x0c8000 card=0x0a111025 chip=0x9c628086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series I2C Controller'
    class = serial bus
hdac1@pci0:0:27:0: class=0x040300 card=0x0a111025 chip=0x9c208086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series HD Audio Controller'
    class = multimedia
    subclass = HDA
pcib1@pci0:0:28:0: class=0x060400 card=0x0a111025 chip=0x9c108086 rev=0xe4 hdr=0x01
    vendor = 'Intel Corporation'
    device = '8 Series PCI Express Root Port 1'
    class = bridge
    subclass = PCI-PCI
ehci0@pci0:0:29:0: class=0x0c0320 card=0x0a111025 chip=0x9c268086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series USB EHCI'
    class = serial bus
    subclass = USB
isab0@pci0:0:31:0: class=0x060100 card=0x0a111025 chip=0x9c458086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series LPC Controller'
    class = bridge
    subclass = PCI-ISA
ahci0@pci0:0:31:2: class=0x010601 card=0x0a111025 chip=0x9c038086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series SATA Controller 1 [AHCI mode]'
    class = mass storage
    subclass = SATA
none1@pci0:0:31:3: class=0x0c0500 card=0x0a111025 chip=0x9c228086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series SMBus Controller'
    class = serial bus
    subclass = SMBus
none2@pci0:0:31:6: class=0x118000 card=0x0a111025 chip=0x9c248086 rev=0x04 hdr=0x00
    vendor = 'Intel Corporation'
    device = '8 Series Thermal'
    class = dasp
ath0@pci0:1:0:0: class=0x028000 card=0xe058105b chip=0x0034168c rev=0x01 hdr=0x00
    vendor = 'Qualcomm Atheros'
...

Read more...

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

Thanks for the back trace. Can you also issue the following commands (in gdb, after it crashes, assuming the crash address from the backtrace did not change):

(gdb) x/i 0x000000080159472b
(gdb) disass 0x000000080159472b

or

(gdb) layout asm

This may help to locate the critical place.

Revision history for this message
Matthias Apitz (gubu) wrote : Re: [Bug 1608180] Re: stellarium 0.14.3 on FreeBSD 11-CUR amd64 crashes on start

El día lunes, marzo 13, 2017 a las 05:49:51a. m. -0000, Alexey Dokuchaev escribió:

> Thanks for the back trace. Can you also issue the following commands
> (in gdb, after it crashes, assuming the crash address from the backtrace
> did not change):
>
> (gdb) x/i 0x000000080159472b
> (gdb) disass 0x000000080159472b

# # gdb work/stellarium-0.15.1/src/stellarium stellarium.core
GNU gdb 6.1.1 [FreeBSD]
...
(gdb) x/i 0x000000080159472b
0x80159472b: (bad)

(gdb) disass 0x000000080159472b
No function contains specified address.

>
> or
>
> (gdb) layout asm

(gdb) layout asm
   ┌───────────────────────────────────────────────────────────────────────────────────────────────┐
  >│0x80159472b (bad) │
   │0x80159472c loop 0x801594776 │
   │0x80159472e not %edx │
   │0x801594730 lea -0x7f(%rdx,%rax,1),%edx │
   │0x801594734 cmp %ecx,%edx │
   │0x801594736 cmovle %edx,%ecx │
   │0x801594739 cmp %eax,%ecx │
   │0x80159473b cmovl %eax,%ecx │
   │0x80159473e movd %ecx,%xmm4 │
   │0x801594742 psrld %xmm4,%xmm2 │
   │0x801594746 pxor %xmm8,%xmm8 │
   │0x80159474b pmaxsd %xmm3,%xmm2 │
   │0x801594750 movslq %ecx,%rax │
   │0x801594753 movd 0x108(%rdi,%rax,4),%xmm4 │
   │0x80159475c pshufd $0x0,%xmm4,%xmm6 │
   │0x801594761 movslq 0x178(%rdi,%rax,4),%rax │
   │0x801594769 add 0x100(%rdi),%rax │
   └───────────────────────────────────────────────────────────────────────────────────────────────┘
FreeBSD-co Thread 80b76b9 In: Line: ?? PC: 0x80159472b
(gdb)

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

OK, if my assembly is correct, there should be something like this shortly after the faulty instruction.

    -8<-
   e: 66 0f 6e e1 movd %ecx,%xmm4
  12: 66 0f d2 d4 psrld %xmm4,%xmm2
  16: 66 45 0f ef c0 pxor %xmm8,%xmm8
  1b: 66 0f 38 3d d3 pmaxsd %xmm3,%xmm2
  20: 48 63 c1 movslq %ecx,%rax
  23: 66 0f 6e a4 87 08 01 movd 0x108(%rdi,%rax,4),%xmm4
    -8<-

(This is copy-paste of that code you quited run through as(1)). I'd like to know which file this SIMD code comes from. Let's pick the last line above (just as example, you might want to adjust it) and do some grepping.

First, quick sanity check that core dump itself contains this code (it should):

$ perl -e 'open(F, "<:raw", $ARGV[0]) or die $! ; while(<F>) { if (/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; } }' stellarium.core

If it does not print "found (stellarium.core)" then I screwed up somewhere or need more information.

If it does, then we can try to find which executable file or library contains this code:

$ perl -e 'open(F, "<:raw", $ARGV[0]) or die $! ; while(<F>) { if (/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; } }' /usr/local/bin/stellarium

$ find /usr/local/lib /usr/lib /lib -type f -exec perl -e 'open(F, "<:raw", $ARGV[0]) or die $! ; while(<F>) { if (/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; } }' '{}' \;

Note that the last command will most likely take considerable amount of time to run since we're using not the most efficient binary string search here.

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (3.1 KiB)

# cd /usr/ports/astro/stellarium
# perl -e 'open(F, "<:raw", $ARGV[0]) or die $! ; while(<F>) { if (/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; } }' stellarium.core
found (stellarium.core)

# perl -e 'open(F, "<:raw", $ARGV[0]) or die $! ; while(<F>) { if (/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; } }' work/stellarium-0.15.1/src/stellarium

# find /usr/local/lib /usr/lib /lib -type f -exec perl -e 'open(F,"<:raw", $ARGV[0]) or die $! ; while(<F>) { if(/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; }}' '{}' \;
#

i.e. the code is found it the stellarium.core, but not in the executeable and
not in the shared libs;

Does stellarium uses dlopen(3C) to load additional shared libs?

I did in addition with the libs from the ldd output:

# for i in `cat libs` ; do echo grep $i : ; perl -e 'open(F,"<:raw", $ARGV[0]) or die $! ; while(<F>) { if(/\x66\x0f\x6e\xa4\x87\x08\x01/) { print "found ($ARGV[0])\n"; exit; }}' $i ; done
grep /lib/libz.so.6 :grep /usr/local/lib/qt5/libQt5Concurrent.so.5 :
grep /usr/local/lib/qt5/libQt5OpenGL.so.5 :
grep /usr/local/lib/qt5/libQt5PrintSupport.so.5 :
grep /usr/local/lib/qt5/libQt5MultimediaWidgets.so.5 :
grep /usr/local/lib/qt5/libQt5Script.so.5 :
grep /usr/local/lib/qt5/libQt5SerialPort.so.5 :
grep /usr/local/lib/qt5/libQt5Multimedia.so.5 :
grep /usr/local/lib/qt5/libQt5Network.so.5 :
grep /usr/local/lib/qt5/libQt5Widgets.so.5 :
grep /usr/local/lib/qt5/libQt5Gui.so.5 :
grep /usr/local/lib/libGL.so.1 :
grep /usr/local/lib/qt5/libQt5Core.so.5 :
grep /usr/lib/libc++.so.1 :
grep /lib/libcxxrt.so.1 :
grep /lib/libm.so.5 :
grep /lib/libgcc_s.so.1 :
grep /lib/libthr.so.3 :
grep /lib/libc.so.7 :
grep /usr/local/lib/libproxy.so.1 :
grep /usr/local/lib/libharfbuzz.so.0 :
grep /usr/local/lib/libpng16.so.16 :
grep /usr/local/lib/libexpat.so.1 :
grep /usr/local/lib/libxcb-dri3.so.0 :
grep /usr/local/lib/libxcb-present.so.0 :
grep /usr/local/lib/libxcb-sync.so.1 :
grep /usr/local/lib/libxshmfence.so.1 :
grep /usr/local/lib/libglapi.so.0 :
grep /usr/local/lib/libXext.so.6 :
grep /usr/local/lib/libXdamage.so.1 :
grep /usr/local/lib/libXfixes.so.3 :
grep /usr/local/lib/libX11-xcb.so.1 :
grep /usr/local/lib/libX11.so.6 :
grep /usr/local/lib/libxcb.so.1 :
grep /usr/local/lib/libxcb-glx.so.0 :
grep /usr/local/lib/libxcb-dri2.so.0 :
grep /usr/local/lib/libXxf86vm.so.1 :
grep /usr/local/lib/libdrm.so.2 :
grep /usr/lib/libexecinfo.so.1 :
grep /usr/local/lib/libicui18n.so.58 :
grep /usr/local/lib/libicuuc.so.58 :
grep /usr/local/lib/libpcre16.so.0 :
grep /usr/local/lib/libglib-2.0.so.0 :
grep /usr/local/lib/libintl.so.8 :
grep /usr/local/lib/libfreetype.so.6 :
grep /usr/local/lib/libgraphite2.so.3 :
grep /usr/local/lib/libXau.so.6 :
grep /usr/local/lib/libpthread-stubs.so.0 :
grep /usr/local/lib/libXdmcp.so.6 :
grep /usr/local/lib/libdevq.so.0 :
grep /lib/libelf.so.2 :
grep /usr/local/lib/libicudata.so.58 :
grep /usr/local/lib/libiconv.so.2 :
grep /usr/local/lib/libpcre.so.1 :
grep /usr/lib/libbz2.so.4 :
grep /usr/lib/libprocstat.so.1 :
grep /lib/libkvm.so.7 :
grep /lib/libutil.so.9 :

--
Matthias Apitz, ✉ <email address hidden>, ⌂ http://www.unixarea.de/ ☎ +49-176-3890204...

Read more...

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

That's strange... Could it be some kind of memory corruption?

Try to install gdb711 (devel/gdb port), then do this:

$ gdb711 ./stellarium
$ disas /r 0x000000080159472b
$ r
$ disas /r 0x000000080159472b

Would it show any differences?

Revision history for this message
Matthias Apitz (gubu) wrote :

El día lunes, marzo 13, 2017 a las 01:50:13p. m. -0000, Alexey Dokuchaev escribió:

> That's strange... Could it be some kind of memory corruption?
>
> Try to install gdb711 (devel/gdb port), then do this:
>
> $ gdb711 ./stellarium
> $ disas /r 0x000000080159472b
> $ r
> $ disas /r 0x000000080159472b
>
> Would it show any differences?

I will do this later; as well I will run the perl-grep over the night
over all files below /usr; I have somehow the feeling that the code is
loaded, but not as a shared lib, somehow otherwise from another file...

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

OK, sounds like a plan. One thing you might want to do is instead of grepping for "movd 0x108(%rdi,%rax,4),%xmm4" (that is, 66 0f 6e a4 87 08 01), grep for actual opcodes of the faulty instruction (I originally did not use it because I didn't know exact opcode string, but "disas /r" from new gdb should give you both the opcodes and mnemonics).

Revision history for this message
Matthias Apitz (gubu) wrote :

El día lunes, marzo 13, 2017 a las 02:32:46p. m. -0000, Alexey Dokuchaev escribió:

> OK, sounds like a plan. One thing you might want to do is instead of
> grepping for "movd 0x108(%rdi,%rax,4),%xmm4" (that is, 66 0f 6e a4 87 08
> 01), grep for actual opcodes of the faulty instruction (I originally did
> not use it because I didn't know exact opcode string, but "disas /r"
> from new gdb should give you both the opcodes and mnemonics).

we need a better plan :-(

the grepping does not get any hits (apart of the core file);

launching stellarium below GDB (anyway if gdb or gdb7121) just hangs
where normally the crash occurs; maybe some resource problem;

I'm open for new plans/ideas;

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

> launching stellarium below GDB (anyway if gdb or gdb7121) just hangs
> where normally the crash occurs; maybe some resource problem;

Not sure if I understand you correctly here. Do you mean that it's not possible to do the test I asked for in comment #33?

Revision history for this message
Matthias Apitz (gubu) wrote :

El d�a Tuesday, March 14, 2017 a las 08:13:56AM -0000, Alexey Dokuchaev escribi�:

> > launching stellarium below GDB (anyway if gdb or gdb7121) just hangs
> > where normally the crash occurs; maybe some resource problem;
>
> Not sure if I understand you correctly here. Do you mean that it's not
> possible to do the test I asked for in comment #33?

Re/ comment #33

> Try to install gdb711 (devel/gdb port), then do this:

installed OK (7121)

> $ gdb711 ./stellarium
> $ disas /r 0x000000080159472b

gives someting like 'not in function'

> $ r

the 'r' command starts stellarium, splash appears, small GUI window in
left upper corner of display; then it hangs and I have to kill the gdb
proc.

> $ disas /r 0x000000080159472b

could not be done due to hanging/killed gbd session

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

OK, would replacing "disas /r 0x000000080159472b" with "disas /r 0x000000080159472b-16,0x000000080159472b+16" help?

Also, can you install sysutils/ltrace and post "ltrace -C stellarium" output?

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

Apart from memory corruption, it also could be that Stellarium ends up executing wrong memory for some reason. Can you mount linprocfs(5) and "cat /compat/linux/proc/<stellaium-pid>/maps"?

Revision history for this message
Matthias Apitz (gubu) wrote :
Download full text (46.1 KiB)

# gdb7121 work/stellarium-0.15.1/src/stellarium stellarium.core
...
Core was generated by `work/stellarium-0.15.1/src/stellarium'.
Program terminated with signal SIGILL, Illegal instruction.
#0 0x000000080159a72b in ?? ()

(I recompiled work/stellarium-0.15.1/src/stellarium last night and the
place in the mathcing core file moved a bit)

(gdb) disas /r 0x000000080159a72b-16,0x000000080159a72b+16
Dump of assembler code from 0x80159a71b to 0x80159a73b:
   0x000000080159a71b: 29 8b 8f f8 00 00 sub %ecx,0xf88f(%rbx)
   0x000000080159a721: 00 66 0f add %ah,0xf(%rsi)
   0x000000080159a724: 7e ea jle 0x80159a710
   0x000000080159a726: be 17 08 00 00 mov $0x817,%esi
=> 0x000000080159a72b: c4 e2 48 f7 d2 bextr %esi,%edx,%edx
   0x000000080159a730: 8d 54 02 81 lea -0x7f(%rdx,%rax,1),%edx
   0x000000080159a734: 39 ca cmp %ecx,%edx
   0x000000080159a736: 0f 4e ca cmovle %edx,%ecx
   0x000000080159a739: 39 c1 cmp %eax,%ecx
End of assembler dump.
(gdb) q

# gdb7121 work/stellarium-0.15.1/src/stellarium
...
(gdb) disas /r 0x000000080159a72b-16,0x000000080159a72b+16
Dump of assembler code from 0x80159a71b to 0x80159a73b:
   0x000000080159a71b: Cannot access memory at address 0x80159a71b

i.e. without the core file the space is not known

'ltrace' dumps core itself:

# ltrace -C work/stellarium-0.15.1/src/stellarium 2>&1 | tee /tmp/l
# cat /tmp/l
qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)(1, 0x10129e0, 0x1012a40, 0x1012b40, 1) = 1
__cxa_atexit(0xc97040, 0x149cf48, 0x1408628, 0x80b61f040, 1) = 0
short() = <void>
QString::fromAscii_helper(char const*, int)(0xed5c0d, 3, 0x8080808080808080, 3, 0xfefefefefefefeff) = 0x80b61f0c0
__cxa_atexit(0x4d3780, 0x149cf30, 0x1408628, 3, 1) = 0
short() = <void>
QString::fromAscii_helper(char const*, int)(0x100b942, 64, 0x8080808080808080, 64, 0xfefefefefefefeff) = 0x80b63a0a0
QString::split(QChar, QString::SplitBehavior, Qt::CaseSensitivity) const(0x149cf38, 0x7fffffffda58, 32, 1, 1) = 0x149cf38
QArrayData::deallocate(QArrayData*, unsigned long, unsigned long)(0x80b63a0a0, 2, 8, 0x80b63a000, -744) = 0x91ff1c6c956ec979
__cxa_atexit(0x4de9b0, 0x149cf38, 0x1408628, 0, -792) = 0
short() = <void>
QString::fromAscii_helper(char const*, int)(0xed5c0d, 3, 0x8080808080808080, 3, 0xfefefefefefefeff) = 0x80b61f0e0
__cxa_atexit(0x4d3780, 0x149cf20, 0x1408628, 3, 1) = 0
short() = <void>
QString::fromAscii_helper(char const*, int)(0x100b942, 64, 0x8080808080808080, 64, 0xfefefefefefefeff) = 0x80b63a0a0
QString::split(QChar, QString::SplitBehavior, Qt::CaseSensitivity) const(0x149cf28, 0x7fffffffda58, 32, 1, 1) = 0x149cf28
QArrayData::deallocate(QArrayData*, unsigned long, unsigned long)(0x80b63a0a0, 2, 8, 0x80b63a000, -736) = 0x91ff1c6c956ec979
__cxa_atexit(0x4de9b0, 0x149cf28, 0x1408628, 0, -792) = 0
short() = <void>
QString::fromAscii_helper(char const*, int)(0xed5c0d, 3, 0x8080808080808080, 3, 0xfefefefefefefeff) = 0x80b61f100
__cxa_atexit(0x4d3780, 0x...

Revision history for this message
Matthias Apitz (gubu) wrote :

> Apart from memory corruption, it also could be that Stellarium ends up
> executing wrong memory for some reason. Can you mount linprocfs(5) and
> "cat /compat/linux/proc/<stellaium-pid>/maps"?

I will attach the file 'maps' of this script:

# cat launch.sh

work/stellarium-0.15.1/src/stellarium &

while true; do
    cat /compat/linux/proc/$!/maps >> maps
    echo MAPS >> maps
done

which catches the maps during the live of the proc.

Revision history for this message
Matthias Apitz (gubu) wrote :
Revision history for this message
Alexey Dokuchaev (danfe) wrote :

> # gdb7121 work/stellarium-0.15.1/src/stellarium
> ...
> (gdb) disas /r 0x000000080159a72b-16,0x000000080159a72b+16
> Dump of assembler code from 0x80159a71b to 0x80159a73b:
> 0x000000080159a71b: Cannot access memory at address 0x80159a71b
>
> i.e. without the core file the space is not known

OK, that explains why faulty code was not found in programs or libraries on disk. This memory is allocated and populated during execution. But it also means that it should not be executed at all. The map dump shows that 0x000000080159a72b belongs to this region:

> 0000000801563000-00000008015fd000 rw-p 0009c000 00:00 0

And it is indeed not executable. Something fishy is going on, and I have no ideas for the moment, except these two:

1. It seems that you're running programs with Spanish locale (es_ES)? Can you try with LANG=C or LC_ALL=C, just to rule this particular peculiarity out? You might try other languages as well, but make sure the setting does get applied.

2. The crash occurs with both splash screen and main window visible at the same time; and the closest function call to Stellarium itself that I can see in the backtrace is QSplashScreen::finish(). Why don't you try to disable all splash-related code in main.cpp at all, starting from line 166: QPixmap pixmap(StelFileMgr::findFile("data/splash.png")); and up to line 367: splash.finish(&mainWin); and see what happens.

Revision history for this message
Matthias Apitz (gubu) wrote :

I set LANG=C and disabled in the source the splash screen; I removed the
~root/.stellarium dir; the splash is
away, it only shows up s small window in left upper corner, and it says
before crash:

# work/stellarium-0.15.1/src/stellarium -d
...
Loaded plugin "Novae"
Creating directory "/root/.stellarium/modules/Novae"
[Novae] no Novae section exists in main config file - creating with defaults
[Novae] novae.json does not exist - copying default file to "/root/.stellarium/modules/Novae/novae.json"
[Novae] copied default novae.json to "/root/.stellarium/modules/Novae/novae.json"
[Novae] loading catalog file: "/root/.stellarium/modules/Novae/novae.json"
Loaded plugin "Oculars"
Ocular plugin - press Command-O to toggle eyepiece view mode. Press ALT-o for configuration.
Creating directory "/root/.stellarium/modules/Oculars"
Oculars::validateIniFile copied default_ocular.ini to "/root/.stellarium/modules/Oculars/ocular.ini"
Loaded plugin "Satellites"
Creating directory "/root/.stellarium/modules/Satellites"
[Satellites] satellites.json does not exist - copying default file to "/root/.stellarium/modules/Satellites/satellites.json"
[Satellites] copied default satellites.json to "/root/.stellarium/modules/Satellites/satellites.json"
[Satellites] copied default qs.mag to "/root/.stellarium/modules/Satellites/qs.mag"
[Satellites] loading catalog file: "/root/.stellarium/modules/Satellites/satellites.json"
Satellite has invalid orbit: "CADRE" "41475"
Loaded plugin "SolarSystemEditor"
Trying to copy ssystem.ini to "/root/.stellarium/data/ssystem.ini"
MeteorShowersMgr: Loading catalog file: "/root/.stellarium/modules/MeteorShowers/showers.json_new.json"
MeteorShowersMgr: The catalog was updated!
Illegal instruction (`core' generated)

Revision history for this message
Matthias Apitz (gubu) wrote :

I glanced through the src/*/*.cpp and see a lot of calls to qDebug() ...
how can I activate this to get the messages into a file or stderr?
Where is the impementation of this method or is it part of the Qt lib?

Revision history for this message
Alexey Dokuchaev (danfe) wrote :

Some more ideas, from most to least probable:

1. We're dealing with some kind of stack corruption, e.g. because large object (or large number of objects) is allocated on stack, or local buffer gets overrun, destroying return address and we end up trying to resume execution from wrong memory.

2. Can you try to restart X11 server with VESA backend (slow) and see if it changes anything?

3. Faulty memory. You might try replacing RAM sticks (unless they're soldered) or run memtest86+ (e.g. from a live bootable CD as I recall FreeBSD port is broken on amd64).

qDebug() messages appear in the log when Stellarium is launched with -d or --verbose options.

Revision history for this message
Matthias Apitz (gubu) wrote :

void StelMainView::setFullScreen(bool b)
{
        if (b)
        ; // showFullScreen();
        else
        {
                // showNormal();
...

with the above changes, it does not crash anymore, but also does not
show any window; does this ring some bell?

Revision history for this message
Matthias Apitz (gubu) wrote :

El día miércoles, marzo 15, 2017 a las 01:28:02p. m. -0000, Alexey Dokuchaev escribió:

> Some more ideas, from most to least probable:
>
> 1. We're dealing with some kind of stack corruption, e.g. because large
> object (or large number of objects) is allocated on stack, or local
> buffer gets overrun, destroying return address and we end up trying to
> resume execution from wrong memory.
>
> 2. Can you try to restart X11 server with VESA backend (slow) and see if
> it changes anything?

The Acer C720 run all in VESA mode because the Haswell is not yet supported in FreeBSD.

> 3. Faulty memory. You might try replacing RAM sticks (unless they're
> soldered) or run memtest86+ (e.g. from a live bootable CD as I recall
> FreeBSD port is broken on amd64).

I know three C720, all with the same crash in stellarium; this deletes
this option number 3, I think;

Revision history for this message
Matthias Apitz (gubu) wrote :

I have installed the same (binaries) of the software, same kernel
r314251 and same set of pre-compiled packages (based on port as of March
4, 2017) in an amd64 VM. The Xorg server was tested as 'vesa' and as 'vmware'.
In both stellarium starts fine.

Revision history for this message
Matthias Apitz (gubu) wrote :

I ssh'ed from another laptop (runs r302904 from July last year and
packages from ports August) to the C720 in question with '-Y' to tunnel
back the DISPLAY. The started stellarium on the C720 crashes at the
same point, i.e. the problem does not depend on the used Xorg server.

Revision history for this message
Matthias Apitz (gubu) wrote :

I have just made the following comment in the issue we have open as well in FreeBSD bugs tracker https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211758

1)
I own a bunch of laptops Dell E6330 and netbooks Acer C720, they all run the same binary software (kernel and ports compiled on my poudriere oven, a Dell PowerEdge R210), all 12-CURRENT r314251 and packages compiled from ports r435425 (March 4, 2017). On the Dell 6330 the stellarium 0.15.1 runs fine, while the same binary crashes on all Acer C720, always at the same place (when bringing up the GUI after splash screen).

2)
The same binary system+ports is installed at work in Vbox on a Win7 host, using the same Xorg + vboxvideo driver. As well here stellarium works fine.

3)
This let me think, that the issue is related to the video stack in the C720 (Xorg with vesa driver); the Dell 6330 uses same Xorg with intel driver;

4)
With the recent update of all my systems to r314251+r435425 another application with heavy GUI, the ports/games//flightgear, shows now the same problem: works fine on Dell 6330, crashes on Acer C720 when bringing up the GUI after splash;

Revision history for this message
Matthias Apitz (gubu) wrote :

I've updated one of the Acer C720 to the most recent graphic work kernel
for FreeBSD from https://github.com/freebsd/freebsd-base-graphics
which does allow to use the video-intel driver for Xorg. stellarium
still crashed with the same symptoms while getting the GUI up, until I
realized that the user must be in the group 'video' to have access to
the files below /dev/dri:

crw-rw---- 1 root video 0x6c 9 Apr. 12:57 card0
crw-rw---- 1 root video 0x6b 9 Apr. 12:57 controlD64

Adding the user to the group 'video' makes it finally work fine (also
flightgear works too).

On the other C720 system I still have to use the vesa driver for Xorg and
there are no files or dir /dev/dri. This would explain why stellarium
crashes there, but would not explain how it worked this way in the past.

 matthias

Revision history for this message
gzotti (georg-zotti) wrote :

@Matthias: Can we close this bug here? You have found a solution in system configuration. Does current Stellarium 0.16.1 work?

Changed in stellarium:
status: Confirmed → Incomplete
gzotti (georg-zotti)
Changed in stellarium:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.