Bug 377931

I see this on F7 as well.

Sorry, I should have mentioned: that's F7 x86, so it's not an x86_64 specific issue.

How does it break? Do you have an strace perhaps?

Do you suspect a packaging bug, or do you think this is an upstream issue? In
the latter case it would be better to report it upstream.

(In reply to comment #3)
> How does it break? Do you have an strace perhaps?
> 
> Do you suspect a packaging bug, or do you think this is an upstream issue? 
In
> the latter case it would be better to report it upstream.
> 

In the original report, I said that uic can't run - it segfaults.

Sorry I don't have a trace.  Gdb output was bizarre and useless (claimed the 
fault was in some completely unrelated library).

Exactly the same for me, although in my case the segfault was only visible as a
failure in a configure script: I confirmed the segfault by rerunning the failing
test manually. I triggered it by trying to rebuild KDE PIM from the source RPM.
The configure script suggested that this is a mismatch between Qt versions
and/or the compilers used to build them.

> I triggered it by trying to rebuild KDE PIM from the source RPM.

This looks more like a not-vtk bug to me. Should we move this bug to the qt
component?

Hi,
Just some additional input from a non-expert user (hope it helps to bracket the
source of the problem): in my installation, the vtk-qt package makes Qt designer
crash on launch; however, if I open with KUIViwer, say, GUI.ui from the QT
examples directory, I can see the live Qt widget working! I have no clue about
what is going on here ...
Oscar

*** Bug 413181 has been marked as a duplicate of this bug. ***

I noticed that the bug is tagged for x86_64, but a couple of comments here (mine
included) refer to i386.

Did anyone ever try this on F7 and succeeded? E.g. is it an F8 regression?

It is a regression. Everything works fine under F7 with VTK 5.0.2. 

(In reply to comment #11)
> It is a regression. Everything works fine under F7 with VTK 5.0.2. 

Thanks, this info is very important! Now could you perhaps also do the following
test: Remove the F8 package(s) and use the F7 one(s). If it suddenly works then
the bug is in the F8 build. If it doesn't work then the bug is external to the
vtk build and needs to followed up there.

The following comments indicate the latter case:

> Sorry I don't have a trace.  Gdb output was bizarre and useless (claimed the 
> fault was in some completely unrelated library).
[...]
> I triggered it by trying to rebuild KDE PIM from the source RPM.

So maybe it is a kde/qt regression in F8 becoming visible in the vtk-qt module
(resp. just the designer part for some)?

I installed the qt-vtk packages on two different fc7 computers and i have the same
problem as on fc8. qt-designer and all qt-vtk programs crashes immediately with
a segfault. 

Well, I spoke too fast .... As Holger says, I went back to a F7 clean
installation, added the vtk-qt package and Qt Designer segfaults. Sorry about my
previous misleading email.

Moreover, I compiled vtk from its 5.0.2 source under F7, enabling Qt support and
this version also segfaults. I am looking more into it, as I have been able to
extensively use Qt Designer with the VTK widget in the past.....

  

Update: I have just finished a full re-install of F8 on a clean disk, followed
by a full system update as of today (30/12/07), including kernel (now
2.6.23.9-85) and then added all the vtk packages through yum. Under such
conditions everything works fine, including Qt Designer, which shows the
QVTKWidget in the palette (and it actually works). The only major thing
different from my previous attempts is that this time I have not yet installed
the nvidia drivers for my card. I'll do that next and post the news ... 

