Description of problem: qgis segfaults at startup. Version-Release number of selected component (if applicable): rawhide version. How reproducible: always. Additional info: http://blog.qgis.org/node/116 is out.
Do you have an execution from strace? Architecture? Version?
that box is now shut down, but both machines where it happens are i386 or better (Dell desktop and Lenovo T43). will provide versions and strace later once running them again.
Created attachment 304511 [details] strace output leading to crash fcntl64(16, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xbfe0d844) = 0 fcntl64(16, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xbfe0d844) = 0 fcntl64(16, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xbfe0d844) = 0 access("/usr/share/qgis/resources/srs.db-journal", F_OK) = -1 ENOENT (No such file or directory) fstat64(16, {st_mode=S_IFREG|0644, st_size=3468288, ...}) = 0
qgis-0.9.1-5.fc9.i386 Linux Dell-desktop 2.6.25-8.fc9.i686 #1 SMP Wed Apr 23 03:56:19 EDT 2008 i686 i686 i386 GNU/Linux
/usr/share/qgis/resources/context_help/995980174_sk_SK /usr/share/qgis/resources/qgis.db /usr/share/qgis/resources/qgis_help.db /usr/share/qgis/resources/srs.db /usr/share/qgis/svg
the same listing in f8 doesn't have it either: /usr/share/qgis/resources/context_help/995980174_sk_SK /usr/share/qgis/resources/qgis.db /usr/share/qgis/resources/qgis_help.db /usr/share/qgis/resources/srs.db /usr/share/qgis/svg but that qgis-0.9.1-3.fc8 version works.
Comment on attachment 304511 [details] strace output leading to crash bzip2 attached strace
well, that journal file sqlite journal but it's not needed as it only reads the file in RO mode. I'll provide bt tomorrow.
qgis-0.9.1-6.fc9 has been submitted as an update for Fedora 9
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
qgis-0.9.1-6.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update qgis'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3892
Created attachment 305681 [details] strace record of qgis execution
To the previous post: QGIS still segfaults while startup, even in the version qgis-0.9.1-6.fc9. From the gdb: (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x056ac8db in sincos () from /usr/lib/libgdal.so.1 (gdb)
Same here, on x86_64.
how about upgrading to the 0.10 as it's out already?
Unfortunately, I didn't have more luck with 0.10.0. Doug, I've got an updated spec file and some updated patches if you're interested though. I can check them into CVS if you wish.
(In reply to comment #16) > Doug, I've got an updated spec file and some updated patches if you're > interested though. I can check them into CVS if you wish. Can you email them to me? I have been trying to get 0.10.0 built but am having problems w/ the python modules including rpath. If you have that fixed I should be able to push out new packages soon.
It seems to me that it might be a gdal problem (see comment #13). I built my own gdal (older version -- 1.4.4) and the qgis 0.10.0 (from the official source code) and it seems to work flawlessly.
That makes sense since I've been getting broken deps reports the past couple days; I tried rebuilding against the current gdal but it didn't seem to work (the 0.9.1-6 that's in testing). qgis has broken dependencies in the development tree: On ppc: qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 On x86_64: qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) On i386: qgis-0.9.1-5.fc9.i386 requires libgeos.so.2
qgis functionalty fixed in F-9 upstream -testing branch. Please look after gdal-1.5.1-7. gdal-1.5.1-7 %changelog * Thu May 15 2008 Balint Cristian <rezso> - 1.5.1-7 - fix x86_64 problem --- frmts/hdf4/hdf-eos/GDapi.c.orig 2008-05-20 15:01:09.000000000 +0300 +++ frmts/hdf4/hdf-eos/GDapi.c 2008-05-20 15:02:07.000000000 +0300 @@ -6258,7 +6258,7 @@ -#if !defined(HP9000) && !defined(DEC_ALPHA) +#if !defined(HP9000) && !defined(DEC_ALPHA) && !defined(__x86_64__) void sincos(double val, double *sin_val, double *cos_val) {
I will push this to updates-stable ASAP today.
(In reply to comment #17) > Can you email them to me? I have been trying to get 0.10.0 built but am > having problems w/ the python modules including rpath. If you have that fixed > I should be able to push out new packages soon. Mail is sent -- I don't recall having problems with the python modules, though.
(In reply to comment #22) > Mail is sent -- I don't recall having problems with the python modules, though. > Received; could you run rpmlint on your packages and see if you get rpath warnings for the python modules? For the GCC 4.3 patches, I was planning on just dropping them completely as it seems they were all incorporated upstream.
gdal-1.5.1-7.fc9 has been submitted as an update for Fedora 9
I dont get hardcoded r-path over 1.5.1 series. I always check r-path. BTW, i am using python/perl highly intensive I have zerro problem using tham. If you have problems please fill a bugreport or something to clarify those issues. gdal-1.5.1-7.fc9 is pending for updates, till than unpacient folk can grab it from koji. ~cristian
(In reply to comment #25) > I dont get hardcoded r-path over 1.5.1 series. > I always check r-path. BTW, i am using python/perl > highly intensive I have zerro problem using tham. > > If you have problems please fill a bugreport or > something to clarify those issues. No; this is in the new qgis 0.10.0, not gdal. > gdal-1.5.1-7.fc9 is pending for updates, till than > unpacient folk can grab it from koji. Great; can you ask rel-eng to tag the gdal update as an override so I can build a new qgis against it?
Usually i wait till bodhi automagicaly tag it. If you want please let me know how/where to mail for quick up the tagging ? BTW, on other hand: Can please take care of these lower ? 2 of tham are pretty annoying, let me know if I can help out in any way, i am sure you can easily treat tham as well. rpmlint qgis qgis.x86_64: E: non-executable-script /usr/share/qgis/python/plugins/plugin_installer/qgis_plugins.py 0644 qgis.x86_64: E: invalid-soname /usr/lib64/libqgis_core.so libqgis_core.so qgis.x86_64: E: invalid-soname /usr/lib64/libqgis_gui.so libqgis_gui.so qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libQtSvg.so.4 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libQtNetwork.so.4 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libQt3Support.so.4 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libproj.so.0 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libgeos.so.2 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /usr/lib64/libgdal.so.1 qgis.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libqgis_gui.so /lib64/libm.so.6 qgis.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/qgis/core.so qgis.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/python2.5/site-packages/qgis/core.so ['/usr/src/redhat/BUILD/qgis-0.9.1/src/core/.', '/usr/lib64'] qgis.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/qgis/gui.so qgis.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/python2.5/site-packages/qgis/gui.so ['/usr/src/redhat/BUILD/qgis-0.9.1/src/core/.', '/usr/lib64', '/usr/src/redhat/BUILD/qgis-0.9.1/src/gui/.']
Looking at the error again, if this segfault is not related to the dependency problem emails I've been getting about geos, then you should be able to test out the fix by updating the gdal in updates-testing. If that fixes it, I probably don't need to rebuild qgis right now (just need to figure out how to fix the geos dependency problems). (In reply to comment #27) > qgis.x86_64: E: binary-or-shlib-defines-rpath > /usr/lib64/python2.5/site-packages/qgis/core.so > ['/usr/src/redhat/BUILD/qgis-0.9.1/src/core/.', '/usr/lib64'] > qgis.x86_64: W: unstripped-binary-or-object > /usr/lib64/python2.5/site-packages/qgis/gui.so > qgis.x86_64: E: binary-or-shlib-defines-rpath > /usr/lib64/python2.5/site-packages/qgis/gui.so > ['/usr/src/redhat/BUILD/qgis-0.9.1/src/core/.', '/usr/lib64', > '/usr/src/redhat/BUILD/qgis-0.9.1/src/gui/.'] Right; these are the python rpath problems I was talking about that I also noticed in 0.10.0. I'm already disabling rpath in the cmake line, so I'm not sure what's going on that the pyton modules are being built with it.
gdal-1.5.1-7.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
$ qgis qgis: error while loading shared libraries: libgrass_vect.so.6.3: cannot open shared object file: No such file or directory # ldconfig -v $ qgis Segmentation fault $ rpm -q qgis gdal qgis-0.9.1-6.fc9.i386 gdal-1.5.1-7.fc9.i386 Starting program: /usr/bin/qgis [Thread debugging using libthread_db enabled] warning: "/usr/lib/debug/usr/lib/atlas/liblapack.so.3.0.debug": The separate debug info file has no debug info warning: "/usr/lib/debug/usr/lib/atlas/libblas.so.3.0.debug": The separate debug info file has no debug info [New Thread 0xb801e730 (LWP 3353)] Program received signal SIGSEGV, Segmentation fault. 0x00e7b6ab in sincos (val=0, sin_val=0xbed56028, cos_val=0xbed56020) at GDapi.c:6265 6265 *sin_val = sin(val); (gdb)
The same applies to me. The SIGSEGV again, same as in comment #13.
OMG ! so it crash for i386 too ? Please confirm this, and i fix than gdal ASAP.
yup, my f9 box is i686 something. can cat cpuinfo later if needed.
Juha, Please test this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=626873 Just grab *.i386 builds from koji page and give a shot. Confirm please if its working, than i push tham tu updates.
gdal-1.5.1-8.fc9 has been submitted as an update for Fedora 9
Hey, now it works :) Thank you very much! You can close this bug now.
Bodhi will take care of closing the bug (unless that checkbox was explicitly unchecked when submitting the update).
It was checked. Lets wait, it will do its job.