Bug 498111
Summary: | qt-programs linked against libgrass_gprof (like gdal) crash when qgtkstyle is active | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sven Lankes <sven> | ||||||||||
Component: | gdal | Assignee: | Balint Cristian <cristian.balint> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | low | ||||||||||||
Version: | 13 | CC: | ahz001, alex, anton, ayurtsev, barmstro, bengt.sjogren, boris.leidner, cedric.olivier, christof, christy.m.n, cje, cristian.balint, dan, dylan.semler, fedora.bugreports, fedora, flemming, jan.kratochvil, k_a_r_l_o_, kb2jaq, kevin, leifer, micha, nicolas.gif, nrojb23, paulius.zaleckas, pertusus, rdieter, redhat-bugzilla, redhat_bugzilla, silfreed, stephan, than, twaugh, uksi, vpvainio, wdaguirrer, wg | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | qt-4.6.3-8.fc12 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2010-07-13 07:39:36 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | 498229 | ||||||||||||
Bug Blocks: | 497741, 497851 | ||||||||||||
Attachments: |
|
FYI, the real-world program which has this problem is merkaartor. i cannot reproduce this problem with F11-preview! could you please attach the backtrace of the crash? thanks Created attachment 341743 [details]
Requested stracktrace
mailed gdal maintainers. One guess of mine is that gdal has may have namespace issues (overriding or hijacking symbols used by qgtkstyle) Here's what may or may not be some useful playing and debugging: used gtk-qt-engine to set gtk style, and now I can't reproduce crash but removing the ~/.gtkrc-2.0-kde4 file created makes crash re-appear but killing xsettings-kde makes crash go away too creepy Bouncing to gdal, for advice, feedback. For example, I rebuilt gdal without grass support, and can no longer reproduce any crashes. Narrowed down test case to linking -lQtGui -lgrass_gproj Volley to grass, for advice, feedback wrt crazy crashes For fun, rebuilt gdal, hacking out it's linking to libgrass_gproj, and qt app crashes went away too. Not sure if that's a viable option or not (don't see any undefined symbols in the resulting libgdal), but thought I'd mention it in case it is. Created attachment 341828 [details]
hack to avoid libgdal linking to libgrass_gproj
Does our GRASS have this changeset yet? http://trac.osgeo.org/grass/changeset/36484 The bug in libgrass_gproj this fixes may be the source of the memory corruption. That said, I doubt that's it as this memory abuse shouldn't get called by merely linking the library, there are no magic constructor sections or anything like that in libgrass_gproj. Have you tried the dependencies of libgrass_gproj yet? In particular, libproj.so.0 from the proj package? libproj has quite a few exported symbols with generic names: http://trac.osgeo.org/proj/browser/trunk/proj/src/projects.h * It overrides math functions like arc trig functions and hypot with its own versions. * It has functions named vector1, vector2 and freev2. This could be the problem, but it might also be a complete red herring. It seems to be the cross-linked libgdal <--> libgrass_gproj When I fixed gdal as above (comment #9 and comment #10), the libgrass_gproj-linked test case stopped crashing too. That's really bizarre. The fact that they link against each other shouldn't break anything. (In reply to comment #4) > mailed gdal maintainers. By the way, last time I checked the current maintainer, Cristian Balint, his FAS account was disabled a while back. It may have since been re-enabled, but I haven't had a chance to check. Meanwhile all ACLs for provenpackager have been lifted so co-maintainers can step up. Cristian is/was the grass maintainer as well. Fun, well, we have a hackish workaround in comment #10, any objections to whipping up some test builds? Seems Cristian's account has since been re-enabled: https://admin.fedoraproject.org/accounts/user/view/rezso (you need to login to FAS to view the above page) Double lovely, gdal now FTBFS , http://koji.fedoraproject.org/koji/taskinfo?taskID=1331178 (in swig/ruby bindings). Previously in testing, I only ever built libgdal by hand. The errors: > gdal_wrap.cpp: In function 'VALUE _wrap_GCP_Info_set(int, VALUE*, VALUE)': > gdal_wrap.cpp:6057: error: could not convert 'GDAL_GCP_Info_set(arg1, ((const char*)arg2))' to 'bool' > gdal_wrap.cpp:6057: error: type 'void' argument given to 'delete', expected pointer > gdal_wrap.cpp:6060: error: invalid use of 'void' > gdal_wrap.cpp:6062: error: invalid use of 'void' > gdal_wrap.cpp: In function 'VALUE _wrap_GCP_Id_set(int, VALUE*, VALUE)': > gdal_wrap.cpp:6157: error: could not convert 'GDAL_GCP_Id_set(arg1, ((const char*)arg2))' to 'bool' > gdal_wrap.cpp:6157: error: type 'void' argument given to 'delete', expected pointer > gdal_wrap.cpp:6160: error: invalid use of 'void' > gdal_wrap.cpp:6162: error: invalid use of 'void' Looks like the .i files need fixing. > Previously in testing, I only ever built libgdal by hand. Without RPM_OPT_FLAGS? This pretty much invalidates all your tests, as merely rebuilding GDAL with different flags may have "fixed" it. With RPM_OPT_FLAGS, and the builds initiated from an rpmbuild. Give me a *little* credit? :) Hello, I have a segmentation fault too with merkaartor. (merkaartor-0.13.1-1.fc10.1.i386) in dmesg : merkaartor[4233]: segfault at 5c ip 034bc8b4 sp bf994680 error 4 in libQtGui.so.4.5.0[32f5000+9b8000] merkaartor[4266]: segfault at 5c ip 034bc8b4 sp bf8b6b10 error 4 in libQtGui.so.4.5.0[32f5000+9b8000] merkaartor[4401]: segfault at 5c ip 034bc8b4 sp bfd4afa0 error 4 in libQtGui.so.4.5.0[32f5000+9b8000] Is it the same bug ? What can I do ? (In reply to comment #23) > Hello, I have a segmentation fault too with merkaartor. > (merkaartor-0.13.1-1.fc10.1.i386) > in dmesg : > merkaartor[4233]: segfault at 5c ip 034bc8b4 sp bf994680 error 4 in > libQtGui.so.4.5.0[32f5000+9b8000] > merkaartor[4266]: segfault at 5c ip 034bc8b4 sp bf8b6b10 error 4 in > libQtGui.so.4.5.0[32f5000+9b8000] > merkaartor[4401]: segfault at 5c ip 034bc8b4 sp bfd4afa0 error 4 in > libQtGui.so.4.5.0[32f5000+9b8000] > Is it the same bug ? > What can I do ? This looks like the same bug, yes. I have created an update that includes a workaround. Said update is still waiting for the next update push. You can install it from http://koji.fedoraproject.org/koji/buildinfo?buildID=100112 in the meantime. (In reply to comment #24) > (In reply to comment #23) > > > Hello, I have a segmentation fault too with merkaartor. > > (merkaartor-0.13.1-1.fc10.1.i386) > > in dmesg : > > merkaartor[4233]: segfault at 5c ip 034bc8b4 sp bf994680 error 4 in > > libQtGui.so.4.5.0[32f5000+9b8000] > > merkaartor[4266]: segfault at 5c ip 034bc8b4 sp bf8b6b10 error 4 in > > libQtGui.so.4.5.0[32f5000+9b8000] > > merkaartor[4401]: segfault at 5c ip 034bc8b4 sp bfd4afa0 error 4 in > > libQtGui.so.4.5.0[32f5000+9b8000] > > Is it the same bug ? > > What can I do ? > > This looks like the same bug, yes. I have created an update that includes a > workaround. Said update is still waiting for the next update push. You can > install it from http://koji.fedoraproject.org/koji/buildinfo?buildID=100112 in > the meantime. Thanks a lot, That's solve my problem. So it was the same bug... This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I've had QGIS segfault'ing since qt-4.5.0-14 was released (see bug #497851) on Fedora 9 and 10, and this continues on Fedora 11. I have tried rebuilding gdal 1.5.3 on Fedora 9 and 1.6.0 on Fedora 10 with the suggestion in comment 10, hoping that it would solve the problem, but the build fails with "undefined reference to `GPJ_grass_to_wkt'" Just wanted to note that this was not the problem with QGIS, bug #497851 has the fix that worked for me with Fedora 9, 10 and 11. This *is* the same problem, afaict, you just worked around it by changing styles. gdal 1.6.1 is built in rawhide, yet in bootstrap mode And after reading its "configure.in" I've found that it support symbols visibility (disabled by default). IMO it's worth trying in next builds. *** Bug 497851 has been marked as a duplicate of this bug. *** I can no longer reproduce this error an rawhide. Might have been fixed with the updated gdal. (In reply to comment #32) > I can no longer reproduce this error an rawhide. Might have been fixed with the > updated gdal. It is because gdal from rawhide is built without grass support. Enabling symbol visibility feature in gdal doesn't help. I have a fresh install of Fedora 11 x86-64 with latest updates. QGIS does not work. Workarounds mentioned in Comment #28 does not improve the situation. Here comes the printout of terminal window: [me@pc ~]$ qgis Segmentation fault [me@pce ~]$ su root Password: [root@pc me]# qgis Warning: Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed Segmentation fault [root@pc me]# I can confirm I get the same problem on F-11, although I can workaround this by changing the theme to "Cleanlooks" using qtconfig-qt4. If I select them "GTK+", or use the default then I get a seg fault. I reinstall Fedora 11 but 32-bit version. No luck. The last messages in the QGIS flash-screen is about python plug-ins. Just for fun I uninstalled python integration and plugins for QGIS. Ooops! Now the QGIS work with "Cleanlooks" as the theme for Qt4. Reinstalling python integration and plugins for QGIS causes "Segmentation fault" again. It looks like there is something terribly wrong with python support for QGIS as well (Bug 518121). Reinstall Fedora 11 64-bit version. Works as described in Comment #35 if "Python integration and plugins for qgis" is not used. *** Bug 570768 has been marked as a duplicate of this bug. *** - Works as of: gdal-1.7.1-1.fc14.x86_64 or gdal-1.6.2-5.fc13.x86_64 qt-devel-4.6.2-7.fc13.x86_64 I'll check grass now. Trying now update to gdal-1.6.2-6 and see. This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I'm seeing this again (maybe related t the last couple of updates to gdal that enable grass support again?). I'm receiving bugreports for merkaartor running under gnome again (bz #589496). Linking the above helloworld.cpp against gdal and running it under gnome results in a segfault. Same situation with qlandkartegt, but what's interesting is the fact that it crashes in F-11 and F-13, F-12 is fine, haven't tried rawhide yet. And the workaround with overriding the style doesn't help. There is a fresh backtrace in bug 589496 *** Bug 589496 has been marked as a duplicate of this bug. *** qlandkartegt-0.18.1-1.fc14.x86_64 (even without the workaround) gdal-1.7.1-2.fc14.x86_64 ^^^ this combination runs fine in rawhide (In reply to comment #46) > qlandkartegt-0.18.1-1.fc14.x86_64 (even without the workaround) > gdal-1.7.1-2.fc14.x86_64 > ^^^ this combination runs fine in rawhide Looking at the changelog it seems that this gdal-version is currently built without grass-support. Not sure if that is for bootstrapping purposes or if it's going to stay that way. Ah, that explains it, gdal in both F-12 and rawhide are built without grass ... The reason why the apps are crashing again (e.g. in F-11) is the update from qt 4.5 to 4.6. The qt 4.6 code added an explicit call to the gtk style engine when run under GNOME, see gui/kernel/qapplication_x11.cpp, around line 2307 ... if (X11->desktopEnvironment == DE_KDE) X11->desktopVersion = QString::fromLocal8Bit(qgetenv("KDE_SESSION_VERSION")).toInt(); #if !defined(QT_NO_STYLE_GTK) if (X11->desktopEnvironment == DE_GNOME) { static bool menusHaveIcons = QGtkStyle::getGConfBool(QLatin1String("/desktop/gnome/interface/menus_have_icons"), true); QApplication::setAttribute(Qt::AA_DontShowIconsInMenus, !menusHaveIcons); } #endif ... This code doesn't exist in qt 4.5 and in my opinion it's the reason why the workaround doesn't work. *** Bug 588088 has been marked as a duplicate of this bug. *** *** Bug 585998 has been marked as a duplicate of this bug. *** BTW, that workaround needs to go away ASAP, as it makes those apps look ugly in KDE (it always uses the Cleanlooks style no matter what). If it doesn't work anyway, that's all the more reason to remove it. Created attachment 413811 [details]
script to build the reproducer and prepare some logs
I was also able to kill the over-linking (unused-direct-shlib-dependency) in gdal and grass libraries with using "-Wl,--as-needed", but it made no change in this issue.
(In reply to comment #52) > BTW, that workaround needs to go away ASAP, as it makes those apps look ugly in > KDE (it always uses the Cleanlooks style no matter what). If it doesn't work > anyway, that's all the more reason to remove it. Well, better to look ugly than to crash. But it's true that now (with qt 4.6) it doesn't make sense to keep the workaround. I've started to look at this issue more seriously and as a first step I've built minimalized (read as almost all features disabled) gdal and grass libraries. The test case binary now opens only 52 libraries instead of 99 when built against Fedora packages. But it still crashes ... This: nm -D `ldd /usr/bin/qlandkartegt | sed -e 's/^.* => //g' -e 's/ (.*$//g'` | \ grep '^[0-9a-f ]' | sed -e 's/^........ //g' | grep '^T' | sort | uniq -c | \ grep -v '^ 1 ' should give you a list of suspicious symbols (defined in more than one shared library). It's likely that one of those symbols is causing the symbol conflict. Though actually, I guess you need to ldd also the libraries which are being dlopened, e.g. /usr/lib/libgtk-x11-2.0.so The list of libraries can be obtained when running with LD_DEBUG=all, the outputs are stored at http://fedora.danny.cz/tmp Unfortunately the output from the command above (on my minimalized test-case) is empty, even when run with the library list returned by ld. My recent idea is that the wrong order of library constructors makes the app crash. Asked by dhorak to post some notes. Reproduced by Comment 53 on F-13 x86_64 current-latest. The crash happens for ./a at: #0 x11EventSourcePrepare (s=<value optimized out>, timeout=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:79 79 && !source->d->queuedUserInputEvents.isEmpty())); (gdb) l 74 if (timeout) 75 *timeout = -1; 76 GX11EventSource *source = reinterpret_cast<GX11EventSource *>(s); 77 return (XEventsQueued(X11->display, QueuedAfterFlush) 78 || (!(source->flags & QEventLoop::ExcludeUserInputEvents) 79 && !source->d->queuedUserInputEvents.isEmpty())); 80 } That `GX11EventSource *source' has been allocated by: 171 QGuiEventDispatcherGlibPrivate::QGuiEventDispatcherGlibPrivate() 172 { 173 x11EventSource = reinterpret_cast<GX11EventSource *>(g_source_new(&x11EventSourceFuncs, 174 sizeof(GX11EventSource))); 175 g_source_set_can_recurse(&x11EventSource->source, true); 176 177 memset(&x11EventSource->pollfd, 0, sizeof(GPollFD)); 178 x11EventSource->flags = QEventLoop::AllEvents; 179 x11EventSource->q = 0; 180 x11EventSource->d = 0; 181 182 g_source_attach(&x11EventSource->source, mainContext); 183 } But there is ->d initialized to 0. Therefore the ->d dereference apparently crashes. The non-crashing ./a1 gets that ->d initialized by: #0 QGuiEventDispatcherGlib::startingUp (this=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:217 #1 0x00007ffff736594e in QApplicationPrivate::construct (this=0x602f90, dpy=0x0, visual=0, cmap=0) at kernel/qapplication.cpp:773 #2 0x00007ffff73661b1 in QApplication::QApplication (this=0x7fffffffd240, argc=@0x7fffffffd20c, argv= 0x7fffffffd358, _internal=263682) at kernel/qapplication.cpp:693 #3 0x00000000004009d2 in main (argc=1, argv=0x7fffffffd358) at a.cpp:6 The crash for ./a happens during a call from kernel/qapplication.cpp:771. In the non-crashing ./a1 the initialization happens during a call from: kernel/qapplication.cpp:773. Therefore there is a fragile state of GX11EventSource in between which gets exploited by some callbacks which get installed by static constructors of -lgrass_gproj or probably from one of the many libraries indirectly linked in through libgrass_gproj.so dependencies. x11EventSourcePrepare should be fortified against NULL d. Whether it should ignore NULL d or assertion-fail on NULL d I do not know, the whole problems needs more analysis whether the current codebase should handle such case or whether the newly installed hook/callback by the -lgrass_gproj indirect libraries is incorrect (in such case there should be an assertion check to forbid installation of new hooks/callbacks so early). I guess we can add a NULL check there to stop this crash from happening. *** Bug 598996 has been marked as a duplicate of this bug. *** *** Bug 599251 has been marked as a duplicate of this bug. *** *** Bug 601629 has been marked as a duplicate of this bug. *** *** Bug 594859 has been marked as a duplicate of this bug. *** *** Bug 602711 has been marked as a duplicate of this bug. *** *** Bug 603443 has been marked as a duplicate of this bug. *** *** Bug 605942 has been marked as a duplicate of this bug. *** Package: merkaartor-0.15.3-1.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. Launch Merkaartor as user 2. 3. Comment ----- Seg fault at launch. Happens since I updated from F12 to F13. The app doesn't crash when I launch it as root. I submitted bug 605942, which has been marked as a duplicate. My crash is with qlandkartegt-0.18.1-1.fc13.x86_64. I read through all of the above, but don't understand much. So, is there a way to run qlandkartegt under F13 without crash? Frank (In reply to comment #69) > So, is there a way to run qlandkartegt under F13 without crash? Currently the only known workaround is to run it from a kde session. *** Bug 606181 has been marked as a duplicate of this bug. *** *** Bug 607329 has been marked as a duplicate of this bug. *** For people like me who want to run merkaartor on F-13. I managed to get it running by either rebuilding the F-13 RPM with a change to the spec file to disable GDAL --- F-13/merkaartor.spec 14 Jun 2010 22:42:09 -0000 1.26 +++ F-13/merkaartor.spec 24 Jun 2010 11:44:47 -0000 @@ -28,7 +28,7 @@ %build rm -rf includes/boost lrelease-qt4 src/src.pro -qmake-qt4 Merkaartor.pro PREFIX=%{_prefix} LIBDIR=%{_libdir} RELEASE=1 VERSION=0.16 REVISION=.1 NODEBUG=1 GEOIMAGE=1 GPSD=1 GDAL=1 +qmake-qt4 Merkaartor.pro PREFIX=%{_prefix} LIBDIR=%{_libdir} RELEASE=1 VERSION=0.16 REVISION=.1 NODEBUG=1 GEOIMAGE=1 GPSD=1 GDAL=0 make %{?_smp_mflags} or building the version from the git repository: git clone http://git.gitorious.org/merkaartor/main.git merkaartor cd merkaartor qmake-qt4 NODEBUG=1 GEOIMAGE=1 GPSD=1 GDAL=0 make ./binaries/bin/merkaartor *** Bug 607935 has been marked as a duplicate of this bug. *** For giggles, can anyone seeing this try if this helps? QT_NO_GLIB=1 merkaartor (In reply to comment #75) > For giggles, can anyone seeing this try if this helps? > > QT_NO_GLIB=1 merkaartor works for me with merkaartor-0.16.1-1.fc13.x86_64 cheers (In reply to comment #76) > (In reply to comment #75) > > For giggles, can anyone seeing this try if this helps? > > > > QT_NO_GLIB=1 merkaartor > > works for me with merkaartor-0.16.1-1.fc13.x86_64 > > cheers Works for me too when setting QT_NO_GLIB=1. Works for me: [stephan@kulta Europe]$ qlandkartegt ------------ 4506687.439892 5432922.567629 ------------ +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs +towgs84=606.0,23.0,413.0 Erreur de segmentation (core dumped) [stephan@kulta Europe]$ QT_NO_GLIB=1 qlandkartegt ------------ 4506687.439892 5432922.567629 ------------ +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs +towgs84=606.0,23.0,413.0 ------------ 4506687.439892 5432922.567629 ------------ +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs +towgs84=606.0,23.0,413.0 ... Thanks Works for qgis too. Woot! $ QT_NO_GLIB=1 qgis OK, thanks for the confirmations. I think we've got a lead here on how to apply a workaround in qt (at least until the source of problematic glib event loop callbacks are found). Test qt builds that include a workaround: F-14/rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=180455 F-13: https://koji.fedoraproject.org/koji/buildinfo?buildID=180430 F-12: https://koji.fedoraproject.org/koji/buildinfo?buildID=180464 (In reply to comment #81) > Test qt builds that include a workaround: > F-14/rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=180455 I have tried this build and it fixes the issue for me. (In reply to comment #81) > Test qt builds that include a workaround: > F-13: http://koji.fedoraproject.org/koji/buildinfo?buildID=180430 These packages seems to have resolved my issue preventing qgis from loading as well. And qlandkartegt works too with the patched qt. *** Bug 610835 has been marked as a duplicate of this bug. *** *** Bug 610973 has been marked as a duplicate of this bug. *** *** Bug 611071 has been marked as a duplicate of this bug. *** *** Bug 611095 has been marked as a duplicate of this bug. *** *** Bug 611431 has been marked as a duplicate of this bug. *** *** Bug 611670 has been marked as a duplicate of this bug. *** *** Bug 606095 has been marked as a duplicate of this bug. *** *** Bug 604314 has been marked as a duplicate of this bug. *** *** Bug 613377 has been marked as a duplicate of this bug. *** qt-4.6.3-8.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/qt-4.6.3-8.fc13 qt-4.6.3-8.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/qt-4.6.3-8.fc12 qt-4.6.3-8.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. qt-4.6.3-8.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 614042 has been marked as a duplicate of this bug. *** *** Bug 622164 has been marked as a duplicate of this bug. *** |
Created attachment 341656 [details] example-code to trigger segfault Description of problem: A binary that links against qt and gdal segfaults immediately when using qgtkstyle. Version-Release number of selected component (if applicable): qt 4.5.* on f9 / f10 / f11 gdal 1.6.0 Steps to Reproduce: 1. Compile the attached helloworld.cpp 2. link against gdal 3. run the resulting binary (either from inside gnome or using -style GTK+) Actual results: segfault Expected results: Hello World