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
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 ---
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.
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
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.
reproduced in Gnome 3 on Fedora 64 bit
(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.
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.
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.
Created attachment 57951 [details] Backtrace (master) - improved Also, for the record I am on Ubuntu 10.04, Gnome
(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
*** Bug 46965 has been marked as a duplicate of this bug. ***
(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.
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)
*** Bug 45579 has been marked as a duplicate of this bug. ***
(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.)
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 ?
Confirmed on Ubuntu 12.04 32Bit. So its not a 64Bit specific issue. The floating is essential though.
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
CCing Michael Meeks too -- in that range there are 34 commits by Michael touching vcl/unx/gtk.
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
HOLY CRAP! Now that's a major bug. As you know, this doesn't happen with the QT build.
Changed whiteboard, according to the wiki
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 :-)
*** Bug 48641 has been marked as a duplicate of this bug. ***
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.
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
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 ...
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
sent to ML for review for libreoffice-3-5 and -3-5-3.
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.
Thanks for fixing!
*** Bug 49077 has been marked as a duplicate of this bug. ***
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.