Bug 46687 - 'Find' toolbar causes writer,calc,impress, not responding
Summary: 'Find' toolbar causes writer,calc,impress, not responding
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: bibisected35 BSA target:3.6.0 target:...
Keywords:
: 45579 46965 48641 49077 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-02-27 11:45 UTC by alex
Modified: 2012-04-23 08:31 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
when I did the step 4. (17.20 KB, image/png)
2012-02-27 11:45 UTC, alex
Details
Backtrace (masteer) (3.32 KB, text/plain)
2012-03-02 16:10 UTC, Josh Heidenreich
Details
Backtrace (master) - improved (4.03 KB, text/plain)
2012-03-02 16:23 UTC, Josh Heidenreich
Details
bt from master on pc Debian x86-64 (3.91 KB, text/plain)
2012-03-10 12:48 UTC, Julien Nabet
Details
bisect log in the range indicated by bibisect (7.47 KB, text/plain)
2012-04-07 18:27 UTC, Björn Michaelsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2012-02-27 11:45:14 UTC
Created attachment 57729 [details]
when I did the step 4.

Problem description: 

Steps to reproduce:
1. ctrl+F,and you should see the 'Find' toolbar at the bottom.
2. Move 'Find' toolbar away from bottom to somewhere, which means Find toolbar becomes floating.
3. click the X on the toolbar, which means closed
4. ctrl+F again, which means, I wanna open the Find toolbar.

Current behavior:
The whole writer is dead.

Expected behavior:
I should see the 'Find' toolbar again

Platform (if different from the browser): 
 Ubuntu 10.04.4 LTS             
Browser: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.10.229 Version/11.62
Comment 1 Petr Mladek 2012-03-01 02:01:30 UTC
I am able to reproduce it. I get the following error message on console:

--- cut ---
The program 'soffice' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 15349 error_code 8 request_code 42 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
--- cut ---
Comment 2 Petr Mladek 2012-03-01 02:04:05 UTC
I see the problem also with 3.5.0-release. It was reported weeks after the release, so it does not affected that many people in the real life. So, it should not block the release => lowering the severity a bit.

