Created attachment 69308 [details] Xorg config On a system with a nVidia graphics card, nouveau driver, two monitors, Impress crashes without message as soon as a presentation is started (e.g., [F5]). The video setup does have Xinerama disabled in /etc/X11/xorg.conf. When Xinerama is enabled, Impress does not crash. A wild guess is that Impress performs a Xinerama specific call regardless whether Xinerama is available. System details: Fedora 17, x86_64, all updates as of today. NVidia GeForce 7600 GS graphics card. X.Org X Server 1.12.3 + nouveau driver 0.0.16. LibreOffice 3.5.x and 3.6.x. Note: When LibreOffice is started from the command line, it shows "Xlib: extension "XINERAMA" missing on display ":0".".
On which Linux distrib are you and which version? Could you try to retrieve a backtrace with symbols by following this link? http://wiki.documentfoundation.org/BugReport Website isn't available for the moment, it will be in some hours. If interested, you must: - install "libreoffice-dbg" package (it's the name for Debian and derivatives like Ubuntu) - once LO is launched, attach gdb to LO: - LOPID=$(pidof soffice.bin) - gdb soffice.bin $LOPID - type "c" (to continue) - go on to reproduce the crash. - bt (to retrieve the bt) - copy paste the output in the file and attach it to the bugtracker
Created attachment 69333 [details] Backtrace after crash
> On which Linux distrib are you and which version? See orig message: System details: Fedora 17, x86_64, all updates as of today.
Johan: sorry Johan, read a little too quickly :-) Thank you for your backtrace. Would it be possible to retrieve a bt with symbols to have extra details?
I did already install libreoffice-dbg. What else can I do to get more symbols?
Caolán: I know it hasn't been reproduced but does his bt can be helpful? I only found that "gdk_x11_window_set_user_time"was called only in vcl/unx/gtk/window/gtkframe.cxx 817 static void lcl_set_user_time( GtkWindow* i_pWindow, guint32 i_nTime ) 818 { 819 #if !GTK_CHECK_VERSION(3,0,0) 820 if( bGetSetUserTimeFn ) 821 { 822 bGetSetUserTimeFn = false; 823 p_gdk_x11_window_set_user_time = (setUserTimeFn)osl_getAsciiFunctionSymbol( GetSalData()->m_pPlugin, "gdk_x11_window_set_user_time" ); 824 } and this function must be called by the function GtkSalFrame::Show in this same file.
I suspect your symbols are out-of-step with your binary. Can you ensure the same version of both libreoffice and the libreoffice-dbg package are installed concurrently. Without that the trace is not so useful. And in general, Xinerama / multi-head issues in gtk+ are my fault ;-) so I'm interested ...
if you let abrt file the bug then the debuginfo will be installed automatically and the backtrace will be collected with symbols
abrt cannot cope with the dump.
I performed a clean install of LO + debuginfo, and managed to get a stacktrace with symbols. See attachment.
Created attachment 69394 [details] Backtrace after crash (with symbols)
Grief I just noticed the 3.5.7 in there - -so- much of this code has changed in recent time, that it's a different world for 3.5.x which has just got to the end of it's release lifetime. Any chance you can re-test with a 3.6.x build ? Thanks.
Well... not trivially. Fedora provides 3.5.7. I can download 3.6 builds from the LO site, but these do not provide debugging symbols. Can you provide a 3.6 build with symbols? Forward porting 3.6.x to Fedora doesn't look like an easy road.
Just to keep you informed... I backported 3.6.3 from Fedora 18 to Fedora 17. Unfortunately, the build did not contain debugging symbols. I'm trying to find out why.
(In reply to comment #14) > Just to keep you informed... > I backported 3.6.3 from Fedora 18 to Fedora 17. Unfortunately, the build did > not contain debugging symbols. I'm trying to find out why. This had been broken since the first 3.6 import. It should be fixed now.
Using F18 3.6.3.1-1 I applied David's patch and rebuilt it on F17. This time I got the symbols. And the crash.
Created attachment 69444 [details] Backtrace after crash (3.6.3, with symbols)
Just to know, what gtk versions are installed? For example on pc Debian x86-64 testing updated today, I've got: Source: gtk+2.0 Version: 2.24.10-2 I also got: Package: libgtk-3-0 Source: gtk+3.0 Version: 3.4.2-4 If you don't have libgtk-3-0, could you install it and give a new try?
Fedora 17 has gtk3-3.4.4-1 .
(In reply to comment #19) > Fedora 17 has gtk3-3.4.4-1 . Ok but according to this line of your bt, LO seems to use gtk 2: "/lib64/libgdk-x11-2.0.so.0" I don't know if there's a way to force LO to use gtk 3 (again just to test)
The Fedora 17 (and 18) rpm spec files build libreoffice using GTK2. Maybe Caolán McNamara can comment on this?
nobody uses the gtk3 plugin yet, its new ready for prime-time.
Hm - still in UNCONFIRMED status. Can one of the few devs involved (or OP) confirm the issue still exists and mark as NEW - or even better - if it's fixed we can mark it as WFM :)
It still crashes in the latest version available from the LO site (Versie 4.0.3.3 .3.3 (Bouw-id: 0eaa50a932c8f2199a615e1eb30f7ac74279539)).
Johan: would you have some time to retrieve a new bt, perhaps it could be crash somewhere else?
Version field is oldest version that we see the problem - we use just comments to say it still exists on a newer version. Putting version back
(In reply to comment #25) > Johan: would you have some time to retrieve a new bt, perhaps it could be > crash somewhere else? This would require downloading of the newest src, building with debuginfo, installing (including debuginfo) on a production system (since that's the one with 2 heads). This will take several hours of work and may risk the stability of the production system. Before undertaking this task: Did any of you devs try to reproduce the problem on one of your own systems? It must not be that hard to find a dual-head system, disable Xinerama, and start a presentation.
Created attachment 80185 [details] Backtrace after crash (4.1.0.0 beta 1)
#0 0x00000035e14794ba in gdk_x11_window_set_user_time () from /lib64/libgdk-x11-2.0.so.0 #1 0x00007fa7d9acbd3d in lcl_set_user_time (i_pWindow=0xc08eb0, i_nTime=12184672, i_nTime@entry=314940849) at /usr/src/debug/libreoffice-3.6.3.1/vcl/unx/gtk/window/gtkframe.cxx:826 Seems to be: p_gdk_x11_window_set_user_time( widget_get_window(GTK_WIDGET(i_pWindow)), i_nTime ); Crashing inside that call. Johan - thanks so much for your hard work on this getting traces ! :-)
I pushed a patch to master (a link should soon show up here), I'd love to know if it fixes the issue - if so, we'll back port it. Ultimately, this is all a work-around for some horrible legacy metacity bug (IIRC). Anyhow - that is as it may be, but what would -really- help would be if you could install debuginfo symbols for your system's gtk2 - then we could see exactly what is going wrong inside that gdk function call :-) I'm still suspicious that (since we realize all our windows at construction time) there should be a valid / non-NULL GdkWindow around there but ... Any chance of a new master trace just with the gdk symbols installed. Anyhow - sorry for the problem, and thanks for the great debugging ! :-)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d5d1415161ef687cf0d4d6eccad0940e3016110 fdo#56583 - avoid setting user time on unrealized windows. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 80210 [details] Backtrace after crash (4.1.0.0 beta 1, with gtk2 debuginfo) Hope this helps.
Hi Johan, Yes - it helps a lot; that shows the crash is at the 1st pointer de-reference: #0 0x00000036952795da in IA__gdk_x11_window_set_user_time (window=0x0, timestamp=<optimized out>) at gdkwindow-x11.c:3726 #1 0x00007fffea04d2ad in lcl_set_user_time (i_pWindow=0x1da2230, i_nTime=6591760, i_nTime@entry=606035500) at /usr/sr And that window == NULL that we pass in. ie. my patch will fix your issue ;-) whether you then find another issue, I don't know - but I'll back-port this to various branches now. Thanks !
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=baa6b7f1a86a0014c9ce176b687bf6ac3edf933d&h=libreoffice-4-1 fdo#56583 - avoid setting user time on unrealized windows. It will be available in LibreOffice 4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8fc65f9095bb95692afb1d7522d4d5765dbb3658&h=libreoffice-3-6 fdo#56583 - avoid setting user time on unrealized windows. It will be available in LibreOffice 3.6.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d03cef0145db7475db66dd611c22c6e6fc51b48&h=libreoffice-4-0 fdo#56583 - avoid setting user time on unrealized windows. It will be available in LibreOffice 4.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for the patch. It does, indeed, fix the crash. The resultant LO (4.1.0.0 beta1) is unfortunately not usable, since there are many other things that go wrong. Fonts come out wrong, images are garbled, and the external display (where the presention is shown) stays empty. I'm reasonably sure this is not related to the problem at hand. I'll await 4.1 with confidence.
> The resultant LO (4.1.0.0 beta1) is unfortunately not usable, > since there are many other things that go wrong. Fonts come > out wrong, images are garbled, and the external display (where > the presention is shown) stays empty. Wow -those sound horrible; I'm not aware of duplicates of that, nor can I reproduce them. Can you file some other bugs while you're here and make them 4.1 blockers (add "4.1mab" to the dependencies) - so we address them asap. Otherwise; there should be a 4.0 snapshot with the fix out shortly; see http://dev-builds.libreoffice.org/ Thanks !
I'll download the 4.0 and 4.1 snapshots when they are available and see if they show these problems. I build Fedora rpms, and I needed a lot of trickery to backport the F19 kits to F17 so it is very well possible I made some mistakes (mixing up library versions and such).
The nightly build of 4.1.0.0 beta1 shows the same erroneous behaviour. Do you have a 4.0 build (and/or 3.6.6) with the patch applied so I can test if it is a regression?
try here: http://dev-builds.libreoffice.org/daily/libreoffice-4-0/ or the same for -3-6.
All directories under http://dev-builds.libreoffice.org/daily/libreoffice-4-0/ are empty. Same for 3-6. Only 4-1 contains builds.
Bother; so - no I don't have a build (sorry) making generic linux builds is rather a black-art, sorry about that. OTOH - if we can get your other bugs filed / fixed on master that would be the best solution - they sound debilitating & we can't ship 4.1 like that. Master -should- be usable at all times :-)
*** Bug 53555 has been marked as a duplicate of this bug. ***