Bug 58699 - Impress remote doesn't close
Summary: Impress remote doesn't close
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta1
Hardware: Other All
: high critical
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:4.1.0 target:4.0.1
Keywords:
: 60325 60736 61265 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-12-24 04:56 UTC by Fahad Al-Saidi
Modified: 2013-11-16 23:07 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of what is not closing (142.17 KB, image/png)
2013-01-25 10:42 UTC, Mihkel Tõnnov
Details
Trace (43.03 KB, text/plain)
2013-01-25 11:00 UTC, Mihkel Tõnnov
Details
trace from GNU/Linux 64, LiBo RC2 (8.54 KB, text/plain)
2013-01-25 11:06 UTC, Marco Menardi
Details
Trace when I tried to close the program and was not responding (7.38 KB, text/plain)
2013-01-25 11:08 UTC, Marco Menardi
Details
Video showing the problem GNU/Linux 64, LiBo RC2 (529.10 KB, video/x-matroska)
2013-01-25 11:13 UTC, Marco Menardi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fahad Al-Saidi 2012-12-24 04:56:58 UTC
There is no way to close impress remote if you accidentally open it. Close button doesn't work.
Comment 1 Marco Menardi 2012-12-27 00:32:38 UTC
I can confirm in Beta2 too, I just selected that menu item by mistake and had to kill Impress as a whole, very bad if I would had my work unsaved.
Here 4.0beta2, GNU/Linux debian sid 64, KDE as DE
Comment 2 Makoto Takizawa 2013-01-03 13:04:12 UTC
I can confirm in night build 2/Jan/2012 mac os x version, too.
mac ox x ver 10.7.5
Comment 3 Michael Meeks 2013-01-11 11:22:32 UTC
This closes just fine for me - both with the close button and the X tick at the top right using a libreoffice-4-0 build from just after rc1.

Can you confirm that this continues to be a problem with RC1 ?
Comment 4 Marco Menardi 2013-01-11 18:49:01 UTC
I've just installed LiBo4.0RC1, and the bug is still there
Comment 5 Fahad Al-Saidi 2013-01-12 10:01:43 UTC
I also installed RC1 and the bug is still existing.
Comment 6 Mihkel Tõnnov 2013-01-22 01:52:13 UTC
Still doesn't close in RC1 for me too. Reopening the bug.
Comment 7 Joel Madero 2013-01-23 15:51:10 UTC
Tricky but I think I'm marking this as NEW as three users are reporting the issue. 

Michael - any idea what could make it not work for three people but works fine for you?

Marking as NEW (confirmed)

I tend to agree that this is a CRITICAL bug as the inability to close would be a big problem, especially for a new feature.

Curious to know what's going on that's unique to your environments that would cause this issue. Can you give us more details about your setups?
Comment 8 Michael Meeks 2013-01-25 10:23:28 UTC
Can someone attach a screenshot of what is not closing ? :-)

I have seen a deadlock when using the remote that I'd like to nail-down as well.

As/when this happens - can you please do:

$ pidof soffice.bin
$ gdb
attach <pid printed out above>
thread apply all backtrace

and append the result here ? then we can nail it I think. We really need the debuginfo packages installed to do that - but if you don't have them any sort of trace -may- help.

Thanks !
Comment 9 Mihkel Tõnnov 2013-01-25 10:42:49 UTC
Created attachment 73636 [details]
Screenshot of what is not closing
Comment 10 Mihkel Tõnnov 2013-01-25 11:00:45 UTC
Created attachment 73637 [details]
Trace

Added trace as Michael requested. Using RC2, without any LibO debug packages (do the pre-releases / daily builds from http://dev-builds.libreoffice.org/ have them at all?).
Comment 11 Marco Menardi 2013-01-25 11:06:18 UTC
Created attachment 73638 [details]
trace from GNU/Linux 64, LiBo RC2
Comment 12 Marco Menardi 2013-01-25 11:08:12 UTC
Created attachment 73639 [details]
Trace when I tried to close the program and was not responding
Comment 13 Marco Menardi 2013-01-25 11:13:00 UTC
Created attachment 73640 [details]
Video showing the problem GNU/Linux 64, LiBo RC2

Here you can see the exact steps and what happens :)
Comment 14 Michael Meeks 2013-01-26 11:31:34 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e99b540d8985b87247519c951e6ef65a01b1f5c9