(In reply to comment #15)

Installing the nvidia driver brings the segfaults back. I've noticed that the
vtk packages are built with OSMesa support. I am not sure if the nvidia driver
supports off-screen (I'll check into that). BTW, what is the graphics hardware
for the other segfault reports in this bug thread?
 

I can confirm that the designer plugin works with fc8 on a non nvidia system!
But disabling the nvidia driver on fc7 does not helped!

(In reply to comment #17)

So now we have two non-nvidia F8 installations where the Qt plugin works OK! And
to this I add the following: I have compiled vtk from source (version vtk-5.0.2)
on F8, specifically disabling OSMesa support (unlike the vtk rpms we get with
the F8 distro). The plugin works just fine even with the nvidia driver! I'll get
vtk 5.0.3 tonight and retry.... 

(In reply to comment #18)

vtk-5.0.3 with no OSMesa support, compiles perfectly for both Qt3 and Qt4,
generating a working QVTK widget in both cases (Qt3 Designer and Qt4 Designer),
even with the nvidia driver installed (yum from livna.org).

I guess we need to know what happens with other hardware ....

Could someone please post an backtrace of such a segfault? For this to be
readable you need to install all respective *-debuginfo packages including the
ones from the nvidia-graphics libs as it looks like it descending into it and
breaking there.

Also please mention the graphics driver you use (nvidia, ati, something else),
as well as the origin of the driver's install if it is not from Fedora itself
(self-compiled, atrpms, livna, freshrpms etc.)

Finally if someone has a very small test-case for the segfault to be reproduced,
please file it as well, thanks!

Actually, I manage to find that the segfault is triggered by libselinux, and 
is related to dlopen and thread-local static variables. I attach bellow a 
backtrace of Qt-3.3 designer, and i'll try to explain what I manage to 
understand.

lrineau@schtroumpf $ rpm -q vtk-qt qt-designer libselinux
vtk-qt-5.0.3-20.fc8
qt-designer-3.3.8-9.fc8
libselinux-2.0.43-3.fc8

To trigger the bug, just launch 'designer' without any argument:

lrineau@schtroumpf $ designer
zsh: segmentation fault  designer

Here is the backtrace:

#0  0x005c88d4 in fini_context_translations () at setrans_client.c:211
#1  0x005c224e in fini_lib () at init.c:127
#2  0x005baad2 in __do_global_dtors_aux () from /lib/libselinux.so.1
#3  0x005ca15c in _fini () from /lib/libselinux.so.1
#4  0x00bde0c2 in _dl_close_worker (map=0x84a20b0) at dl-close.c:271
#5  0x00bde877 in _dl_close (_map=0x84a20b0) at dl-close.c:729
#6  0x00d70d24 in dlclose_doit () from /lib/libdl.so.2
#7  0x00bd91b6 in _dl_catch_error (objname=0x8473d34, errstring=0x8473d38, 
mallocedp=0x8473d30, operate=0xd70d00 <dlclose_doit>, args=0x84a20b0)
    at dl-error.c:178
#8  0x00d7130c in _dlerror_run () from /lib/libdl.so.2
#9  0x00d70d5a in dlclose () from /lib/libdl.so.2
#10 0x05e6fa6d in QLibraryPrivate::freeLibrary (this=0x84b14d8) at 
tools/qlibrary_unix.cpp:130
#11 0x05e943b0 in QLibrary::unload (this=0x84ae080) at tools/qlibrary.cpp:340
#12 0x05e94e8c in ~QLibrary (this=0x84ae080) at tools/qlibrary.cpp:156
#13 0x05e7447a in ~QComLibrary (this=0x84ae080) at tools/qcomlibrary.cpp:72
#14 0x05e8fbb3 in QGPluginManager::addLibrary (this=0x84a16e8, lib=0x84ae080) 
at tools/qgpluginmanager.cpp:526
#15 0x05e905c0 in QGPluginManager::featureList (this=0x84a16e8) at 
tools/qgpluginmanager.cpp:436
#16 0x08095f2e in MainWindow::setupPluginManagers (this=0x847b9f8) at 
mainwindow.cpp:3117
#17 0x080a73fe in MainWindow (this=0x847b9f8, asClient=false, single=false, 
plgDir=@0xbf912460) at mainwindow.cpp:178
#18 0x08084c91 in main (argc=138874800, argv=Cannot access memory at address 
0x5
) at main.cpp:194
#19 0x00c00390 in __libc_start_main (main=0x8084980 <main>, argc=1, 
ubp_av=0xbf912544, init=0x82b6bf0 <__libc_csu_init>,
    fini=0x82b6be0 <__libc_csu_fini>, rtld_fini=0xbd9940 <_dl_fini>, 
stack_end=0xbf91253c) at libc-start.c:220
#20 0x08084331 in _start ()

Here is the context in setrans_client.c:
209     hidden void fini_context_translations(void)
210     {
211             free(prev_r2t_trans);
212             free(prev_r2t_raw);
213             free(prev_t2r_trans);
214             free(prev_t2r_raw);
215     }

What is more, the addresses of these four variables are invalid:
(gdb) print prev_r2t_trans
Cannot access memory at address 0x40
(gdb) print prev_r2t_raw
Cannot access memory at address 0x3c
(gdb) print prev_t2r_trans
Cannot access memory at address 0x44
(gdb) print prev_t2r_raw
Cannot access memory at address 0x48

That is a nasty bug. I have understood the following:

