This is a GENERAL problem for me! I am using Base and had the problem with 5.3.7. I switched to 5.4.3 and still am seeing it. I am using the embedded database option. Note I have been using libreoffice base for a LONG time, before 2011, all on the SAME database which has grown.... I have been using it mostly on the same laptop for the past 4 years. In the process of looking at various forms for my database or reports, libreoffice "hangs". I can wait 30 minutes and it does not come back!! I started having this problem in the last few months. I am trying the LinuxMint standard LibreOffice package which is 5.1.6.2 to see if the problem occurs. So far, there is no evidence of this problem. I WILL UPDATE this report if the "hanging" problem PERSISTS or NOT.
see crash report b246ae69-d658-41c4-a372-4dc980e9e308
You could try getting a backtrace of the hang: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux Note that you need to install the LibreOffice debug package of your Linux distro.
(In reply to Buovjaga from comment #2) > You could try getting a backtrace of the hang: > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux > Note that you need to install the LibreOffice debug package of your Linux > distro. ..or maybe it will not provide any additional info as we already have the report: http://crashreport.libreoffice.org/stats/crash_details/b246ae69-d658-41c4-a372-4dc980e9e308
This wouldn't have anything to do with the kernel version bug by any chance ?
@Ralph : we need more information than what you have provided. You mention that the problem started a few months ago: the version numbers you mention weren't released a few months ago, certainly not 5.3.7 or 5.4.3, so we would need to know when the problem first appeared and with which version of LibreOffice. Additionally, you mention that you have been using the same embedded database for the past 4 years. It could be that your database has unfortunately become corrupt, this is a known drawback of using the embedded hsqldb 1.8 engine. If you have a backup, then I would suggest using a copy of that to test with the latest production releases to see whether you can still reproduce the problem. You mention that you can't reproduce the problem with 5.1.6.2, which is the version provided by the distribution (Mint Sarah ?)
Ideally, we would need an ODB file that shows the problem in order to test.
@Ralph : please also report whether you are using just distro-provided builds or snaps, or ppas, or whether you are using TDF downloads.
If you are using TDF builds and mixing with Ubuntu provided report-builder versions, you will have no end of trouble...
(In reply to Alex Thurgood from comment #4) > This wouldn't have anything to do with the kernel version bug by any chance ? Hi Alex! I am using: uname -a Linux sclero 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux cat /etc/linuxmint/info RELEASE=18.2 CODENAME=sonya EDITION="Cinnamon 64-bit" DESCRIPTION="Linux Mint 18.2 Sonya" DESKTOP=Gnome TOOLKIT=GTK NEW_FEATURES_URL=http://www.linuxmint.com/rel_sonya_cinnamon_whatsnew.php RELEASE_NOTES_URL=http://www.linuxmint.com/rel_sonya_cinnamon.php USER_GUIDE_URL=help:linuxmint GRUB_TITLE=Linux Mint 18.2 Cinnamon 64-bit and I am up-to-date. Does that provide the info that you need? Thanks! Ralph Peters
(In reply to Alex Thurgood from comment #7) > @Ralph : please also report whether you are using just distro-provided > builds or snaps, or ppas, or whether you are using TDF downloads. (In reply to Alex Thurgood from comment #5) > @Ralph : we need more information than what you have provided. > > You mention that the problem started a few months ago: the version numbers > you mention weren't released a few months ago, certainly not 5.3.7 or 5.4.3, > so we would need to know when the problem first appeared and with which > version of LibreOffice. > > Additionally, you mention that you have been using the same embedded > database for the past 4 years. It could be that your database has > unfortunately become corrupt, this is a known drawback of using the embedded > hsqldb 1.8 engine. > > If you have a backup, then I would suggest using a copy of that to test with > the latest production releases to see whether you can still reproduce the > problem. > > You mention that you can't reproduce the problem with 5.1.6.2, which is the > version provided by the distribution (Mint Sarah ?) Hi! 5.1.6.2 Is the "standard" deb file package provided by LinuxMint 18.2 5.3.7 and 5.4.3 were downloaded from the LibreOffice site as deb-file packages. When I switch, I always do a complete un-install: sudo apt-get purge libreoffice*.* sudo apt-get purge libreoffice-* sudo apt-get purge libobasis* Lately the first command clears out everything. Then I install. I either use the LinuxMint software gui (for 5.1.6.2) OR for the latter 2 cd ../something/DEBS/ sudo dpkg -i *.deb Does that answer your question? Ralph
Created attachment 137947 [details] relationships for database Bug 113937
(In reply to Alex Thurgood from comment #5) > @Ralph : we need more information than what you have provided. > > You mention that the problem started a few months ago: the version numbers > you mention weren't released a few months ago, certainly not 5.3.7 or 5.4.3, > so we would need to know when the problem first appeared and with which > version of LibreOffice. > > Additionally, you mention that you have been using the same embedded > database for the past 4 years. It could be that your database has > unfortunately become corrupt, this is a known drawback of using the embedded > hsqldb 1.8 engine. > > If you have a backup, then I would suggest using a copy of that to test with > the latest production releases to see whether you can still reproduce the > problem. > > You mention that you can't reproduce the problem with 5.1.6.2, which is the > version provided by the distribution (Mint Sarah ?) Hi, I have MANY backups of the database .odb file. I could go back a year or two to see if the problem exists. Some times it takes an hour or two of use before it shows up. I have seen the problem a time or two with 5.1.6.2. Sometimes, even if I do a "Force" quit I see soffice.bin running in "top" and have to kill it with "kill -9 ###" I was using 5.3.3 before and did not see the problem. But, during the summer I am busy doing other things and may not have stressed it enough then. How does one un-corrupt a file. Yes I could go back to a odb file that appears OK, but the work involved may be monumental to update to "current". It would be nice if someone would write some software to test basic stuff for corruption, like "relataionships" - see attached jpeg. Ralph
(In reply to Alex Thurgood from comment #5) > @Ralph : we need more information than what you have provided. > > You mention that the problem started a few months ago: the version numbers > you mention weren't released a few months ago, certainly not 5.3.7 or 5.4.3, > so we would need to know when the problem first appeared and with which > version of LibreOffice. > > Additionally, you mention that you have been using the same embedded > database for the past 4 years. It could be that your database has > unfortunately become corrupt, this is a known drawback of using the embedded > hsqldb 1.8 engine. > > If you have a backup, then I would suggest using a copy of that to test with > the latest production releases to see whether you can still reproduce the > problem. > > You mention that you can't reproduce the problem with 5.1.6.2, which is the > version provided by the distribution (Mint Sarah ?) Hi, I have thought about using a split database with something like MariaDB. But I have not seen a good tutorial on making the switch. I started a time or two and gave up. I would like to export data, forms, reports, queries,.... I do not mind spending a day or two to get back to my current setup if it would be roughly the same. I exported this database once from a DOS database (cornerstone) and that was a lot of work! Ralph
(In reply to Alex Thurgood from comment #8) > If you are using TDF builds and mixing with Ubuntu provided report-builder > versions, you will have no end of trouble... Hi, I do not think that I am doing this... I am using the LinuxMint software and also LibreOffice downloads - see a previous reply. Ralph
Thanks Ralph, let me have a read through your answers and I'll try and get back to you with some suggestions.
(In reply to Ralph Peters from comment #11) > Created attachment 137947 [details] > relationships for database Bug 113937 BTW, the ODB file for this is 5.4 MB, so it is fairly large.
(In reply to Alex Thurgood from comment #15) > Thanks Ralph, let me have a read through your answers and I'll try and get > back to you with some suggestions. Great! The problem seems to occur when I have several forms open making changes to the data. I would prefer not to ship the odb file to you. It contains some sensitive info. I can do tests for you to look for bugs. I am an engineer who wrote software for some 40 years in Fortran, Lisp, C++, java,... on topics ranging from simulation of solar-energy systems to simulation of simple nuclear-power systems for space applications to water and contaminant transport modeling and building geometry (surroundings) from various sensors like "laser range-finders" (robotics). I have way to much experience looking for bugs! BTW, an up-to-date tutorial about moving from the embedded hsqldb to an external database using something like MariaDB would be very helpful. Yes, there are old tutorials on the web that treat "bits and pieces" of such a move -- although I may have missed a newer one. I would be quite willing to read the new tutorial, use it AND provide feedback to the author to make it better. Talk to you later, Ralph
@Ralph : as you mention that you have programming experience, perhaps you could install either the debug code for the version of LO that comes with your distrib and try and obtain a backtrace using gdb when the app hangs. That at least might point in the right direction. The problem with LO5162 as provided by the distro is that it is, to all intents and purposes, obsolete, and no longer supported by TDF. Whether or not Ubuntu still provides updates and fixes for that version is another matter altogether and not within the LibreOffice project's control. Another avenue to explore is the version of JDK/JVM. The report-builder, as does embedded hsqldb, uses Java to function correctly, and perhaps a SIGSEGV in the JVM, for whatever reason, is subsequently causing LO to hang. You might want to look through your logs to see if there are any traces of hangs registered there when using LibreOffice and that particular ODB file. If we don't have a copy of the database, and I understand your reticence to post a copy on this bug report, then it is going to be very difficult for us to reproduce. If your database contains confidential information then posting it to this bug report is not a good idea, as it will become public. There are/were known mutex release issues that sometimes occur(red) with LibreOffice Base, particularly when switching between Forms and Reports. The behaviour you describe might be one such occurrence, which is why I suggested trying to obtain a backtrace with a debug build (or the associated debug symbol code provided with the distro version).
(In reply to Alex Thurgood from comment #18) > @Ralph : as you mention that you have programming experience, perhaps you > could install either the debug code for the version of LO that comes with > your distrib and try and obtain a backtrace using gdb when the app hangs. > That at least might point in the right direction. > > The problem with LO5162 as provided by the distro is that it is, to all > intents and purposes, obsolete, and no longer supported by TDF. Whether or > not Ubuntu still provides updates and fixes for that version is another > matter altogether and not within the LibreOffice project's control. > > Another avenue to explore is the version of JDK/JVM. The report-builder, as > does embedded hsqldb, uses Java to function correctly, and perhaps a SIGSEGV > in the JVM, for whatever reason, is subsequently causing LO to hang. You > might want to look through your logs to see if there are any traces of hangs > registered there when using LibreOffice and that particular ODB file. > > If we don't have a copy of the database, and I understand your reticence to > post a copy on this bug report, then it is going to be very difficult for us > to reproduce. If your database contains confidential information then > posting it to this bug report is not a good idea, as it will become public. > > There are/were known mutex release issues that sometimes occur(red) with > LibreOffice Base, particularly when switching between Forms and Reports. The > behaviour you describe might be one such occurrence, which is why I > suggested trying to obtain a backtrace with a debug build (or the associated > debug symbol code provided with the distro version). Hi Alex, Where do I get the debug code? I could wander the web but thought that I would ask. I am currently using version 5.4.3.2 of LibreOffice which I downloaded from the LibreOffice site. Ahh gdb.... I remember it well...with fondness based on many hours(days, weeks...) using it inside emacs. (Maybe not fondness, but it was a great tool.) I have not used it for a few years, so I may have a few questions about what would make sense to do. Are you suggesting just a simple run and then look at the backtrace after I kill it?? A set of suggestions to get me re-started might speed things up. Is "main" LibreOffice code c++? Or one of the newer languages? I know that hsqldb is java. Which logs should I look at during and after a "hang"? Suggestions appreciated! You mentioned mutex issues and that sounds right to me. On occasion, after I killed LibreOffice in the standard gui manner ("Wait" or "Force Quit"), I have checked "top" and found soffice.bin was still running and chewing up a lot of cpu (40%) after it was "killed". Ralph -------------------------------------------- I CHECKED ON THE INSTALLED PACKAGES FOR JAVA and JDK. Are these appropriate? JAVA: dpkg -l | grep java ii ca-certificates-java 20160321 all Common CA certificates (JKS keystore) ii cjs 3.4.4+sonya amd64 Mozilla-based javascript bindings for the Cinnamon platform ii gir1.2-javascriptcoregtk-3.0:amd64 2.4.11-0ubuntu0.1 amd64 JavaScript engine library from WebKitGTK+ - GObject introspection data ii gir1.2-javascriptcoregtk-4.0:amd64 2.18.3-0ubuntu0.16.04.1 amd64 JavaScript engine library from WebKitGTK+ - GObject introspection data ii gjs 1.44.0-1ubuntu1 amd64 Mozilla-based javascript bindings for the GNOME platform ii java-common 0.56ubuntu2 all Base package for Java runtimes ii libapache-pom-java 10-2build1 all Maven metadata for all Apache Software projects ii libatk-wrapper-java 0.33.3-6 all ATK implementation for Java using JNI ii libatk-wrapper-java-jni:amd64 0.33.3-6 amd64 ATK implementation for Java using JNI (JNI bindings) ii libcjs0f 3.4.4+sonya amd64 Mozilla-based javascript bindings for the Cinnamon platform ii libcommons-beanutils-java 1.9.2-3 all Apache Commons BeanUtils - Utility for manipulating Java beans ii libcommons-collections3-java 3.2.2-1 all Apache Commons Collections - Extended Collections API for Java ii libcommons-compress-java 1.10-2 all Java API for working with compression and archive formats ii libcommons-digester-java 1.8.1-4 all Rule based XML Java object mapping tool ii libcommons-logging-java 1.2-1+build1 all common wrapper interface for several logging APIs ii libcommons-parent-java 39-3 all Maven metadata for Apache Commons project ii libdb-je-java 3.3.98-1 all Oracle Berkeley Database Java Edition ii libgjs0e 1.44.0-1ubuntu1 amd64 Mozilla-based javascript bindings for the GNOME platform ii libhsqldb1.8.0-java 1.8.0.10+dfsg-6 all Java SQL database engine ii libicu4j-java 4.2.1.1-3 all Library for Unicode support and internationalization ii libjavascriptcoregtk-1.0-0:amd64 2.4.11-0ubuntu0.1 amd64 JavaScript engine library from WebKitGTK+ ii libjavascriptcoregtk-3.0-0:amd64 2.4.11-0ubuntu0.1 amd64 JavaScript engine library from WebKitGTK+ ii libjavascriptcoregtk-4.0-18:amd64 2.18.3-0ubuntu0.16.04.1 amd64 JavaScript engine library from WebKitGTK+ ii libjaxp1.3-java 1.3.05-2ubuntu3 all Java XML parser and transformer APIs (DOM, SAX, JAXP, TrAX) ii libjtidy-java 7+svn20110807-4 all JTidy ii liblucene2-java 2.9.4+ds1-4 all Full-text search engine library for Java(TM) ii libobasis5.4-extension-javascript-script-provider 5.4.3.2-2 amd64 Script provider for JavaScript extension for LibreOffice 5.4 .3.2 ii libservlet2.5-java 6.0.45+dfsg-1 all Servlet 2.5 and JSP 2.1 Java API classes ii libservlet3.0-java 7.0.68-1ubuntu0.1 all Servlet 3.0 and JSP 2.2 Java API classes ii libservlet3.1-java 8.0.32-1ubuntu1.4 all Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API classes ii plasma-scriptengine-javascript 4:15.12.3-0ubuntu1 amd64 JavaScript script engine for Plasma JDK: dpkg -l | grep jdk ii openjdk-8-jre:amd64 8u151-b12-0ubuntu0.16.04.2 amd64 OpenJDK Java runtime, using Hotspot JIT ii openjdk-8-jre-headless:amd64 8u151-b12-0ubuntu0.16.04.2 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
BTW, many times if I do NOT "save" my work before closing LibreOffice Base, it will hang "permanently". save -> means click the "save" icon - the floppy disk icon in upper left close -> means click the "X" in the upper-right corner I can "kill" libreoffice base and "recover" my work and then re-remember to save and then close.
Ralph: see here https://wiki.documentfoundation.org/QA/BugReport/Debug_Information For Debian, Ubuntu the package names apparently follow the format libreoffice-*-dbgsym Another possibility is downloading this massive 2GB (6GB unpacked) archive, which includes the debug symbols already: http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/current/ It is a fresh master build.
Setting to NEEDINFO pending receipt of a backtrace. If we get one, we can decide where to go from there.
(In reply to Buovjaga from comment #21) > Ralph: see here > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information > > For Debian, Ubuntu the package names apparently follow the format > libreoffice-*-dbgsym > > Another possibility is downloading this massive 2GB (6GB unpacked) archive, > which includes the debug symbols already: > http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF- > dbg/current/ > It is a fresh master build. Hi, I suppose that a set of "dbgsym" deb files are available for 5.4.2? I looked, but was unable to find them. Your link sent me to a debug set for 6.0 which MAY have its own new & exciting problems. I can use it if that is all that is available, but.... I see that valgrind lives! A wonderful tool, but only if you are able to stand a slow-down of 100 fold... Ralph
(In reply to Ralph Peters from comment #23) > I suppose that a set of "dbgsym" deb files are available for 5.4.2? I > looked, but was unable to find them. They are supposed to be in your distribution's package repository. Ubuntu has them, but I am not sure about Linux Mint. If you are unable to find them, the 6.0 debug build should do (if the problem still happens).
(In reply to Buovjaga from comment #24) > (In reply to Ralph Peters from comment #23) > > I suppose that a set of "dbgsym" deb files are available for 5.4.2? I > > looked, but was unable to find them. > > They are supposed to be in your distribution's package repository. Ubuntu > has them, but I am not sure about Linux Mint. > > If you are unable to find them, the 6.0 debug build should do (if the > problem still happens). Ubuntu should work just fine. OK, I spent some time looking at Ubuntu and did not see what you are talking about. Would it be possible for you to provide a link to what you think is the BEST download (.tgz file) for me to use? Thanks, Ralph Peters
(In reply to Ralph Peters from comment #25) > OK, I spent some time looking at Ubuntu and did not see what you are talking > about. Would it be possible for you to provide a link to what you think is > the BEST download (.tgz file) for me to use? I would just go with the latest master debug build, which now happens to be: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/2017-11-29_00.49.31/master_dbg~2017-11-29_00.49.31_LibreOfficeDev_6.1.0.0.alpha0_Linux_x86-64_archive.tar.gz After unpacking, you should just be able to run soffice from the program subdirectory.
(In reply to Buovjaga from comment #26) > (In reply to Ralph Peters from comment #25) > > OK, I spent some time looking at Ubuntu and did not see what you are talking > > about. Would it be possible for you to provide a link to what you think is > > the BEST download (.tgz file) for me to use? > > I would just go with the latest master debug build, which now happens to be: > https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF- > dbg/2017-11-29_00.49.31/master_dbg~2017-11-29_00.49.31_LibreOfficeDev_6.1.0. > 0.alpha0_Linux_x86-64_archive.tar.gz > > After unpacking, you should just be able to run soffice from the program > subdirectory. THANKS! I hope to give it a try in the next day or two. Ralph
Created attachment 138086 [details] GDB output from PRELIMINARY run LOTs of complaints! It stopped several times so I had to "continue"
Created attachment 138087 [details] Trace file for PRELIMINARY run This is the trace file that is associated with the "GDB output" file that I just sent. NOTE!! LO Base did not crash but there are LOTS of complaints... I will try to reproduce some of my "hanging" problems tomorrow. These 2 files are just examples to see if I am doing the things that you need/want. and now off to a basketball game... Ralph
After a closer look there are some SIGSEGV problems. NOT good!
BTW, this was just a simple test. I opened a single form at a time (locations and then plants) and did a search for records that matched a specified value. Nothing fancy or complicated!
Created attachment 138220 [details] A second gdb trace. I thought that I would look up stuff in "tables" instead of "forms" and paid close attention to the gdb output. After looking at the output, I gave up!! This is a mess. SIGSEV occurs repeatedly! Is the 6. branch this much of a mess?? Please respond! Look at both gdb traces!
I have been using 5.4.3 to add information with only 1 form open. I had 1 hang and when I recovered I found that most of the info (45 minutes of work) was gone. I have just tried again doing something even simpler and now, as I am shutting down to save my work, it has hung again. The gui says "Wait?" or "Force quit?" and after cycling through this several times over 15 minutes I have given up and done a "Force quit" I was able to recover and all the new data was there, but when I tried to exit it hung again. A fourth try recovered and successfully shutdown. Output from a shell program "watching" soffice shows modest use during this last "hang". Mon Dec 11 12:33:41 MST 2017 - %CPU %MEM CMD 5.3 12.2 /opt/libreoffice5.4/program/soffice.bin --base file:///home/ralph/Desk Mon Dec 11 12:33:51 MST 2017 - %CPU %MEM CMD 5.3 12.2 /opt/libreoffice5.4/program/soffice.bin --base file:///home/ralph/Desk Mon Dec 11 12:34:01 MST 2017 - %CPU %MEM CMD 5.3 12.2 /opt/libreoffice5.4/program/soffice.bin --base file:///home/ralph/Desk Mon Dec 11 12:34:11 MST 2017 - %CPU %MEM CMD 5.3 12.2 /opt/libreoffice5.4/program/soffice.bin --base file:///home/ralph/Desk Mon Dec 11 12:34:21 MST 2017 - %CPU %MEM CMD 5.2 12.2 /opt/libreoffice5.4/program/soffice.bin --base file:///home/ralph/Desk This database is almost USELESS!!! Would someone fix all the SIGSEGV errors and I can see if the problem goes away?
Well, no response so far - almost a month since my first post on this subject! I decided after doing some research on the web to switch from an embedded database to a split database which uses hysqldb using the wizard found at https://www.mediafire.com/file/59iq0esx071zcic/Split_HSQLDB_Wizard_v3c.odb?ssl=1 I spent about a day doing the transfer, which included a fairly detailed check of the new database to see that all data tables, views, forms, and reports were OK. I have been using the split-database for several days and have had NO CRASHES. YES NONE! This leads me to suspect that there is nothing wrong with my data, instead there are problems with the current (LO 5.4.3) implementation of the embedded database in LO. If I have any "crash" problems I will report them here!! SO, I would suggest that people do NOT USE the embedded database and switch/start with the split version! There are a number of web pages on the subject for example http://g0o0o0gle.com/base-wizard-portablesplit-hsql-database-template/ BTW, my database is fairly large. The mydb.data file is 34 MB. Compressed as a tgz file the size is 5.5 MB, this includes everything except the driver files (hysqldb.jar and sqltool.jar) which do not change.
(In reply to Ralph Peters from comment #34) > Well, no response so far - almost a month since my first post on this That is a rather unfair assessment given that several people have responded to you over the weeks. The fact of the matter is that you have a fairly large, complex embedded hsqldb database, and you can not, for perfectly valid reasons, provide us with a copy of the ODB. This means we are pretty much limited in where we can go with this. The fact that Base sigsegv's all over the place is nothing new and is down mainly to JVM instantiation and memory management (most, but not all, of the SIGSEGV tend to occur in the JVM). Two suggestions : - try increasing RAM allocated for the Java thread when you open the ODB file - possibly, that might help stabilize things a little - in order to do this, you will need to change the memory settings in the .properties or .scpt file within the ODB itself, which means unzipping and opening those files in a text editor, making your changes, then saving them and rezipping. Best to to do that on a copy of the ODB to see how well that goes. Off-hand, I don't remember exactly which file needs to be changed, but this should be searchable via Google, perhaps even in the hsqldb documentation itself ; - second suggestion that might help us is if you could construct an ODB file with a minimum set of tables/forms/relationships not containing any sensitive data and that you could provide us, so that we could test ourselves.
Seeing a SIGSEGV in the AffineBridge rang a bell : - it could be that you've been hit by the problem described and discussed in this thread : https://lists.freedesktop.org/archives/libreoffice/2015-June/068446.html for which there is currently no solution. See also bug 57872, which is also related to the above mail discussion (indirectly, in that it talks about how to improve performance in the Java bridge).
(In reply to Alex Thurgood from comment #35) > (In reply to Ralph Peters from comment #34) > > Well, no response so far - almost a month since my first post on this > > That is a rather unfair assessment given that several people have responded > to you over the weeks. > > The fact of the matter is that you have a fairly large, complex embedded > hsqldb database, and you can not, for perfectly valid reasons, provide us > with a copy of the ODB. This means we are pretty much limited in where we > can go with this. > > The fact that Base sigsegv's all over the place is nothing new and is down > mainly to JVM instantiation and memory management (most, but not all, of the > SIGSEGV tend to occur in the JVM). > > Two suggestions : > > - try increasing RAM allocated for the Java thread when you open the ODB > file - possibly, that might help stabilize things a little - in order to do > this, you will need to change the memory settings in the .properties or > .scpt file within the ODB itself, which means unzipping and opening those > files in a text editor, making your changes, then saving them and rezipping. > Best to to do that on a copy of the ODB to see how well that goes. Off-hand, > I don't remember exactly which file needs to be changed, but this should be > searchable via Google, perhaps even in the hsqldb documentation itself ; > > - second suggestion that might help us is if you could construct an ODB file > with a minimum set of tables/forms/relationships not containing any > sensitive data and that you could provide us, so that we could test > ourselves. I chose my words poorly Alex. I have received a number of replies since I first posted the problem! I should have said that I have only received requests for more info. On a major piece of C++ code that I was developing, I ran both valgrind and gdb at least every week during development to check for "unseen" problems. Of course, I ran them whenever I had a problem. And that kept me out of trouble. So,the SIGSEVs caused me a lot of heartburn. I had not received any response about the SIGSEVs, until now. Yes, it is difficult to debug via "long distance". I have done only a little java software, so figuring out how to increase the size of RAM and the mutex stuff would take me quite a while. BTW, I thought that java was not supposed to have memory problems? Wasn't that the point? But I am merely an old C++ hacker (and lisp and Fortran) The bottom line is that splitting the database SEEMS to have solved the problem. I am using hysqldb 2.4 This "experiment" may provide you with some more ideas about what the problem is. I will notify you on this thread if I see a problem. I have spent a number of hours adding data with 1 to 2 forms open and NO problems. I will be adding a lot of data to the split database and will have multiple forms open at one time. This should provide a good test!! BTW, I will not go back to the embedded database as the split one posts info to the database during the session and is reported to be less likely to lose information when there are problems. Or do I mis-understand what I have read?? So, again my apologies for getting a bit rude. The task, as I laid it out was very difficult!! I became irritated when I could not go "back to work". Thanks for your help and attention! Ralph
Alex, I am using hysqldb 2.4 in the split database. I think the embedded database uses hysqldb version 1.8. (released in 2008) Is it possible that some of these problems are associated with the "old" database? I would imagine that there has been major work done, maybe even in areas that affect this set of problems.. Just a thought, Ralph
(In reply to Ralph Peters from comment #38) > I am using hysqldb 2.4 in the split database. I think the embedded database > uses hysqldb version 1.8. (released in 2008) > > Is it possible that some of these problems are associated with the "old" > database? I would imagine that there has been major work done, maybe even > in areas that affect this set of problems.. The plan is to rather move to Firebird SQL. There are some blocker bugs still https://bugs.documentfoundation.org/showdependencytree.cgi?id=51780&hide_resolved=1
I didn't read the whole part but just some remarks: 1) About gdb traces: first one doesn't show bt just some running but perhaps it was on purpose second one shows "??" and, as Alex indicated, must correspond to Java part. It should indeed be fixed but for the moment, just type "c" to keep on and fetch the real bt. third one displays nothing except the real gdb trace is in gdbtrace.log 2) About hsqldb version I hope you don't try to mix versions because it could corrupt your db. Indeed, LO uses hsqldb 1.8.0 so if you use 2.4 even to experiment... 3) It seems we still need a step by step process to reproduce this with a small db. 4) as you're very experienced, I wonder if you'd be interested in building LO code, see https://www.libreoffice.org/community/developers/ Indeed, most of the LO code is in C++ (I'd say at least 90%?). It would allow you to: - not search some debug packages - to choose your build options - try to add some specific debug traces ... but I'll stop here since I won't teach you anything here :-) Of course you need a good connection since LO code is quite big and some patience to build (depending on your machine obviously and your build options) but once it's done, you can really experiment.
Created attachment 138772 [details] Various web sites that helped me to move from a embedded to split database
(In reply to Julien Nabet from comment #40) > I didn't read the whole part but just some remarks: > 1) > About gdb traces: > first one doesn't show bt just some running but perhaps it was on purpose > second one shows "??" and, as Alex indicated, must correspond to Java part. > It should indeed be fixed but for the moment, just type "c" to keep on and > fetch the real bt. > third one displays nothing except the real gdb trace is in gdbtrace.log > > 2) > About hsqldb version > I hope you don't try to mix versions because it could corrupt your db. > Indeed, LO uses hsqldb 1.8.0 so if you use 2.4 even to experiment... > > 3) > It seems we still need a step by step process to reproduce this with a small > db. > > 4) > as you're very experienced, I wonder if you'd be interested in building LO > code, see https://www.libreoffice.org/community/developers/ > Indeed, most of the LO code is in C++ (I'd say at least 90%?). > It would allow you to: > - not search some debug packages > - to choose your build options > - try to add some specific debug traces > ... > but I'll stop here since I won't teach you anything here :-) > Of course you need a good connection since LO code is quite big and some > patience to build (depending on your machine obviously and your build > options) > but once it's done, you can really experiment. Hi, I am using hysqldb 2.4 only with my split database see: https://www.mediafire.com/file/59iq0esx071zcic/Split_HSQLDB_Wizard_v3c.odb?ssl=1 for a bit of background on my setup. So, I do not think that there is any problem with having both 2.4 and 1.8, as 1.8 is used only for the embedded database. IMPORTANT BTW, I have been using my split database since about 12/15/2017 and have had no hanging/crashing problems at all. I have more than 30 hours of using it and entering data. I have had some "fun" making it do the right thing (like auto-incrementing keys in tables) but I have fixed my particular problems. I miss being able to modify database tables after they are in use. (Yes, I can setup a new one, copy-paste data and then delete the old one.) But the rock-solid stability makes these annoyances a very minor problem. So, I am interested in spending my limited time, particularly on the computer, working instead of chasing bugs. I would seriously suggest that "official" and updated documents be written for Base concerning CONVERTING an embedded database to a split one. Currently, there are a number of sources (SEE ATTACHED PDF) that are from different dates. I would also suggest that NO ONE use an embedded database because of the numerous problems discussed in various forums and articles on the web. Ralph Peters
(In reply to Ralph Peters from comment #42) > > Hi, > > I am using hysqldb 2.4 only with my split database see: > https://www.mediafire.com/file/59iq0esx071zcic/Split_HSQLDB_Wizard_v3c. > odb?ssl=1 > for a bit of background on my setup. > > So, I do not think that there is any problem with having both 2.4 and 1.8, > as 1.8 is used only for the embedded database. Please see bug34411 Bug hasn't been solved up to now. With internal database I use a macro to save the database every time I open the file. So I have 10 copies saved in LO-backup-path. For external database I would use MariaDB instead. Connecting to MariaDB, to PostgreSQL, Firebird, external HSQLDB and some others is all described in Base-Handbook. Little problem: Newer versions aren't translated yet from German to English.
(In reply to robert from comment #43) > (In reply to Ralph Peters from comment #42) > > > > Hi, > > > > I am using hysqldb 2.4 only with my split database see: > > https://www.mediafire.com/file/59iq0esx071zcic/Split_HSQLDB_Wizard_v3c. > > odb?ssl=1 > > for a bit of background on my setup. > > > > So, I do not think that there is any problem with having both 2.4 and 1.8, > > as 1.8 is used only for the embedded database. > > Please see bug34411 > > Bug hasn't been solved up to now. > > With internal database I use a macro to save the database every time I open > the file. So I have 10 copies saved in LO-backup-path. For external database > I would use MariaDB instead. > > Connecting to MariaDB, to PostgreSQL, Firebird, external HSQLDB and some > others is all described in Base-Handbook. Little problem: Newer versions > aren't translated yet from German to English. Hi, I have a bash script that I run to keep 4 backups on my local computer and a backup on Dropbox, plus backups on Google Drive... It is better than none, but one can still lose your work since the last backup. If it crashes regularly (every 2 or 3 hours), one can become quite frustrated! I used hysqldb because there was a wizard to do the setup!! And instructions too! Also, it was relatively easy to move database tables, forms,queries, and reports from the old embedded database to the new split one -- merely cut & paste! It would be really nice to have an up-to-date Base handbook that discussed this topic and others! My heritage is German, but I do not read or speak it. Thanks, Ralph Peters
Closing this report as insufficient data. The information about the legendary instability of the embedded hsqsl 1.8.0 when the ODB file contains many reports, forms, macros, etc and a file size of several Mb is well known. It is documented in many places and certainly not a new phenomena. I could have set this to WONTFIX, as it is unlikely that the instability issues will ever be addressed for the current embedded version of hsqldb, considering that the project is moving towards supporting embedded Firebird as the default rather than continuing with embedded hsqldb. This means that the code relating to embedded hsqldb is in "maintenance/curation mode" rather than "active development". Regressions are still being fixed for the time being, but tomy knowledge, no specific development with regard to improving embedded hsqldb 1.8 is being undertaken. As we don't have a sample db file with which to test, and as the original poster has moved to an external hdsqldb solution, I am setting this to INSUFFICIENT DATA rather than worksforme.
(In reply to Alex Thurgood from comment #45) > Closing this report as insufficient data. > > The information about the legendary instability of the embedded hsqsl 1.8.0 > when the ODB file contains many reports, forms, macros, etc and a file size > of several Mb is well known. It is documented in many places and certainly > not a new phenomena. > > I could have set this to WONTFIX, as it is unlikely that the instability > issues will ever be addressed for the current embedded version of hsqldb, > considering that the project is moving towards supporting embedded Firebird > as the default rather than continuing with embedded hsqldb. This means that > the code relating to embedded hsqldb is in "maintenance/curation mode" > rather than "active development". Regressions are still being fixed for the > time being, but tomy knowledge, no specific development with regard to > improving embedded hsqldb 1.8 is being undertaken. > > > As we don't have a sample db file with which to test, and as the original > poster has moved to an external hdsqldb solution, I am setting this to > INSUFFICIENT DATA rather than worksforme. Closing it seems like a reasonable thing to do Alex. I was unable to setup a test database that illustrated the problems and didn't have sensitive info. I have continued using my split database and have done a lot of work adding "location" data from friends - adding something like 4000 records, editing them, etc. I have also used other parts of the database adding records, editing etc. My total time working with it is at least 80 hours. I have had NO CRASHES!!!! What a relief!!! Yes, there are some minor inconveniences using a split database -- for example one cannot modify tables after they are created. It would be nice to be able to edit the "Description" for each of the variables at a later date. BTW, your first line in the post is concerning ("legendary instability") - Is this one of the reasons for switching to Firebird? It may be worthwhile to think about the "root-cause" of the embedded database problems. Is it hysqldb 1,8 OR something else in the linkage between it and libreoffice. I would think that the Firebird group should be inetersted/concerned/something...
(In reply to Ralph Peters from comment #46) > > BTW, your first line in the post is concerning ("legendary instability") - > Is this one of the reasons for switching to Firebird? It may be worthwhile > to think about the "root-cause" of the embedded database problems. Is it > hysqldb 1,8 OR something else in the linkage between it and libreoffice. I > would think that the Firebird group should be > inetersted/concerned/something... No, the problems with hsqldb and LO, AOO, and prior to that OOo, mainly all revolve around Java, and the way it is instantiated and the Java processes managed within the LO process. It has always been a disaster just sitting there, waiting to happen, even at the time that Sun first came up with idea (I was involved with OOo at the time and voiced my concerns even then, from the non-developer perspective that I had). Embedded Firebird doesn't use any of that Java-instantiation stuff. That was the whole point of moving to it in the first place, to hopefully provide a C++ based engine database that could be embedded without having to rely on Java to jump through rings of fire. The problem is that we have a ton of legacy ODB files with embedded hsqldb 1.8 out there in userland, and no easy way to convert them.
Thanks for the reply! I am just a simple-minded Fortran/C++ programmer :^), but did a bit in java and can "sorta" understand your comments. I think that you implied these problems do not exist with a split database and/or the later hsqldb 2.4?? Correct? At least, I have not seen problems, yet. The problems with legacy embedded databases could be "fixed/mitigated" if there was a detailed explanation/tutorial about how to switch to a split database and some supporting software. It would certainly be good "public relations" with your "customers". I had relatively good luck moving to a split database with hsqldb 2.4. Why did I choose hsqldb? There were bits of documentation on the web, a wizard to help with setup, and I thought (maybe incorrectly) that staying with hsqldb would make the move easier. Thanks for your help and comments, Ralph Peters Retired cactus & succulent guy in Albuquerque NM For something completely different (pretty pictures that I also "index" in this database), go to http://www.new-mexico.cactus-society.org/Presentations/RalphPeters_ThunderRiver/PicGallery/index.html
You have captured some remarkably succulent specimens there, Ralph! (In reply to Alex Thurgood from comment #47) > The problem is that we have a ton of > legacy ODB files with embedded hsqldb 1.8 out there in userland, and no easy > way to convert them. Relevant tender result from Sept 2017: https://listarchives.documentfoundation.org/www/board-discuss/msg04087.html "Tender to implement HSQLDB binary format import in LibreOffice"