Of course, it is still pretty bad and we should fix it ASAP, so I am going to add it into most annoying bugs.
Comment 3 sasha.libreoffice 2012-03-01 04:21:44 UTC
reproduced in 3.5.0 rc 3 and in 3.6.0 master e9d045f-9eed775-f06126 on Fedora64 bit
Steps to reproduce:
0. Start Writer
1. Press Ctrl-F
Comment 4 Jan Holesovsky 2012-03-01 04:27:20 UTC
Alex: Is this in KDE?  If yes, it is most probably the Qt bug that Lubos has fixed recently - you should request its backport to Ubuntu LTS.
Comment 5 sasha.libreoffice 2012-03-01 05:09:53 UTC
reproduced in Gnome 3 on Fedora 64 bit
Comment 6 alex 2012-03-01 06:07:00 UTC
(In reply to comment #4)
> Alex: Is this in KDE?  If yes, it is most probably the Qt bug that Lubos has
> fixed recently - you should request its backport to Ubuntu LTS.

No, it is Gnome2.30.2. QT version is 4.7.0 backported from kubuntu backport ppa.
Comment 7 Thomas Collerton 2012-03-02 03:27:19 UTC
Reproducible on master and 3.5.0, however if the --sync argument is appended to the ./soffice.bin command, no crash happens. Working on Gnome 3 with kde disabled.
Comment 8 Josh Heidenreich 2012-03-02 16:10:06 UTC
Created attachment 57950 [details]
Backtrace (masteer)

I got this backtrace by running soffice --writer --sync, and breaking on gdk_x_error().

I don't have symbols for everything, but it's a start.

Interestingly, with --sync, it didn't crash, at least not the first time. Only by opening and closing about 5 - 10 times did it crash. Looks like a race condition.
Comment 9 Josh Heidenreich 2012-03-02 16:23:53 UTC
Created attachment 57951 [details]
Backtrace (master) - improved

Also, for the record I am on Ubuntu 10.04, Gnome
Comment 10 vermontpoet 2012-03-04 19:56:59 UTC
(In reply to comment #2)
> I see the problem also with 3.5.0-release. It was reported weeks after the
> release, so it does not affected that many people in the real life.

Not true. Bear in mind that 3.5 didn't make it into the Natty LibreOffice Ubuntu PPA until weeks after release. The bug appeared the day after upgrading my system.  I just filed the same bug, I think, here:

https://bugs.freedesktop.org/show_bug.cgi?id=46965
Comment 11 Petr Mladek 2012-03-05 09:06:22 UTC
*** Bug 46965 has been marked as a duplicate of this bug. ***
Comment 12 alex 2012-03-05 15:18:51 UTC
(In reply to comment #10)
> (In reply to comment #2)
> > I see the problem also with 3.5.0-release. It was reported weeks after the
> > release, so it does not affected that many people in the real life.
> 
> Not true. Bear in mind that 3.5 didn't make it into the Natty LibreOffice
> Ubuntu PPA until weeks after release. The bug appeared the day after upgrading
> my system.  I just filed the same bug, I think, here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=46965

Yes, you do. It is quite annoying that ctrl+F it is a function that I use so often.
Comment 13 Julien Nabet 2012-03-10 12:48:26 UTC
Created attachment 58276 [details]
bt from master on pc Debian x86-64

I retrieved this pb too (I've been had this one since a while)

First I had this :
The program 'soffice' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 10673 error_code 8 request_code 42 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

So to retrieve the bt, I did before launching soffice.bin --calc
export GDK_SYNCHRONIZE="1"
(commit c604a738f48ffa4c12f7c9801d03a146303d3123)
Comment 14 Julien Nabet 2012-03-12 12:29:20 UTC
*** Bug 45579 has been marked as a duplicate of this bug. ***
Comment 15 Roman Eisele 2012-03-16 00:20:11 UTC
(Just for the record: it was already clear from the comments above that this is a Linux-specific bug, but just be be absolutely sure that there is no hidden cross-platform bug behind it, I tested the 'steps to reproduce' given in Description on MacOS X. Result: no problems, everything works as expected, LibreOffice is still completely functional after step 4. So, confirmed: a Linux-only bug.)
Comment 16 Caolán McNamara 2012-04-03 14:21:50 UTC
I saw this recently on a master build on x86_64 under GNOME. Has anyone seen this *not* on a 64bit machine ?, i.e. is it a generic bug or a 64bit one ?
Comment 17 Björn Michaelsen 2012-04-06 17:32:46 UTC
Confirmed on Ubuntu 12.04 32Bit. So its not a 64Bit specific issue. The floating is essential though.
Comment 18 Björn Michaelsen 2012-04-06 17:45:51 UTC
bjoern@helium:~/bibisect3-5/bibisect-3-5$ git bisect log
# bad: [4c30602f43475389f81b1d981ce8ee9a3410b9d9] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
git bisect bad 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
# bad: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
git bisect bad 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
# good: [4bae211a2589ecaec48c1409cf7cd1580d3e14c5] source-hash-31e7820f03badc3c6fe8fdaffb74f2125e05ea96
git bisect good 4bae211a2589ecaec48c1409cf7cd1580d3e14c5
# good: [eca91b9203dad6a608086451c6ad119f856782e4] source-hash-003973f5d461b981737946456eb08b2b7d60f150
git bisect good eca91b9203dad6a608086451c6ad119f856782e4
# good: [b7e3f39afb62647252f6e649962e94eb967a3cce] source-hash-3e5eece31d93ed378613991c8a8bbe451aa5c081
git bisect good b7e3f39afb62647252f6e649962e94eb967a3cce
# skip: [e279a23b4a849f4a24050fbe668c12f81a45fb02] source-hash-a39f4e5b57f5e518cc1ba09d5801da07b52fbaa5
git bisect skip e279a23b4a849f4a24050fbe668c12f81a45fb02
# good: [6a6cdbd2c691e6ebf692910c2623f8607cf73187] source-hash-dc8249af103741415a074d9bbf8b1211f24a7c3f
git bisect good 6a6cdbd2c691e6ebf692910c2623f8607cf73187
# bad: [860351a174dea414f94654859c7c9cacf14fa102] source-hash-2175576c120806f8415be7ab2051ba639a18f564
git bisect bad 860351a174dea414f94654859c7c9cacf14fa102

thus the cause in one of these 128 commits:
git log dc8249af103741415a074d9bbf8b1211f24a7c3f..2175576c120806f8415be7ab2051ba639a18f564
Comment 19 Björn Michaelsen 2012-04-06 17:52:02 UTC
CCing Michael Meeks too -- in that range there are 34 commits by Michael touching vcl/unx/gtk.
Comment 20 Björn Michaelsen 2012-04-07 18:27:36 UTC
Created attachment 59634 [details]
bisect log in the range indicated by bibisect

Bisecting in the bibisect range indicates:
bjoern@helium:~/.jenkins/jobs/libreoffice-fdo46687/workspace$ git bisect good
232c6f1309bb73cc6516c58da749f64ce3668932 is the first bad commit
commit 232c6f1309bb73cc6516c58da749f64ce3668932
Author: Michael Meeks <michael.meeks@suse.com>
Date:   Tue Oct 25 16:17:40 2011 +0100

    gtk3: cleanup timeout source, to avoid annoying warnings with old glibs

:040000 040000 bd152bc7f41c383f6f06224a04a7b66aa3a24a1c 273687495f03af50f40753cca2f0b180f3237ae2 M	vcl
Comment 21 dE 2012-04-14 09:57:07 UTC
HOLY CRAP! Now that's a major bug.

As you know, this doesn't happen with the QT build.
Comment 22 Florian Reisinger 2012-04-15 03:40:26 UTC
Changed whiteboard, according to the wiki
Comment 23 Michael Meeks 2012-04-15 11:10:24 UTC
Interesting bug - I can't reproduce this at all with SAL_SYNCHRONIZE set, but without it set it is trivial to reproduce (urgh). Julien - your traces matches the one I don't get with SAL_SYNC... set :-)
Comment 24 Björn Michaelsen 2012-04-17 02:09:35 UTC
*** Bug 48641 has been marked as a duplicate of this bug. ***
Comment 25 Michael Meeks 2012-04-18 02:48:38 UTC
Chopped the range down: it is certainly in the big gtk+ re-factor between:
	+ dc4c10d72 - has the crash [!] ...
	+ 403608200 - no crash

Will try to peel this back, and hope the commits there build nicely in isolation.
Comment 26 Michael Meeks 2012-04-18 07:52:10 UTC
the deadlock is annoying from the gtk X error handler I guess. I got an xtrace log thus:

004:<:0081:  8: Request(23): GetSelectionOwner atom=0x168("CLIPBOARD")
002:>:1387: Event PropertyNotify(28) window=0x0460044e atom=0x27("WM_NAME") time=0x0612ed8d state=NewValue(0x00)
004:>:0081: Event PropertyNotify(28) window=0x0460044e atom=0x25("WM_ICON_NAME") time=0x0612ed8d state=NewValue(0x00)
002:>:1387: Event PropertyNotify(28) window=0x0460044e atom=0x128("_NET_WM_ICON_NAME") time=0x0612ed8d state=NewValue(0x00)
002:>:1387: Event PropertyNotify(28) window=0x0460044e atom=0x25("WM_ICON_NAME") time=0x0612ed8d state=NewValue(0x00)
004:>:0081:32: Reply to GetSelectionOwner: owner=0x04004954

This previous synchronous call completed without errors, so something below up to the error caused the grief:

002:>:1387: Event PropertyNotify(28) window=0x04600003 atom=0x297("SAL_GETTIMEEVENT") time=0x0612ed8d state=NewValue(0x00)
002:<:1388: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x0460044f property=0x13a("_NET_WM_USER_TIME") type=0x6("CARDINAL") data=0x00000000;
002:<:1389: 28: Request(12): ConfigureWindow window=0x0460044e values={x=772 y=786 width=371 height=70}
002:<:138a: 96: Request(18): ChangeProperty mode=Replace(0x00) window=0x0460044e property=0x28("WM_NORMAL_HINTS") type=0x29("WM_SIZE_HINTS") data=0x00000234,0x00000000,0x00000000,0x00000000,0x00000000,0x00000173,0x00000046,0x00000173,0x00000046,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x0000000a;
002:<:138b: 20: Request(12): ConfigureWindow window=0x0460044e values={x=772 y=786}
002:<:138c: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x0460044e property=0x138("_NET_WM_WINDOW_TYPE") type=0x4("ATOM") data=0x18d("_NET_WM_WINDOW_TYPE_TOOLBAR");
002:<:138d: 16: Request(12): ConfigureWindow window=0x0460044e values={stack-mode=Above(0x00)}
002:<:138e: 60: Request(18): ChangeProperty mode=Replace(0x00) window=0x0460044e property=0x23("WM_HINTS") type=0x23("WM_HINTS") data=0x00000067,0x00000000,0x00000001,0x04600105,0x00000000,0x00000000,0x00000000,0x04600106,0x04600001;
002:<:138f: 12: Request(19): DeleteProperty window=0x0460044e property=0x12c("_NET_WM_STATE")
004:>:0081: Event PropertyNotify(28) window=0x0460044e atom=0x28("WM_NORMAL_HINTS") time=0x0612ed8e state=NewValue(0x00)
002:<:1390: 12: Request(19): DeleteProperty window=0x0460044e property=0x126("_NET_WM_DESKTOP")
002:>:1390: Event PropertyNotify(28) window=0x0460044e atom=0x28("WM_NORMAL_HINTS") time=0x0612ed8e state=NewValue(0x00)
004:>:0081: Event PropertyNotify(28) window=0x0460044e atom=0x138("_NET_WM_WINDOW_TYPE") time=0x0612ed8e state=NewValue(0x00)
002:>:1390: Event PropertyNotify(28) window=0x0460044e atom=0x138("_NET_WM_WINDOW_TYPE") time=0x0612ed8e state=NewValue(0x00)
002:<:1391:  8: Request(8): MapWindow window=0x0460044e
002:<:1392: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x04600003 property=0x297("SAL_GETTIMEEVENT") type=0x297("SAL_GETTIMEEVENT") data=0x00;
002:>:1392: Event ConfigureNotify(22) event=0x0460044e window=0x0460044e above-sibling=0x0460044b x=772 y=786 width=371 height=70 border-width=0 override-redirect=false(0x00)
004:>:0081: Event PropertyNotify(28) window=0x0460044e atom=0x23("WM_HINTS") time=0x0612ed8e state=NewValue(0x00)
002:<:1393: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00000158 event-mask=SubstructureNotify,SubstructureRedirect ClientMessage(33) format=0x20 window=0x0460044e type=0x121("_NET_ACTIVE_WINDOW") data=0x01,0x00,0x00,0x00,0x8d,0xed,0x12,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
002:>:1393: Event PropertyNotify(28) window=0x0460044e atom=0x23("WM_HINTS") time=0x0612ed8e state=NewValue(0x00)
002:<:1394: 12: Request(42): SetInputFocus revert-to=Parent(0x02) focus=0x0460044e time=CurrentTime(0x00000000)
002:<:1395:  8: Request(38): QueryPointer window=0x00000158

002:>:1395: Event PropertyNotify(28) window=0x04600003 atom=0x297("SAL_GETTIMEEVENT") time=0x0612ed8e state=NewValue(0x00)
002:>:1394:Error 8=Match: major=42, minor=0, bad=73401422
Comment 27 Michael Meeks 2012-04-19 06:04:22 UTC
Looks like the XSetInputFocus call (causing the error):

002:<:1394: 12: Request(42): SetInputFocus revert-to=Parent(0x02)
focus=0x0460044e time=CurrentTime(0x00000000)
...
002:>:1394:Error 8=Match: major=42, minor=0, bad=73401422

is this one:

Breakpoint 1, XSetInputFocus (dpy=0x80ff600, focus=75498915, revert_to=2, time=0) at SetIFocus.c:38
38	SetIFocus.c: No such file or directory.
	in SetIFocus.c
(gdb) bt
#0  XSetInputFocus (dpy=0x80ff600, focus=75498915, revert_to=2, time=0) at SetIFocus.c:38
#1  0xb23536ac in ToTop (nFlags=12, this=0x8f767a8) at /home/opt/libreoffice/master/vcl/unx/gtk/window/gtkframe.cxx:2233
#2  GtkSalFrame::ToTop (this=0x8f767a8, nFlags=12) at /home/opt/libreoffice/master/vcl/unx/gtk/window/gtkframe.cxx:2206
#3  0xb5374a0b in Window::ImplGrabFocus (this=0x8f6f880, nFlags=0) at /home/opt/libreoffice/master/vcl/source/window/window.cxx:3986
#4  0xb5374d36 in Window::GrabFocus (this=0x8f6f880) at /home/opt/libreoffice/master/vcl/source/window/window.cxx:7476
#5  0xb6ddf6c9 in svx::FindbarDispatcher::dispatch (this=0x8f6be20, aURL=...)
    at /home/opt/libreoffice/master/svx/source/tbxctrls/tbunosearchcontrollers.cxx:730
#6  0xb6c9bc3b in svt::AsyncAccelExec::impl_ts_asyncCallback (this=0x8f6bd60)
    at /home/opt/libreoffice/master/svtools/source/misc/acceleratorexecute.cxx:501
#7  0xb530675c in Call (pCaller=0x0, this=0x8f6bd64) at /home/opt/libreoffice/master/solver/unxlngi6.pro/inc/tools/link.hxx:143
#8  DoEvent_Impl (pEvent=0x0, this=0x8f6bd60) at /home/opt/libreoffice/master/vcl/source/helper/evntpost.cxx:59
#9  vcl::EventPoster::LinkStubDoEvent_Impl (pThis=0x8f6bd60, pCaller=0x0) at /home/opt/libreoffice/master/vcl/source/helper/evntpost.cxx:62
#10 0xb5380fb1 in Call (pCaller=<optimized out>, this=<optimized out>)
    at /home/opt/libreoffice/master/solver/unxlngi6.pro/inc/tools/link.hxx:143
#11 ImplHandleUserEvent (pSVEvent=0x8f6a7a8) at /home/opt/libreoffice/master/vcl/source/window/winproc.cxx:1991
#12 ImplWindowFrameProc (pWindow=0x87bd110, nEvent=22, pEvent=0x8f6a7a8) at /home/opt/libreoffice/master/vcl/source/window/winproc.cxx:2563
#13 0xb5387aea in CallCallback (pEvent=0x8f6a7a8, nEvent=22, this=0x87bd388) at /home/opt/libreoffice/master/vcl/inc/salframe.hxx:281
#14 SalGenericDisplay::DispatchInternalEvent (this=0x80ee160) at /home/opt/libreoffice/master/vcl/generic/app/gendisp.cxx:102
#15 0xb23463bd in GtkData::userEventFn (data=0x80eb5f0) at /home/opt/libreoffice/master/vcl/unx/gtk/app/gtkdata.cxx:942
#16 0xb234641c in call_userEventFn (data=0x80eb5f0) at /home/opt/libreoffice/master/vcl/unx/gtk/app/gtkdata.cxx:952
#17 0xb1a9ad10 in g_idle_dispatch (source=0x8f6ccc0, callback=0xb23463f0 <call_userEventFn(void*)>, user_data=0x80eb5f0) at gmain.c:4785

*but* - it is surrounded by the error trap push/pop:

unx/gtk/window/gtkframe.cxx-                GetGenericData()->ErrorTrapPush();
unx/gtk/window/gtkframe.cxx-                XSetInputFocus( getDisplay()->GetDisplay(), widget_get_xid(m_pWindow), RevertToParent, CurrentTime );
unx/gtk/window/gtkframe.cxx:                GetGenericData()->ErrorTrapPop();

Possibly we are missing an XSync in there ...
Comment 28 Not Assigned 2012-04-19 06:36:30 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d97ea37bba52b21648c91276bc9281d06cdd148

fdo#46687 - fix find toolbar X error handling
Comment 29 Michael Meeks 2012-04-19 06:41:30 UTC
sent to ML for review for libreoffice-3-5 and -3-5-3.
Comment 30 Not Assigned 2012-04-19 14:58:14 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9eed733f85e8003696271e63a3fcfc660511b7ef&g=libreoffice-3-5

fdo#46687 - fix find toolbar X error handling


It will be available in LibreOffice 3.5.4.
Comment 31 sasha.libreoffice 2012-04-19 22:02:51 UTC
Thanks for fixing!
Comment 32 Andras Timar 2012-04-23 07:09:35 UTC
*** Bug 49077 has been marked as a duplicate of this bug. ***
Comment 33 Not Assigned 2012-04-23 08:31:08 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=348cd8a0feb871f5b7f2e558f118cdece7132d3d&g=libreoffice-3-5-3

fdo#46687 - fix find toolbar X error handling


It will be available already in LibreOffice 3.5.3.