Qt designer use dlopen 
with /usr/lib/qt-3.3/plugins/designer/libQVTKWidgetPlugin.so, which 
has "NEEDED libOSMesa.so.6", and libOSMesa.so.6 has "NEEDED libselinux.so.1". 
That means that Qt designer dynamically load libselinux.so.1. However, that 
library has thread-local static variables. I am pretty sure that one cannot 
dynamically load a library with such variables.

Now... why it is only triggered with the proprietary NVidia driver? If 
libOSMesa.so.6 or libselinux.so.1 is pre-loaded, designer does not segfault:
  LD_PRELOAD=/lib/libselinux.so.1 designer
Maybe without the NVidia driver OSMesa is already loaded before designer 
dlopen the plugin libraries.

That is a nasty bug. I do not know how it could be worked around. I do not 
even know if the problem is from vtk-qt, or glibc (libdl), or even from the 
compiler. At least there is know a workaround: preload libselinux.so.1.

Dan, could you please have a look at comment #21? If this is something that can
be fixed in vtk's packaging, could you explain how? Thanks!

P.S. There is vtk 5.0.4 soon hitting rawhide, but according to changelogs this
doesn't seem to be addressing the bug above. Still you may want to wait a couple
of days to have 5.0.4. in the repo. Thanks!

Maybe Ulrich will have some insights?

DSOs with TLS variables of course can be loaded dynamically.  There are certain
optimizations (direct segment access, such as the nvidia DSO performs) which is
a problem but I doubt it is the libselinux DSO.

Somebody will have to try to recreate the situation with something less
dangerous than kde and openGL.  My suspicion is that the problem hides rather in
those components than in libselinux.

(In reply to comment #24)
> DSOs with TLS variables of course can be loaded dynamically.  There are 
certain
> optimizations (direct segment access, such as the nvidia DSO performs) which 
is
> a problem but I doubt it is the libselinux DSO.
> 
> Somebody will have to try to recreate the situation with something less
> dangerous than kde and openGL.  My suspicion is that the problem hides 
rather in
> those components than in libselinux.

I must admit that my understanding of the problem is not satisfactory. I  
think the bug is related to how vtk use libOSMesa.

I have found a similar bug using the vtk module in python. It is quite easy to 
reproduce (without KDE nor Qt): install python, vtk, vtk-python, then import 
the vtk module in python and quit(). Here is a copy-paste of my terminal:
lrineau@schtroumpf ~ $ gdb python
GNU gdb Red Hat Linux (6.6-45.fc8rh)
Copyright (C) 2006 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 "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/python
[Thread debugging using libthread_db enabled]
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[New Thread -1209092416 (LWP 10549)]
>>> import vtk
>>> quit()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209092416 (LWP 10549)]
0x00bb98d4 in fini_context_translations () at setrans_client.c:211
211             free(prev_r2t_trans);
Missing separate debuginfos, use: debuginfo-install freetype-freeworld.i386 
libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXdmcp.i386 libXext.i386 
libXt.i386 libjpeg.i386 libpng.i386 libtiff.i386 libxcb.i386 mesa.i386 
vtk.i386
(gdb) bt
#0  0x00bb98d4 in fini_context_translations () at setrans_client.c:211
#1  0x00bb324e in fini_lib () at init.c:127
#2  0x00babad2 in __do_global_dtors_aux () from /lib/libselinux.so.1
#3  0x00bbb15c in _fini () from /lib/libselinux.so.1
#4  0x00bd9b22 in _dl_fini () at dl-fini.c:248
#5  0x00c1663e in exit (status=0) at exit.c:75
#6  0x04f30372 in Py_Exit (sts=0) at Python/pythonrun.c:1618
#7  0x04f3048f in handle_system_exit () at Python/pythonrun.c:1052
#8  0x04f306aa in PyErr_PrintEx (set_sys_last_vars=1) at 
Python/pythonrun.c:1062
#9  0x04f308ae in PyErr_Print () at Python/pythonrun.c:976
#10 0x04f3105d in PyRun_InteractiveOneFlags (fp=0xd3f420, 
filename=0x4f6a2dc "<stdin>", flags=0xbfa76bb8) at Python/pythonrun.c:793
#11 0x04f3112b in PyRun_InteractiveLoopFlags (fp=0xd3f420, 
filename=0x4f6a2dc "<stdin>", flags=0xbfa76bb8) at Python/pythonrun.c:721
#12 0x04f31267 in PyRun_AnyFileExFlags (fp=0xd3f420, 
filename=0x4f6a2dc "<stdin>", closeit=0, flags=0xbfa76bb8) at 
Python/pythonrun.c:690
#13 0x04f3ade6 in Py_Main (argc=0, argv=0xbfa76c84) at Modules/main.c:523
#14 0x080485d2 in main (argc=Cannot access memory at address 0x1
) at Modules/python.c:23
(gdb)