Is a memory corruption related to that sdremote dialog that may cause something like this issue - I'd love a test of a recent master build with that fix included.
Comment 15 Mateusz 2013-01-28 15:27:39 UTC
I would test it, but the newest build LO 4.0 still has this bug and there is not master build for Linux 32bit (deb package). Could anyone else test it
Comment 16 Michael Meeks 2013-01-29 11:51:36 UTC
Anyone else to test it ? the suspected fix went into the -4-0-0 branch just now - so should be in rc3.
Comment 17 Mateusz 2013-01-30 15:20:02 UTC
(In reply to comment #16)
> Anyone else to test it ? the suspected fix went into the -4-0-0 branch just
> now - so should be in rc3.

Michael, there still is a bug. Tested on libreoffice-4-0~2013-01-29_23.13.14_LibO-Dev_4.0.1.0_Linux_x86_deb.tar.gz
Comment 18 Jorendc 2013-02-02 16:41:06 UTC
(In reply to comment #16)
> Anyone else to test it ? the suspected fix went into the -4-0-0 branch just
> now - so should be in rc3.

Can confirm this is still reproducible. Therefore back to ... NEW (or REOPENED, still need to discuss this kind of specific situations on the QA call).
Comment 19 Thorsten Behrens (CIB) 2013-02-06 00:18:36 UTC
*** Bug 60325 has been marked as a duplicate of this bug. ***
Comment 20 Fahad Al-Saidi 2013-02-06 03:52:12 UTC
I can confirm this bug in LibreOffice_4.0.0.3_Linux_x86_deb
Comment 21 Michael Meeks 2013-02-06 14:00:41 UTC
My strong suspicion is that this is KDE specific; can someone that can repeat the problem do:

export SAL_USE_VCLPLUGIN=gtk
pkill -9 -f soffice.bin
soffice -impress

and see if the problem recurs ?
Comment 22 Mateusz 2013-02-06 14:54:58 UTC
(In reply to comment #21)
> My strong suspicion is that this is KDE specific; can someone that can
> repeat the problem do:
> 
> export SAL_USE_VCLPLUGIN=gtk
> pkill -9 -f soffice.bin
> soffice -impress
> 
> and see if the problem recurs ?

It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2. Besides, Your approach doesn't work.
Comment 23 Michael Meeks 2013-02-06 15:40:55 UTC
> It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2.
> Besides, Your approach doesn't work.

Seriously ? that's bad... So - we need someone that can reproduce this that is a developer; it works perfectly for me, and Thorsten, the code seems reasonable too. The dialog in itself is profoundly non-useful - so one (non-ideal) workaround is just not to launch it ;-)

But it is deeply annoying that this is not reproducible everywhere; perhaps a trace with more debuginfo would be interesting ? but really it's just that the dialog is not closed - 'Execute' never completes (I suspect) - so the question is: why !?
Comment 24 Michael Meeks 2013-02-06 15:50:20 UTC
Wow - so, this looks rather bad. It -seems- that the code path is missing some:

#ifdef ENABLE_SDREMOTE

code-path - which is horrible ! it looks like we simply havn't enabled the sdremote (or bluetooth) in the builds [!!].
Comment 25 Michael Meeks 2013-02-06 16:03:27 UTC
source/ui/dlg/tpoption.cxx-#ifndef ENABLE_SDREMOTE_BLUETOOTH
source/ui/dlg/tpoption.cxx:    aCbxEnableSdremote.Hide();
source/ui/dlg/tpoption.cxx-#endif

And I can see -no- mention of the expected:

source/ui/dlg/tpoption.src:    CheckBox CBX_ENABLE_SDREMOTE
source/ui/dlg/tpoption.src-    {
source/ui/dlg/tpoption.src:        HelpID = "sd:CheckBox:TP_OPTIONS_MISC:CBX_ENABLE_SDREMOTE";
source/ui/dlg/tpoption.src-        Pos = MAP_APPFONT ( 12 , 158  ) ;
source/ui/dlg/tpoption.src-        Size = MAP_APPFONT ( 242 , 10 ) ;
source/ui/dlg/tpoption.src-        TabStop = TRUE ;
source/ui/dlg/tpoption.src-        Text [ en-US ] = "Enable remote control" ;
source/ui/dlg/tpoption.src-    };

in the impress 'General' options page (underneath 'Always with current page') in Tools -> Options -> LibreOffice Impress.

ie. that is -certainly- not defined.
Comment 26 Marco Menardi 2013-02-06 16:22:11 UTC
(In reply to comment #23)
> > It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2.
> > Besides, Your approach doesn't work.
> 
> Seriously ? that's bad... So - we need someone that can reproduce this that
> is a developer; it works perfectly for me, and Thorsten, the code seems
> reasonable too. The dialog in itself is profoundly non-useful - so one
> (non-ideal) workaround is just not to launch it ;-)
> 
> But it is deeply annoying that this is not reproducible everywhere; perhaps
> a trace with more debuginfo would be interesting ? but really it's just that
> the dialog is not closed - 'Execute' never completes (I suspect) - so the
> question is: why !?

One general suggestion to developers: use virtual machines! For testing I use KVM with some stock distro installed, and/or live cd with enough ram assigned (is used as hard disk, you need a lot to let the Libo packages be uncompressed and installed).
I'm a KDE fan, but I've just downloaded (since you had some dubt about KDE):
ubuntu-12.04.1-desktop-i386.iso
run with KVM and 2GB of ram, inside the vm I downloaded the RC3, installed and can confirm the issue there too.
I usually have a spare basic VM Kubuntu installation and run it in "snapshot" mode, do all the tests and when I turn it off everything is back as previous state, so I can do a "clean" test again at will.
Comment 27 Michael Meeks 2013-02-06 16:43:24 UTC
Turns out the lack of functionality here is down to dbus-glib-1 version - which in turn is down to the ancient base-line we're forced to build on, which in turn is related to not having the updated RHEL-5 base to compile from.

Caolan - how is that coming along ?
Comment 28 Not Assigned 2013-02-06 17:50:51 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=535dd86dfa4fbe0f2555205cb925586176267800

fdo#58699 - sdremote - fix it so it closes even with no bluetooth.



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 29 Michael Meeks 2013-02-06 19:39:48 UTC
Marco - the fundamental problem is a difference in build of the same source code between the really old systems we make the generic builds on (which are missing a recent dbus and hence bluetooth) and the modern developer systems ~all of us use to compile with. That's the root cause of the issue.

We'll be pulling up our base system for 4.0.1 I hope - until then you'll need to use a distribution build of 4.0.0 to use the bluetooth remote.
Comment 30 Not Assigned 2013-02-06 19:45:31 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=1ff566f4887ae0ddf99159f8f035e9b91a67643d&h=libreoffice-4-0

fdo#58699 - sdremote - fix it so it closes even with no bluetooth.


It will be available in LibreOffice 4.0.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 31 Michael Meeks 2013-02-06 19:54:53 UTC
Fixed :-)
Comment 32 Marco Menardi 2013-02-06 20:52:02 UTC
(In reply to comment #29)
> Marco - the fundamental problem is a difference in build of the same source
> code between the really old systems we make the generic builds on (which are
> missing a recent dbus and hence bluetooth) and the modern developer systems
> ~all of us use to compile with. That's the root cause of the issue.
> 
> We'll be pulling up our base system for 4.0.1 I hope - until then you'll
> need to use a distribution build of 4.0.0 to use the bluetooth remote.

Yes, this issue sure, but sometime I see developers replying that can't reproduce something and they are using a different OS/version/whatever.
I think could be trivial have at least 8-10 VM with the main GNU/Linux distro and desktops (20GB x 10VM = 200GB) with gdb installed and be able to reproduce and catch more useful info than every average "QA tester" like me can provide.
I've the feeling that developers (and testers also ;P) would save a lot of time this way, i.e. 30 messages on this single issue is a lot of time wasted, every time everyone here has to refocus on what has been tested, carefully re-read what has been said, guess or ask for further info and so on.
This is just a friendly suggestion and my opinion, use or ignore it at your own risk ;P
Comment 33 Jorendc 2013-02-07 22:07:42 UTC
I can verify it's fixed -> VERIFIED FIXED. Thanks everyone involved.
Comment 34 Adolfo Jayme 2013-02-12 19:11:16 UTC
*** Bug 60736 has been marked as a duplicate of this bug. ***
Comment 35 Thomas van der Meulen 2013-02-22 09:04:09 UTC
*** Bug 61265 has been marked as a duplicate of this bug. ***