Download it now!
Bug 56583 - Impress crashes when presentation starts (dual-head, no Xinerama)
Summary: Impress crashes when presentation starts (dual-head, no Xinerama)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.5.6.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0 target:4.1.0.0.beta2 tar...
Keywords:
: 53555 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-10-30 13:47 UTC by Johan Vromans
Modified: 2014-02-10 21:18 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Xorg config (2.93 KB, text/plain)
2012-10-30 13:47 UTC, Johan Vromans
Details
Backtrace after crash (3.34 KB, text/plain)
2012-10-30 20:43 UTC, Johan Vromans
Details
Backtrace after crash (with symbols) (8.53 KB, text/plain)
2012-11-01 15:00 UTC, Johan Vromans
Details
Backtrace after crash (3.6.3, with symbols) (8.72 KB, text/plain)
2012-11-02 13:43 UTC, Johan Vromans
Details
Backtrace after crash (4.1.0.0 beta 1) (17.50 KB, text/plain)
2013-06-03 07:37 UTC, Johan Vromans
Details
Backtrace after crash (4.1.0.0 beta 1, with gtk2 debuginfo) (17.73 KB, text/plain)
2013-06-03 11:21 UTC, Johan Vromans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Vromans 2012-10-30 13:47:05 UTC
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".".
Comment 1 Julien Nabet 2012-10-30 20:20:52 UTC
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
Comment 2 Johan Vromans 2012-10-30 20:43:09 UTC
Created attachment 69333 [details]
Backtrace after crash
Comment 3 Johan Vromans 2012-10-30 20:44:16 UTC
> On which Linux distrib are you and which version?

See orig message:
System details: Fedora 17, x86_64, all updates as of today.
Comment 4 Julien Nabet 2012-10-30 20:46:05 UTC
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?
Comment 5 Johan Vromans 2012-10-31 07:23:33 UTC
I did already install libreoffice-dbg. What else can I do to get more symbols?
Comment 6 Julien Nabet 2012-11-01 05:31:36 UTC
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.
Comment 7 Michael Meeks 2012-11-01 10:01:31 UTC
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 ...
Comment 8 Caolán McNamara 2012-11-01 10:38:18 UTC
if you let abrt file the bug then the debuginfo will be installed automatically and the backtrace will be collected with symbols
Comment 9 Johan Vromans 2012-11-01 14:59:35 UTC
abrt cannot cope with the dump.
Comment 10 Johan Vromans 2012-11-01 15:00:10 UTC
I performed a clean install of LO + debuginfo, and managed to get a stacktrace with symbols. See attachment.
Comment 11 Johan Vromans 2012-11-01 15:00:43 UTC
Created attachment 69394 [details]
Backtrace after crash (with symbols)
Comment 12 Michael Meeks 2012-11-01 16:28:50 UTC
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.
Comment 13 Johan Vromans 2012-11-01 17:30:06 UTC
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.
Comment 14 Johan Vromans 2012-11-02 08:04:10 UTC
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.
Comment 15 David Tardon 2012-11-02 09:26:26 UTC
(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.
Comment 16 Johan Vromans 2012-11-02 13:42:48 UTC
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.
Comment 17 Johan Vromans 2012-11-02 13:43:24 UTC
Created attachment 69444 [details]
Backtrace after crash (3.6.3, with symbols)
Comment 18 Julien Nabet 2012-11-24 07:45:20 UTC
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?
Comment 19 Johan Vromans 2012-11-24 11:15:39 UTC
Fedora 17 has gtk3-3.4.4-1 .
Comment 20 Julien Nabet 2012-11-24 17:37:10 UTC
(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)
Comment 21 Johan Vromans 2012-11-24 19:10:27 UTC
The Fedora 17 (and 18) rpm spec files build libreoffice using GTK2. Maybe Caolán McNamara can comment on this?
Comment 22 Caolán McNamara 2012-11-27 20:03:07 UTC
nobody uses the gtk3 plugin yet, its new ready for prime-time.
Comment 23 Joel Madero 2013-06-02 03:03:11 UTC
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 :)
Comment 24 Johan Vromans 2013-06-02 14:04:42 UTC
It still crashes in the latest version available from the LO site (Versie 4.0.3.3 .3.3 (Bouw-id: 0eaa50a932c8f2199a615e1eb30f7ac74279539)).
Comment 25 Julien Nabet 2013-06-02 14:22:14 UTC
Johan: would you have some time to retrieve a new bt, perhaps it could be crash somewhere else?
Comment 26 Joel Madero 2013-06-02 16:56:17 UTC
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
Comment 27 Johan Vromans 2013-06-02 19:26:11 UTC
(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.
Comment 28 Johan Vromans 2013-06-03 07:37:52 UTC
Created attachment 80185 [details]
Backtrace after crash (4.1.0.0 beta 1)
Comment 29 Michael Meeks 2013-06-03 08:18:42 UTC
#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 ! :-)
Comment 30 Michael Meeks 2013-06-03 08:31:55 UTC
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 ! :-)
Comment 31 Commit Notification 2013-06-03 08:40:32 UTC
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.
Comment 32 Johan Vromans 2013-06-03 11:21:19 UTC
Created attachment 80210 [details]
Backtrace after crash (4.1.0.0 beta 1, with gtk2 debuginfo)

Hope this helps.
Comment 33 Michael Meeks 2013-06-03 11:36:34 UTC
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 !
Comment 34 Commit Notification 2013-06-03 11:42:52 UTC
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.
Comment 35 Commit Notification 2013-06-03 12:19:53 UTC
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.
Comment 36 Commit Notification 2013-06-03 12:20:12 UTC
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.
Comment 37 Johan Vromans 2013-06-03 14:03:06 UTC
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.
Comment 38 Michael Meeks 2013-06-03 15:04:00 UTC
> 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 !
Comment 39 Johan Vromans 2013-06-03 17:26:19 UTC
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).
Comment 40 Johan Vromans 2013-06-04 08:22:18 UTC
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?
Comment 41 Michael Meeks 2013-06-04 08:56:16 UTC
try here: http://dev-builds.libreoffice.org/daily/libreoffice-4-0/ or the same for -3-6.
Comment 42 Johan Vromans 2013-06-04 09:01:13 UTC
All directories under http://dev-builds.libreoffice.org/daily/libreoffice-4-0/ are empty.
Same for 3-6.
Only 4-1 contains builds.
Comment 43 Michael Meeks 2013-06-04 09:37:08 UTC
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 :-)
Comment 44 Caolán McNamara 2013-11-05 16:22:29 UTC
*** Bug 53555 has been marked as a duplicate of this bug. ***
Comment 45 Julien Nabet 2014-02-10 21:18:02 UTC
*** Bug 53555 has been marked as a duplicate of this bug. ***