You can see that the first four lines of the backtrace is the same as for the 
current bug.

Laurent, could you try with rawhide and vtk 5.0.4? I don't really think it fixes
this (at least the changes summary doesn;t indicate this other than general bug
fixing), but one never knows.

Axel, I have tried the same procedure in a rawhide mock root (on my F-8 box) 
and I have not managed to reproduce the segfault. However, I have also tried 
to reproduce the bug in a Fedora 8 mock root, and I have also not managed to 
reproduce the bug.

I do not plan to switch by Fedora box to Rawhide or F-9 soon, so I do not know 
how to test the bug with rawhide.

(In reply to comment #27)
> However, I have also tried 
> to reproduce the bug in a Fedora 8 mock root, and I have also not managed to 
> reproduce the bug.

That's interesting - it means that some bits that are part of your testing
system but not part of the mock chroot environment are messing up this bug.

Maybe calling with strace and comparing the successful calls to open may reveal
which optional module interfered.

Was having this same problem on my machine Fedora 8, x86_64 on a dual core intel.
For me adding LD_PRELOAD=/usr/lib64/libOSMesa.so got designer and UIC working. 
Backtrace is same as first posted - slow connection and debuginfo's are big -
will post later.

vtk-5.0.4-19.fc8.src.rpm
qt-3.3.8b-2.fc8.src.rpm

*** Bug 377811 has been marked as a duplicate of this bug. ***

Created attachment 304595 [details]
GDB of Qt Designer under VTK okugin - selinus

This back trace shows a fault coming from SELinux - I believe this is actually
an error in SELinux that we need to look at.  Please tell me if I should
include anything else to make this easier.  Thanks.

Comment on attachment 304595 [details]
GDB of Qt Designer under VTK okugin - selinus

Change the MIME type and the filename, so that browsers can open the attachment
correctly.

While libselinux is triggering this crash it is not the problem.  See comment #24

(In reply to comment #29)
> Was having this same problem on my machine Fedora 8, x86_64 on a dual core 
intel.

What is your graphic card? What x.org driver do you use?

I use the nvidia driver as others have mentioned may be the cause - perhaps a
fault in the driver's behavior (something in libOSMesa messing it up maybe) -
not sure, still a noob when it comes to debugging.

I also see this on RHEL5 with qt-devel-3.3.6-23.el5, vtk-qt-5.0.4-19.el5 and
nvidia-graphics-173.14.12-28 (the latter two packages from AT RPMs), running on a 32-bit x86.

A configure script tries to run "/usr/lib/qt-3.3/bin/uic -L /usr/lib/kde3/plugins/designer -nounload -impl actest.h actest.ui > actest.cpp" and this results in a segfault. 

Backtrace:
#0  0x02ff579e in fini_context_translations () at setrans_client.c:207
#1  0x02ff0ed2 in fini_lib () at init.c:93
#2  0x02fe9592 in __do_global_dtors_aux () from /lib/libselinux.so.1
#3  0x02ff64cc in _fini () from /lib/libselinux.so.1
#4  0x00ac17de in _dl_fini () at dl-fini.c:248
#5  0x003ae9c9 in *__GI_exit (status=0) at exit.c:75
#6  0x00398df4 in __libc_start_main (main=0x804dee0 <main>, argc=7, ubp_av=0xbfbc97b4,
    init=0x80a28e0 <__libc_csu_init>, fini=0x80a28d0 <__libc_csu_fini>, rtld_fini=0xac15d0 <_dl_fini>,
    stack_end=0xbfbc97ac) at libc-start.c:262
#7  0x0804de51 in _start ()

This looks more and more like an incompatibility between libOSMesa, libselinux and the proprietary nvidia drivers.

Especially the closed source drivers make it difficult to debug, and Fedora does not support such a config. Unless someone can reproduce this with anything but the closed nvidia drivers then I think we will have to close this bug unfixed (or unfixable).

Of course it could also be a bug in vtk/kde/etc. that only surfaces with the closed source nvidia driver, but again we can't really do anything w/o having the code.

I'll keep this open for a while. Please also consider nagging the nvidia forums on this as perhaps the only ones able to provide a solution may be the nvidia Linux devs.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Could you please reopen this one.

It is still happening with Fedora 10.  : )