Blocking upper case text and selecting change to lower case causes beta 4 to crash.
how are you changing the case? from the 'Format | Change case' menu or some key combination or ...? does it happen with an existing document ? or will it happen if you just type a word in a blank doc and change the case is it possible to provide a stack trace ( not even sure how one gets one of those on mac ) please provide some more details to help us
I reported the bug as it related to an "old" document (been saved through a succession of formats over long time) that had a sentence with upper case text. I needed to change it to lower case. I selected the text then via the main menu selected Format - Change Case - lower-case. LO 3.4 beta4 would crash immediately without any sign of case change on screen. I have since created a new odt document and attempted, using same the procedure, to convert a selected block of text to upper case (ie the opposite to before). LO immediately showed spinning wheel (wait) then, after a few seconds, crashed. Seems it is easily reproduced.
Couldn't reproduce problem on Win XP Pro (32 bit) PC so may be Mac OS X specific.
I'm using version 3.3.3 on OS X Lion and I'm having this problem. I'm having this problem. What's odd is that there are times it shows up all the time and I can't work on my screenplays comfortably because of it, and other times it's not a problem. I can usually duplicate this. If there are steps I can do that will help trace this, please let me know because this bug is bad enough for me that I can't use LibreOffice when it's doing this. If I can help fix it, I'll be glad to, since I really need this to work.
Created attachment 52322 [details] OS X Problem Report This is the regular OS X "Problem Report" from trying to change case on OS X (Lion). I highlighted lowercase text then first experimented and tried selecting "Change to Lowercase" from the LO menu. No problems. Then I tried to change it to uppercase and LO crashed.
I apologize for so many comments -- just remember I'm posting this at 5 am and I've been working all night. This is all on OS X Lion. I found this crashed LO on my computer whenever I tried to change to a different case. If I changed lowercase to lowercase, there was no problem. But if I have even one upper case character and the rest lowercase and try to change to lowercase, it crashes. If I have lowercase and try to change to uppercase, it crashes. This was happening on version 3.3.3. I couldn't remember how I had gotten it to work early in the summer. Just in case, I downloaded 3.4.3 and tried it. It still crashed. Then I remembered that when this happened before, I changed back to an earlier version. So I looked in my folders and found an earlier download of LibreOffice, version 3.4.0 (odd it's a higher number than the 3.3.3 that crashes) and installed that over the most recent version I had installed (3.4.3). This means when using 3.4.0 (OOO340m1 Build 12 it works just fine. That particular version was one I downloaded on June 13, 2011 and the newer version that crashed (3.3.3) was downloaded on August 8, 2011 (and 3.4.3 was just downloaded on October 14, 2011). I hope this helps to narrow down when changes were made and, along with the Problem Report I uploaded, gives someone enough to pinpoint this problem. I would think the fix can't be too complex, especially since it shouldn't be hard to backtrack the changes made between versions. If I can help with testing, please let me know.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Happening for all betas, RCs and now final release on OSX 10.6.8 Wasn't critical for a beta, but it is for a final release.
*** Bug 44468 has been marked as a duplicate of this bug. ***
OK, it is getting a litte bit difficult: ) I made a list, refering to the comments -Working- 3.4.0 3.4.1 LOdev 3.5.0 Build ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4 (b1) -Not working- 3.4 b4 3.3.3 3.4.3 3.4.5 3.5 b3 3.5 rc1 3.5 rc3 (final) 3.4.2 Feel free to continue this list. I am going to search after duplicates... IMHO Regression between 3.4.1 and 3.4.2 or 3.5.0b1 and 3.5.0b4
*** Bug 38957 has been marked as a duplicate of this bug. ***
*** Bug 49308 has been marked as a duplicate of this bug. ***
caolanm->mstahl: I can't reproduce this. The MacOSX backtrace gives an intriguing SwUndoTransliterate::AddChanges which might mean something to you ? If not, my test case is simply... blank writer document, "A test is hello" right click on hello and use, change case->UPPERCASE, change case->lowercase. This doesn't crash for me on x86_64 Linux any version that I have Is there is an alternative sure-fire route to reproduce this crash ?
Using: LibreOffice 3.3.3 OOO330m19 (Build:301) tag libreoffice-3.3.3.1 MAC OS 10.6.8 on MacBook. Problem does not seem to occur anymore. I created a new document, did the Format | Change Case and could flip the text to all the options, and reverse. Then loaded an old document, and could randomly change blocks between lower and upper case without issues. Seems the issue I have previously seen (and others) of a crash seems to have gone away.
LO 3.5.2.2/OS X 10.6.8 crashes using any choice under Format/Change Case, including Hiragana/Katakana and Full-width/Half-width, with Asian language option enabled, from a fresh document or an existing document.
I'm running Snow Leopard, so this problem isn't unique to Lion. However, I've been unable to reproduce it since I rebooted my computer a couple of days ago. Just quitting/restarting LibreOffice didn't fix the problem. Is there a way to retrieve the error report that was sent to Apple (sorry, I'm a newbie to bug reporting)? If so, I can post that here.
*** Bug 49455 has been marked as a duplicate of this bug. ***
It's just happened again. Here's (I think) the relevant portion of the error report: Process: soffice [1016] Path: /Applications/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 3.5.2 (???) Code Type: X86 (Native) Parent Process: launchd [118] Date/Time: 2012-05-09 21:04:56.571 -0700 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: -7701968 sec Crashes Since Last Report: -9 Per-App Interval Since Last Report: -72633 sec Per-App Crashes Since Last Report: 1 Anonymous UUID: xxxxxx Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000970c2c52 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libuno_sal.dylib.3 0x0000b710 osl_incrementInterlockedCount + 48 1 libtllo.dylib 0x013c73f4 String::String(String const&) + 20 2 libeditenglo.dylib 0x2969a6dc std::vector<TransliterationChgData, std::allocator<TransliterationChgData> >::_M_insert_aux(__gnu_cxx::__normal_iterator<TransliterationChgData*, std::vector<TransliterationChgData, std::allocator<TransliterationChgData> > >, TransliterationChgData const&) + 1004 3 libswlo.dylib 0x29f5c93e SwTxtNode::TransliterateText(utl::TransliterationWrapper&, unsigned short, unsigned short, SwUndoTransliterate*) + 4478 4 libswlo.dylib 0x29c6a41c SwDoc::TransliterateText(SwPaM const&, utl::TransliterationWrapper&) + 652 5 libswlo.dylib 0x29d64345 SwEditShell::TransliterateText(unsigned long) + 341 6 libsfxlo.dylib 0x00489422 SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned char) + 530 7 libsfxlo.dylib 0x0048b7b4 SfxDispatcher::PostMsgHandler(SfxRequest*) + 308 8 libsfxlo.dylib 0x0064f639 SfxHintPoster::LinkStubDoEvent_Impl(void*, void*) + 25 9 libvcllo.dylib 0x018ecf9f ImplWindowFrameProc(Window*, SalFrame*, unsigned short, void const*) + 5583 10 libvcllo.dylib 0x018f7213 AquaSalInstance::Yield(bool, bool) + 323 11 libvcllo.dylib 0x0161ef00 Application::Yield(bool) + 96 12 libvcllo.dylib 0x0161efec Application::Execute() + 76 13 libsofficeapp.dylib 0x0006bd5d desktop::Desktop::Main() + 6317 14 libvcllo.dylib 0x01626bb8 ImplSVMain() + 376 15 libvcllo.dylib 0x018f61db AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 75 16 libvcllo.dylib 0x0193a50b -[VCL_NSApplication sendEvent:] + 315 17 com.apple.AppKit 0x989d0253 -[NSApplication run] + 917 18 com.apple.AppKit 0x989c8289 NSApplicationMain + 574 19 libvcllo.dylib 0x018f7b87 ImplSVMainHook(int*) + 343 20 libvcllo.dylib 0x01626c61 SVMain() + 17 21 libsofficeapp.dylib 0x00095575 soffice_main + 245 22 org.libreoffice.script 0x00001f0e main + 30 23 org.libreoffice.script 0x00001872 _start + 216 24 org.libreoffice.script 0x00001799 start + 41
aaaah!, we have *two* structs called TransliterationChgData with different layouts, I bet the wrong one is getting used on MacOSX given the presence of the crash in editeng where the duplicate named TransliterationChgData lives caolanm->juliemiller: Excellent, I think that's the magic piece of missing information.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7080d629c82422a419d38051536c7711f8abe53e Resolves: fdo#37044 two different TransliterationChgData structs
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=414152c1ed10ec01b6ea385960c53304e4ec95cc&g=libreoffice-3-5 Resolves: fdo#37044 two different TransliterationChgData structs It will be available in LibreOffice 3.5.4.
Changed the Version field back to '3.3.3 release'. Please note that the Version field should contain the FIRST version which is known to contain the bug, and not the last one ...
excellent, and thanks! I'm looking forward to this never happening again. (In reply to comment #21) > aaaah!, we have *two* structs called TransliterationChgData with different > layouts, I bet the wrong one is getting used on MacOSX given the presence of > the crash in editeng where the duplicate named TransliterationChgData lives > > caolanm->juliemiller: Excellent, I think that's the magic piece of missing > information.
*** Bug 50287 has been marked as a duplicate of this bug. ***
*** Bug 47317 has been marked as a duplicate of this bug. ***
Just a hint: in between, our AOO friends have found the same bug and fixed it, too; see "Bug 120045 - Format case change crashes OOo" <https://issues.apache.org/ooo/show_bug.cgi?id=120045> Verified: Doing some tests with simple case-conversion cases, I can confirm that this bug does neither appear in LibreOffice 3.5.4.2 nor in 3.6beta2 anymore. Therefore promoted Status to VERIFIED/FIXED.