Apache OpenOffice (AOO) Bugzilla – Issue 102735
Crash when typing (plugin causes OOo to crash)
Last modified: 2017-05-20 10:29:03 UTC
Seems strange to me that this bug isn't reported by now. It is simple: Open Calc or writer Type a letter -> crash This bug exists since DEV300m48 and is still in DEV300m50 As it seems noone reported it by now it may depend on the used OS or some other detail of my computer. I'm using OS X 10.4.11 Tiger on a iMac 20" 2.16 GHz. Maybe it has something to do with my two monitors. This error is not occurring in the 3.1 line of snapshots (OOO310mXX)
To give an idea what happened, here the part of soffice.crash.log which I hope is the relevant part: ********** Host Name: Schwan Date/Time: 2009-06-13 15:24:50.708 +0200 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: soffice Path: /Users/tag/Desktop/OpenOffice.org.app/Contents/MacOS/soffice Parent: WindowServer [96] Version: 3.2.0 (???) PID: 28920 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x1e2b4020 Thread 0 Crashed: 0 libobjc.A.dylib 0x90a59654 _class_lookupMethodAndLoadCache + 284 1 libobjc.A.dylib 0x90a59506 objc_msgSend + 86 2 com.apple.AppKit 0x93373990 -[NSEvent _initWithCGSEvent:eventRef:] + 152 3 com.apple.AppKit 0x932a6c0c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 350 4 libvclmxi.dylib 0x01ed093c component_getFactory + 148668 5 libvclmxi.dylib 0x01c8849d Application::Yield(bool) + 83 6 libvclmxi.dylib 0x01c8851f Application::Execute() + 63 7 libsofficeapp.dylib 0x000898da 0x74000 + 88282 8 libvclmxi.dylib 0x01c8e103 DeInitVCL() + 2689 9 libvclmxi.dylib 0x01ecfe52 component_getFactory + 145874 10 libvclmxi.dylib 0x01ed3146 SalGetDesktopEnvironment() + 9892 11 com.apple.AppKit 0x932a08e7 -[NSApplication run] + 547 12 com.apple.AppKit 0x93294820 NSApplicationMain + 573 13 libvclmxi.dylib 0x01ed0dac SalGetDesktopEnvironment() + 778 14 libvclmxi.dylib 0x01c8e18f SVMain() + 17 15 libsofficeapp.dylib 0x000b2cbe soffice_main + 160 16 org.openoffice.script 0x00002b76 main + 30 17 org.openoffice.script 0x000024e6 start + 258 18 org.openoffice.script 0x0000240d start + 41
*** Issue 102753 has been marked as a duplicate of this issue. ***
I have the same Problem Me and rbircher to cc
Created attachment 62976 [details] first crashreport from it
Created attachment 62977 [details] second crashreport from it
I test follow things: - OOo new installation - delete OOo-Profile-Directory - with a new User Account - with Build from ftp://ooopackages.good-day.net/pub/OpenOffice.org/MacOSX/Dev_DEV300_m50/
not reproducible on PPC (Mac OS X 10.4.11) Please check with the Sun-provided build from here: ftp://ftp.snt.utwente.nl/pub/software/openoffice/extended/developer/DEV300_m50/ (Sun's build has OOo's crash-reporter, that generates stacks/reports that are more useful for OOo-developers. Send the report and then post the report-ID that is sent via email as confirmation)
@cloph: My first tests was with the Builds from SUN. But the CrashReporter did not come!
gdb-output (both builds): Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x265e5020 0x97344210 in _class_getMethodNoSuper ()
Forwarding issue to PL, P1 is justified because the application is practically unusable.
For a P1 crash it seems awfully hard too reproduce, in fact so hard that I couldn't either in 10.4 or 10.5.
I now had a look at it myself and am unable to reproduce the problem either. Reducing priority, needhelp.
Unable to reproduce in m48 or m50.
Infos about this bug: Martin Hagman (alias torwart) found this bug and report it in issue 102753, no one from the QA Weekend was able to reproduce it. four Apple was there. Then, Martin found this bug, so we have a problem with two computers. This bug is realy hard to reproduce. My proposal: We wait to m51 and if we have the same problem, we ask other people for help
I can reliably reproduce it. Crash when typing in writer or calc. 3.2.0[300m50(Build:9406)] Greetings, herrdeh
If the issue was reproduced on a CrashReporter-enabled build then there are probably "reportids". Please provide them if available. Without the reportids it is much more difficult. The crashlogs already provided mention JVM threads a lot. It would be interesting to know if the problem has to do anything with the Java integration or with a Java based plugin. Please try to reproduce it with Java support disabled (OpenOffice->Preferences->Java) and/or with all plugins disabled.
For all who have the crash Go to OOO > Performance > Java uncheck Java start DEV300_m50, open writer, and type samething report if OOo Crashs or not, thanks
I test today without active Java. OOo always still Crash.
German m51, Java disabled. Crash in Writer still occurs.
Thanks for checking with m51 with disabled Java. Did the crashreporter work this time? What are the reportids then?
Used sun build for testing (seldom used account, settings unchanged). Some more results I had before this try to send report: - Pasting Clipboard using only the mouse works fine - Opening some menu entries (like Edit/Object, the last one - but there are more) also crashes, not only typing - Typing in preferences crashes too No idea how to get the report ID. On next start of OOo Document recovery -> next, there appears something that a crash report was sent -> next should be some crash reporter tool according to the dialog text before next, but all that appears is an empty writer document (obviously the recovered one). I sent 3 reports, but at the first two I canceled document recovery. In the comment there is always the text http://www.openoffice.org/issues/show_bug.cgi?id=102735 (the URL of this bug) contained. Does this help? One more thing to mention: After the crash there is some thread of OOo still running. I have to use "Sofort beenden" from the context menu of the dock.
So the crashreporter somewhat works, good. > In the comment there is always the text http://www.openoffice.org/issues/show_bug.cgi?id=102735 > (the URL of this bug) contained. Does this help? The crash report tooling doesn't support searching for the submitted summary or comment. I could search for the submitter mail address though. Where they sent from "gantim@xxx"? I didn't find these either. Since the number of crashes for m51 are still finite I looked through all of them, but there were only generic Writer problems. The extra thread running makes me suspicious that there may be extensions involved here. Are any of them active? Please disable or remove them one by one by using the menu Tools->Extensions
I test now with m51 SUN-Build. The problem is always still here. I've found an other Problem in the connection with this issue: if I open the Preferences per Click "OOo-DEV" -> "Preferences..." I have no Problem. But if I open it per put Control + , OOo Freeze! @gantim have you the same problem?
I tested some other things: - Modul Writer normal: Freeze - Modul Calc: Freeze - Modul Impress: Freeze - Modul Draw with a textfield: Freeze - Modul Writer with a Master Document: Freeze - Modul Writer with a HTML DOcument: Freeze - Modul Base with a new Database and a new Table: no Crash or Freeze - Modul Math: no Crash or Freeze I attache still the Hardware page of the Crash Report.
Created attachment 63386 [details] Hardware-Page from MAC OS X CrashReporter
Problem with crashreporter is that it crashes if you type. Probably this prevented previous reports from being sent. Using Textedit and pasting text with the mouse is possible. Reports ryrr4kc and rpvr4kc are two of my crashes.
There's another one without touching the keyboard: Just opened some menus using the mouse, then opened submenu Insert/Object in Writer. Without clicking anything in that menu: Crash! Report ID rmk44kc.
@gantim: Thank you very much for the reportids! Since the POS-tooling doesn't work today I analyzed them manually. It looks like a specific NSMenu event is not handled at all. The crash-reporter doesn't send not enough data to identify which message that would be. There is a trick to get this info though: If an application was started from the command line OSX usually prints the details about a failed message to stderr. So here is the next quest for all users that are affected by the problem: - open the Terminal application - go into the OpenOffice.org.app directory (use the "cd" command to change the directory) - type "./Contents/MacOS/soffice.bin -writer" into the terminal then press enter - make it crash with typing => in the terminal there should be some details about the crash, please provide them here
That way this bug can't be reproduced. Starting OOo from the terminal as you recommended no key presses appear in the OOo window. Whatever had the focus before clicking into OOo window gets the key events. There is no menu, so the submenu crash also can't be generated. Opening documents, selecting and pasting clipboard works fine. Have to end the program after closing the window using Ctrl-C. But no crash as I can't type ... Thought about writing some AppleScript that sends key presses, but am not sure if that would help reproducing the crash. Do you have a better idea?
Starting the command line without the .bin the bug occurs. The output is as following: /Applications/OOo-dev.app/Contents/MacOS/../program/crash_report.bin -p 8508 -s 11 -xml /var/tmp//crxmlX0alI0 -chksum /var/tmp//crchkIWAR2y -stack /var/tmp//crstkAJr4ut -noui If the path is not /Applications but a path with space in it ("/Users/Shared/OOo m51 Absturztest") an additional line appears sh: line 1: /Users/Shared/OOo: No such file or directory
Added the specialist for keyboard-input and menu-handling to the CC list. @gantim: thanks for testing! The error you mentioned unfortunately doesn't tell which message Cocoa has problems with... Another idea: does it help to remove the application settings? (Just remove or rename the folder ~/Library/Application\ Support/OpenOffice.org* or wherever else the application settings are stored on your system)
rbircher > mru removing the user profile is allready done by torwart. see above. We will find out the CWS now. rbircher > gantim and torwart here is a DEV300_m47 from the Buildbot. The DMG is inside the Zip. Please test if you have a crash or not. http://buildbot.go-oo.org/install_sets/MacIntel-2987-DEV300_m47-install_set.zip
Can't test the DEV300_m47 - it crashes on start because of unresolved symbol: Link (dyld) error: Symbol not found: _NSDefaultRunLoopMode Referenced from: /Users/Shared/m47/OpenOffice.org.app/Contents/MacOS/../basis-link/program/libvclmxi.dylib Expected in: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation Assuming this can only be tested on Leopard 10.5 - unresolved symbols often are result of Tiger incompatibility. Can someone with 10.5 please test the m47 if it runs fine? Additional information: DEV300_m52 also crashes like m48-m51 on key press.
Are the buildbots building with an OSX10.5 SDK??? I'm not surprised that the results would crash on OSX 10.4 then. Please someone contact the OSX-buildbot-maintainer.
> Are the buildbots building with an OSX10.5 SDK??? Yes and no. The MacIntel buildbot runs with Mac OSX 10.5 and thus defaults to the 10.5 SDK (the link posted here was from the bot). Maho/Pavel build on Intel with 10.4, and thus default to 10.4 SDK. And as you see from the report: The problem is completely different. You cannot even launch a 10.5-built OOo. Please don't get distracted by that problem. The build was provided to further pin down the problem to a specific cws/code change. (bisecting the changes). As none of the "real" devs can reproduce, this should at least give a hint then. And as already stated (and obvious by the crash-report you received): People were also reproducing the crash with Sun-built OOo. > Please someone contact the OSX-buildbot-maintainer. I am notified, and since there is no way to just tell the build "Use the 10.4 sdk", I manually added -isysroot -Wl,-syslibroot switches to the corresponding places and did set MAC_OSX_DEPLOYMENT_TARGET to 10.4. python-stuff isn't working, but the rest runs OK on 10.5/the build machine at least. http://users2.ooodev.org/~cloph/OOo_m47_Leo_Tiger.dmg I cannot state this often enough: The problem is /NOT/ related to running "10.5 built OOo" on 10.4
so the found in version m48 is a red herring, it does occur in the m47 build as well. I built a m45 version, where even python works here (m45 is before the OOo-internal switch to python 2.6.1) http://users2.ooodev.org/~cloph/OOo_m45_Leo_Tiger.dmg
Very strange. m45 starts fine. Clicking on calc: Immediately crash. Opening writer, typing one (!) letter: works fine. Typing a second letter: Boom! Opening writer, simultaneously hacking on many keys: All chars appear fine. Wait a few seconds, type any key: crash. Crash on pure letters/numbers mostly, not on Shortcuts like Command-V, Shift-Cursor-left or similar. Never at the first letter, mostly the second, sometimes later. Crash is different: The tests before had some seconds "beachball", then crash while some thread remains, OOo has to be closed by kill. In m45 the first typed char needs two seconds. But the char which produces the crash does that immediately, and the OOo process doesn't stay. On a different computer (which probably isn't affected by this bug anyway) using 10.5 no crash occurs with m45. Don't assume the calc crash is related to the phenomenon of this task, suggest to ignore it. But the crash in writer probably is the same. Next test will be done with m43 (tested m41 which I still had somewhere, this works fine).
The last crash on m45 was the problem that some external dependency required 10.5 Leopard, but I'm using 10.4 Tiger. Buildbot was fixed to give 10.4 compatible output. The crash doesn't occur on a newly built m45 or previous, but since m46. Changed version of this issue to DEV300m46. (omitting details about which previous and successing versions were tested to find this out)
Thanks a lot for isolating it down to the DEV300_m45->m46 transition. This is very valuable. Looking through the reportids again and checking the diff between the two mentioned milestones I have another idea: Please disable all checkboxes in OpenOffice.org->Preferences->LangSettings- >WritingAids. If this helps please reenable them gradually until we found the culprit. Maybe the OpenOffice.org->Preferences->OOo->ImprovementProgram has something to do with it too. I suggest to keep it disabled for these tests.
Writing aids seem not to be the problem. Will do a check of improvement program in the evening. hdu, I recommend coordination with cloph before further analyzing (if you didn't already do so) e. g. in the chat. We are in the process of further isolating, finding the exact cws containing the problem (doing builds containing only some cws between m45 and m46), this shall optimize the time for finally finding the cause of the bug.
The cws that causes the bug is vcl100, tnx cloph for the builds to isolate it! I don't see any preferences regarding the improvement program. Where do I find it? Anyway, I think I always answered "No" if I got asked if I wish to participate (dunno if that happened on this computer).
further pinned down to the changes in module "extensions" in the vcl100 cws.
The changes in extensions do not get active until you open "Insert->Object" at which point the Netscape plugin service (libplmxi.dylib) library gets loaded to collect available plugins. Alternatively the service gets loaded when you open a document containg a plugin. However both do not quite match the bug description. However you can verify that it is the extensions code (or not) by moving the library from <office>/Contents/basis-link/program.
Well, that is what the testing did show. build without the changes in extensions → runs fine, switch extensions to vcl100 → crash. It was noted in previous comments to this issue that opening some menu-entries also triggers a crash in the office. Maybe it's the oooimprovement stuff that causes the code to be activated even when not explicitly inserting a plugin object. Anyway, I'll prepare a build with extensions built with debug=true, maybe that will show more useful info.
At least that would give us an explanation what MIGHT be different on our systems; it could now be that it crashes in a plugin hdu and I don't have. Because collecting the plugins indeed can cause them to be loaded.
Even when I cannot reproduce the crash, I can definitely say that the extensions are initialized/queried when typing the first letter, no need to actually use Insert|Object or to load a document with plugin. Test build: http://users2.ooodev.org/~cloph/OOo_vcl100_extensions_debug.dmg output on console: check path file://localhost/Users/cloph/Library/Internet%20Plug-Ins/ Trying path file://localhost/Users/cloph/Library/Internet%20Plug-Ins/ ... got 0 bundles check path file://localhost/Library/Internet%20Plug-Ins/ Trying path file://localhost/Library/Internet%20Plug-Ins/ ... got 6 bundles URL: file://localhost/Library/Internet%20Plug-Ins/Flash%20Player.plugin/ name: description: exec URL = file:///Library/Internet%20Plug-Ins/Flash%20Player.plugin/Contents/MacOS/Flash%20Player Inserting from resource: Mimetype: application/x-shockwave-flash [many lines snipped] ############# so whomever can reproduce the bug: Please attach the output of running the above build from a terminal and/or post the contents of your "~/Library/Internet Plug-Ins" and "/Library/Internet Plug-Ins" folders
Actually I'd also be interested in seeing why the plugins get loaded :-) . But I can debug that for myself.
Global plugin VLC 0.8.6d for Intel 2008-02-27 seems to cause it - removing it OOo doesn't crash anymore.
probably an "upstream" bug then - google find lots of hits wrt crashes with the vlc browser plugin, like for example https://trac.videolan.org/vlc/ticket/908 or https://bugs.launchpad.net/firefox/+bug/117640 But OOo should be more robust and shouldn't crash when a plugin crashes.
I can confirm it too. If I delete the file from the VLC-Plugin, start my OOo m51 an write any sentences without a crash. But it's right, what cloph said, OOo shouldn't crash when a plugin crash. Can someone say me, why a OOO310m14 didn't Crash with installed Plugin?
I have test another thing: I installed the current Version of the Plugin from http://www.videolan.org/mirror-geo.php?file=vlc/1.0.0/macosx/vlc-plugin-1.0.0-intel.dmg, then I start OOo m52, open an new writer-document and write many words without a Crash. I test some Hotkeys too. Also here no crash.
The VLC plugin crash was fixed in 1.0.0RC2 according to https://bugs.launchpad.net/firefox/+bug/117640/comments/12. VLC after 0.9.9a isn't supporting 10.4 Tiger anymore, 0.8.6i which is the newest compiled VLC plugin suitable for Tiger. Think it is not necessary to test it as now we know if there's this crash appearing where it comes from (don't need the plugin myself). Just to keep in mind: People running Tiger wanting the VLC plugin can't use the fixed version.
Great find, thanks a lot for your efforts. What I don't understand is that the VLC library isn't anywhere near the stacks for the CrashReportids (ryrr4kc, rpvr4kc and rmk44kc) or in the attached files crash_001.txt or crash_002.txt. Not even the library itself is mentioned as being loaded (the Quicktime plugin from crash_00*.txt is related though). Our crashreporter has quite some issues when it ignores the plugins...
Yes, thank you very much for that arduous effort. As for why m14 doesn't crash: plugin support came in new with vcl100. What can be fixed is probably that plugins get loaded just when typing, however OOo cannot really protect itself against a crashing plugin library any more than against a crahsing system library (or on of its own dylibs crashing for that matter).
committed a patch that vlc plugin < 1.0 will be rejected (we need that anyway since crashing with it even if later at insert->objects->plugin should be avoided). As for the "at first character" thing: this is a mac specialty actually. Cocoa initializes the native menus at the first key press (makes sense, could be a shortcut). That in turn queries the whole menu hierarchy to be populated, including Insert->Object->Movie and Insert->object->sound. These however get disabled - among other reasons - when there is no plugin available that could play move/sound. My question for cd and mba: couldn't we just leave these menu entries enabled ?
Yes, you can remove that.
cd: Yes, please remove the check from the GetState() method.
after talking to the application leads I have committed a patch removing the check for available sound/movie plugins also; the correspoding menu entries are now always enabled same as insert->"movie and sound" (which is a separate entry and uses a different service to achieve the same effect). fixed in CWS vcl104
*** Issue 103674 has been marked as a duplicate of this issue. ***
please verify in CWS vcl104
Verified with cws vcl104 = ok