My Computer is an intel core i3 iMac with 4GB of memory. I've installed Libreoffice version 3.3.2 and have created two separate but identical, both in schema and data, databases. One was created with Libreoffice as a standard .ODB database. The other database was created with a MySQL front end product and remains on a local MySQL server. Using Libreoffice Database entry, I connected to the MySql database using com.mysql.jdbc.Driver. The Java driver version was java-5-1-16 and the Java runtime provided by Apple Inc. was version 1.6.0-24. In both the standard .ODB database and the MySql Java connected database, the tables with their respected data appear to be correct; however using a simple query, a form with only an initial object or even after displaying a simple view, Libreoffice quits unexpectedly with the following problem details: Process: soffice [575] Path: /Applications/DataBases/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 3.3.2 (???) Code Type: X86 (Native) Parent Process: launchd [224] Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Help would be greatly appreciated. xZaytoun@sbcglobal.net
Hi, Which version of Mac OSX ? 10.5.8, 10.6.7 ??? Have you tried renaming your /Users/myuser/Library/Application Support/LibreOffice folder to LOBCKP and then restarting LibreOffice ? In earlier versions, updates from one version to the next (e.g. 3.3.1 to 3.3.2, or 3.3.2 betas through to release candidate and final) sometimes screwed up the user settings in this folder and cause LibO to become unstable. I don't have the stability issues you have indicated. My system : Mac OSX 10.6.7 LibreOffice 3.3.2 HSQLDB (native LibreOffice ODB) Mysql (front end ODB using mysql C++ connector extension) Mysql (front end ODB using mysql JDBC connector) The only major problems I have found with db connectivity is with ODBC (which doesn't work, but then it doesn't on OpenOffice.org either). As for queries, most of mine are simple, but involve the use of the CAST function and DATE calculations and they work fine. Alex
(In reply to comment #1) > Hi, > > Which version of Mac OSX ? 10.5.8, 10.6.7 ??? > > Have you tried renaming your /Users/myuser/Library/Application > Support/LibreOffice folder to LOBCKP and then restarting LibreOffice ? In > earlier versions, updates from one version to the next (e.g. 3.3.1 to 3.3.2, or > 3.3.2 betas through to release candidate and final) sometimes screwed up the > user settings in this folder and cause LibO to become unstable. > > I don't have the stability issues you have indicated. My system : > > Mac OSX 10.6.7 > LibreOffice 3.3.2 > HSQLDB (native LibreOffice ODB) > Mysql (front end ODB using mysql C++ connector extension) > Mysql (front end ODB using mysql JDBC connector) > > > The only major problems I have found with db connectivity is with ODBC (which > doesn't work, but then it doesn't on OpenOffice.org either). As for queries, > most of mine are simple, but involve the use of the CAST function and DATE > calculations and they work fine. > > > Alex Alex, I'm running Mac OX X version 10.6.7. 4GB of memory and a terabyte of disk space. After reading your comments, since you are not having any problems, I thought that I might have a bad install. I decided to uninstall and download a fresh copy of LibreOffice 3.3.2 and reinstall. I recreated the four small tables and loaded each with some data. All the tables displayed correctly. I then went to Libreoffice preferences to review the standard defaults and when I selected Libreoffice Base for review, Libreoffice quit unexpectedly again. I didn't have to attempt a query. Do you think I might have a problem with my Mac. No other application I run on the Mac acts this way. Any ideas?
Hi Toons, Did you remove /Users/myname/Library/Application Support/LibreOffice before you reinstalled and restarted ? This is where all your user settings are stored. It is/was the flakiest bit (on Mac at least) for some reason. Remove that folder or rename it if you've got stuff you absolutely need in it, then restart LibreOffice. The folder will be recreated. Do not load any ODBs that you might have recovered through the crash recovery wizard, mostly they end up corrupted in one way or another. Alex
(In reply to comment #3) > Hi Toons, > > > Did you remove /Users/myname/Library/Application Support/LibreOffice > before you reinstalled and restarted ? This is where all your user settings are > stored. It is/was the flakiest bit (on Mac at least) for some reason. > > Remove that folder or rename it if you've got stuff you absolutely need in it, > then restart LibreOffice. The folder will be recreated. > > Do not load any ODBs that you might have recovered through the crash recovery > wizard, mostly they end up corrupted in one way or another. > > > Alex Alex, Yes I did remove /Users/myname/Library/Application Support/LibreOffice. Here is an excerpt from the last crash report: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf802fec Crashed Thread: 0 Dispatch queue: com.apple.main-thread EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE ? This is caused by the thread trying to write to read-only memory. This is always caused by a data access. The thread was initiated from: com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 946 The app shouldn't be attempting to write in read-only memory! After an install as administrator using the .DMG package I downloaded, are the other steps one needs to execute e.g. permissions, temp areas, etc?
Ah thanks for that, I have another suggestion. Turn off the accessibility tools, this is known to make LibreOffice unstable and crash spontaneously without warning. Unfortunately, I don't think there is anyone in the dev team at the moment who has the time to look at this. Alex
(In reply to comment #5) By accessibility tools, I mean things like VoiceOver, etc. Alex > Ah thanks for that, I have another suggestion. > > Turn off the accessibility tools, this is known to make LibreOffice unstable > and crash spontaneously without warning. Unfortunately, I don't think there is > anyone in the dev team at the moment who has the time to look at this. > > > Alex
(In reply to comment #6) > (In reply to comment #5) > > By accessibility tools, I mean things like VoiceOver, etc. > > Alex > > > > Ah thanks for that, I have another suggestion. > > > > Turn off the accessibility tools, this is known to make LibreOffice unstable > > and crash spontaneously without warning. Unfortunately, I don't think there is > > anyone in the dev team at the moment who has the time to look at this. > > > > > > Alex Reviewing where things stand before giving up using LibreOffice for databases. I wanted to keep the source of the problem description clean and simple, independent of table configuration, size, etc. So, I reinstalled Libreoffice selected the database option and opened the provided Biblio database (I found out this could be any database). I then used the “Create Query in Design View” to add the bibllio table to the view (also I found out this could be any table ). I then attempted to enlarge the graphical display of the table by dragging the table boundary with my cursor. This action aborts LibreOffice and creates an iMac problem report stating in part that: “LibreOffice quit unexpectedly”. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf7ffffc Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x91d5da02 pthread_mutex_lock + 6 Since this report shows a memory access problem, could it be that I don’t have a 64bit install of LibreOffice or a 32bit implementation is failing on the 54bit iMac? It would help to know that the problem is just unique to my iMac or if any one else could reproduce the same problem. Thanks for all your help.
(In reply to comment #7) > Reviewing where things stand before giving up using LibreOffice for databases. > I wanted to keep the source of the problem description clean and simple, > independent of table configuration, size, etc. Did you turn off Accesibility tools like I suggested ? > Since this report shows a memory access problem, could it be that I don’t have > a 64bit install of LibreOffice or a 32bit implementation is failing on the > 54bit iMac? > LibreOffice for Mac is only available in 32bit build as far as I know. Are you running your kernel in 32bit or 64bit mode ? My kernel runs in 64bit mode, but I still don't have the instability that you encounter. Alex
(In reply to comment #8) > (In reply to comment #7) > > > Reviewing where things stand before giving up using LibreOffice for databases. > > I wanted to keep the source of the problem description clean and simple, > > independent of table configuration, size, etc. > > > Did you turn off Accesibility tools like I suggested ? > > > > Since this report shows a memory access problem, could it be that I don’t have > > a 64bit install of LibreOffice or a 32bit implementation is failing on the > > 54bit iMac? > > > > LibreOffice for Mac is only available in 32bit build as far as I know. Are you > running your kernel in 32bit or 64bit mode ? My kernel runs in 64bit mode, but > I still don't have the instability that you encounter. > > > Alex Alex, Im not sure what all the accessibility tools are. I did make sure VoiceOver is off. Could you identify the others are there? My kernel runs in 64bit mode. I have know problem using Sql statement to query. Do you use the “Create Query in Design View” and try to adjust the display with no problem? If so, the only thing I can think of is some APP I may have executing conflicting with LibreOffice. Thanks again
Hi Toon, Could you post the whole of the Apple stacktrace as an attachment to the bug please ? As to the Accessibility Tools : System Preferences, System and then the first icon representing a white man with outstretched arms on a blue background. Apart from turning off VoiceOver, also turn of the Zoom function if it is on. I don't know what else might have an influence here because, my settings are all those I had when I bought the machine in the first place. Could you post a copy of the ODB file here ? Even if I have to recreate the db backend on the mysql server, I could at least try and reproduce with your own ODB configuration data, unless it is confidential of course. Otherwise, give us the structure of your tables from the mysql server and I'll try and recreate them on my own for testing. Alex
Hi Toon, Well so much for me saying that Base was "fairly" stable. I was just testing 3.4rc1 and got a spontaneous crash when using the Datasource navigator window (obtained by pressing F4 on PC or Shift-F4 on Macbook) to copy data from various tables in a mysql database (using native C++ mysql connector) and the whole app bombed without warning. I have a similar trace message to yours : Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000024 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Will be looking at debugging this later with gdb. Alex
I might add that I'm not displaying a query, view or report as you indicated, so I will be opening a separate bug report for this. Alex
Is this bug still there in your latest version ? I can't reproduce this any more on my Mac. Can you provide a file for us to test with ? Alex
[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.
Installing Release of LibreOffice 3.4.5 solved this problem. BUG 37119 should be closed.
OP has stated that it now works OK, closing.