Description of problem: At the time the crash occurred, I was holding Shift-Ctrl-> to highlight text one word at a time. My document contained only standard formatting elements, like Heading styles and bullet points. Version-Release number of selected component (if applicable): openoffice.org-2.4.1-17.4.fc9 How reproducible: Not easily. I can't offer definitive steps. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: I have noticed this behaviour on x86_64 OOo before. I reinstalled F9 but the 32 bit version, and seemed to have no problems. Since installing 64-bit again, this crash occurs in writer. Trace dump is attached.
Created attachment 312023 [details] Stack report
Created attachment 312033 [details] mapped stack
The pattern fits some unsigned long event getting mangled through an unsigned int type, but I don't see anything immediately wrong in the backtrace locations, and that particular keystroke doesn't blow up OOo for me yet.
I don't suppose you happened upon a reproducible mechanism to get this crash ?
Not yet, I'm afraid. Leave it with me a couple more days and I'll try to hammer it into submission :)
Created attachment 313104 [details] Stack trace dumped by OOo when writer crashed.
Regarding the attachment (id 313104) - I managed to get a second crash. While editing text, I deleted a small block (a few words) in one bullet point and used "del"[ete] keye to bring up the following line to adjoin the end of this line. Then it crashed. It seems to crash when I'm working quickly. Possibly mouse pointer interaction has something to do with this. Is it possible that some problem with the radeon.so driver could be causing this?
I don't suppose that whacking any of the *other* keys around your delete key reproduces this, i.e. occasional misses :-) I can't reproduce, but at least I see one suspicious little thing in the vicinity.
Oh yeah, it's ENTIRELY possible that I hit an adjacent key instead of the key I intended to hit. :) On my laptop keyboard, the DELETE key is top right corner. INSERT / [prt scr] is immediately left of it and HOME is south of it. As the behaviour I observed was my text being deleted, the only plausible key (mis-)press would be INSERT. ( [prt scr] above just indicates the key's mode if the function key is also depressed. ) Is there anything further I can do to replicate this? E.g. certain key presses?
Created attachment 313168 [details] replcement .so Make sure to backup your old version of this file from /usr/lib64/openoffice.org/program to somewhere safe, and stick this one in there instead
My expectation that this will *fix* OOo is pretty much nil, but it might. It might also give a different crash trace that might help me figure this out.
Created attachment 313194 [details] Trace dump after using new library file. Ok, I hate to disappoint you, but it didn't fix it. However, I observed slightly different behaviour this time round. I started up writer, created a new document and started typing the first paragraph. As before, I'd created two lines (heading on the first line, this time), and used DEL[ete] to bring up the line below it. However, it didn't crash here. I then held down CRTL while tapping Cursor-Right to move the cursor one word at a time. There was a momentary pause when I did this - I thought it was going to crash. But no. (Perhaps this is the crash twice bit you mentioned?) Then, holding down CTRL, I also held down Shift and hit Cursor-Right to select, one word at a time, a few words. Then it fell over.
Created attachment 313261 [details] Stack trace This one happened when I hit ENTER twice to create a second paragraph. The document otherwise only contained one paragraph, with a few hyperlinks sprinkled in my text and nothing else.
Created attachment 313262 [details] Another trace when using Ctrl-Shift-Left .. and this one was when selecting some text using my favourite Ctrl-Shift-Left arrow technique. :(
Is there anything further I can do to help solve this? Happy to experiment with new libraries or whatever... :)
Created attachment 315730 [details] another replacement .so Well, this replacement .so is worth a shot to better identify the problem. Afterwards if you run writer from a console it should print out at the start and end of each command triggered by a keystroke combo. So if it crashes then we should know what the last run command was, and the exception catching stuff has been disabled, so the crash report should report where the crash took place, rather than where the exception was caught and then crashed, which wasn't as useful
Although I haven't reproduced the bug, but I'll show my step here. The system info: Fedora 9 kernel 2.6.25.14-108.fc9.x86_64 on an x86_64 openoffice: openoffice.org-2.4.1-17.4.fc9.x86_64 The step: 1.start up the writer via the Terminal,typing the oowriter. 2.typed two lines of words and also the bullet points there , and made the first line the Heading font type. 3.hold the Ctrl+Shift+ -> to highlight the words one by one.(I repeated this step for many times, but nothing happened) 4.just hold the Shift + -> to highlight the words one letter by one letter ,nothing happened. 5.just hold the Ctrl + -> to move among the words one by one, nothing ,either. 6.hold the Ctrl+Shift,and press the keys around the cursors ,such as the Del[ete],the PageDown,PageUp,Insert,RightCtrl,RightShift,Enter,End,Home,and also the PrtScrSysRq.When I changed the key from one to another fast, there was a pause, I thought it was the crash , but no. So,I wondered whether it is a problem caused by the Memory,whether it is a problem caused by the Memory addressability？
After update the openoffice to the latest version openoffice 2.4.1-17.6.fc9.x86_64 ,I did the reproduce again , and have found nothing .
caolanm->steve.dowe: Re Comment #16, did you ever get a chance to try out that replacement debugging library to see if it would print out a hint as to the name of the command which was last triggered from the keyboard was before a crash ?
Sorry, but due to productivity requirements I needed to install a vanilla 32-bit OOo instead. But I still intend to try out the new library and get back to you on this. Will have to test via a VM instead now.
ok, lets forget about it and hope that its good in F-10