Created attachment 95492 [details] spreadsheet exhibiting above bug Creating a name leads to the message "LibreOffice 4.2 - Fatal Error Caught Unknown Exception: Aborting" In detail, in the attached spreadsheet, select a.a70:b70, then "Insert > Names > Create", then "OK" The spreadsheet has over 200 names defined already, so this bug may reflect an undocumented limitation on the number of names allowed. This bug may be related to bug 71943: 71943 also occurs when entering a new formula, but is intermittent and gives a different error message. This new bug occurs every time.
I have succeeded in creating a segmentation fault; attachments coming soon. I am not sure what "a.a70:b70" means, so I selected "a70:b70". My LibreOffice is master commit 806f4d8, fetched 2014-03-04, configured: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and running on debian-wheezy 64-bit. For comparison, LibreOffice 3.5.4.2, as delivered with debian-wheezy, also has a segmentation fault. The stack of the failing thread is: (gdb) backtrace #0 0x000000000cc076c0 in ?? () #1 0x00007fcfef08c225 in ?? () #2 0x0000000000000000 in ?? () This is so different from my backtrace that I am not changing the reported version; advice welcome. To help bugzilla search, from top stack frame at the crash in master: formula::FormulaTokenIterator::GetNonEndOfPathToken (this=0x92bdd00, nIdx=0) at /home/terry/lo_hacking/git/libo4/formula/source/core/api/token.cxx:1328
Created attachment 95515 [details] typescript of crashing LO
Created attachment 95516 [details] backtrace with symbols
(In reply to comment #1) > I have succeeded in creating a segmentation fault; attachments coming > soon. I am not sure what "a.a70:b70" means, so I selected "a70:b70". > a.a70:b70 means cells a70 and b70 in sheet "a".
Created attachment 95532 [details] console logs + bt with symbols On pc Debian x86-64 with master sources updated yesterday (commit 64a96febfe6877a504d8b9f049ce6c02a1b6310f), I have a segfault during the opening.
Quite a variety of failures here: (*) Win : Unknown exception upon Insert > Names > Create (*) Linux : Segmentation fault upon Insert > Names > Create (*) Linux : Segmentation fault upon opening the file I suspect that we are seeing the infamous "undefined bahavior". Can we find somebody with the setup and the patience to try this under valgrind?
With gdb I found that the problem was in sc/source/core/tool/interpr1.cxx: 7795 void ScInterpreter::ScLeft() 7796 { 7797 sal_uInt8 nParamCount = GetByte(); 7798 if ( MustHaveParamCount( nParamCount, 1, 2 ) ) 7799 { 7800 sal_Int32 n; 7801 if (nParamCount == 2) 7802 { 7803 double nVal = ::rtl::math::approxFloor(GetDouble()); // GIVES nan 7804 if ( nVal < 0.0 || nVal > SAL_MAX_UINT16 ) 7805 { 7806 PushIllegalArgument(); 7807 return ; 7808 } 7809 else 7810 n = (sal_Int32) nVal; // GIVES -2147483648 7811 } 7812 else 7813 n = 1; 7814 OUString aStr = GetString().getString(); 7815 n = std::min(n, aStr.getLength()); 7816 aStr = aStr.copy( 0, n ); 7817 PushString( aStr ); 7818 } 7819 } See http://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr1.cxx#7795 About Valgrind, I'll give it a try.
Created attachment 95621 [details] valgrind trace I git updated my local repo (which points on master branch) and retrieved Valgrind trace. I wanted to disable jre but it seems it needs jre to open this file. Except "invalid write of size 4" with a stacktrace related to Java, I noticed nothing, perhaps missed it.
Has there been any progress on this, please? I'm unable to develop my spreadsheet application because of this problem. If it can't be solved, can anyone suggest a work-around? David Lynch
I have a crash from bibisect 42-all versions latest and oldest. So, setting whiteboard NotBibisectable. Meanwhile my debug build of commit 115b295, fetched 2014-04-11 21:59 UTC, fails with an assertion. Like Julien's backtrace on 2014-03-10, rtl_uString_newFromSubString has implausible paramter count=-2147483648
It doesn't crash for me though. Is this specific to a 32-bit platform? I'm on 64-bit.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=37d7d115dd346ba7a713a5a18d90fc48a0d35072 fdo#75971: Perhaps this will prevent the crash ? The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien, or anyone interested, Could you test my above commit and see if that fixes the crash? I can't reproduce it in my environment so I can't verify...
> It doesn't crash for me though. Is this specific to a 32-bit platform? I'm > on 64-bit. All my experimentation has been on 64-bit, debian-wheezy in particular. Note well, however: (*) I am *assuming* that my and Julien's segfaults are related informatively to David's "Unknown Exception". (*) If the assumption is correct, then we are looking at really strange behaviour, as I summarized in comment 6. Additionally, we now have your lack of crash. Does the valgrind output shed any light on the situation? I shall test again after my next build, unless someone beats me to it.
(In reply to comment #14) > Does the valgrind output shed any light on the situation? It's full of java calls, and some sign of a presence of Java extensions and custom toolbars installed by them. Maybe the crash only triggers when you have some specific Java extensions installed? I'm using a dev build which typically has no extensions installed... Other than that, the valgrind output doesn't show anything from the Calc code itself.
Created attachment 98002 [details] console logs + bt with symbols On pc Debian x86-64 with master sources updated today (c6c286f14468d341f5fd88edc39a37175a1b6caa), I reproduced the crash at the opening. I attached the new bt which is a bit different.
No crash at the opening if I apply the fix on ScRight: diff --git a/sc/source/core/tool/interpr1.cxx b/sc/source/core/tool/interpr1.cxx index 0b523e8..67f3fbb 100644 --- a/sc/source/core/tool/interpr1.cxx +++ b/sc/source/core/tool/interpr1.cxx @@ -8091,7 +8091,7 @@ void ScInterpreter::ScRight() if (nParamCount == 2) { double nVal = ::rtl::math::approxFloor(GetDouble()); - if ( nVal < 0.0 || nVal > SAL_MAX_UINT16 ) + if ( rtl::math::isNan(nVal) || nVal < 0.0 || nVal > SAL_MAX_UINT16 ) { PushIllegalArgument(); return ; Ok to push this on master?
If I just do this: select a.a70:b70, then "Insert > Names > Create", then "OK" (and I select no checkbox) I got a popup telling: "Invalid Selection for range names" If I do the same but select "top" checkbox (and I didn't try the others), it's ok. Just for information, I noticed these kinds of logs during tests: warn:legacy.osl:5920:1:sc/source/core/data/formulacell.cxx:1838: no RPN code und no errors ?!?! warn:legacy.osl:5920:1:sc/source/core/data/formulacell.cxx:1574: ScFormulaCell::Interpret: no RPN, no error, no token, but hybrid formula string
Created attachment 98019 [details] valgrind with assertion at strtmpl.cxx:1231 I have started a build including Kohei's patch; ETA about 18 hours. Meanwhile, the attached file is console output from running LO with parameter --valgrind and with the file named on the command line. The crash happened while LO was opening the file. The output seems not be contaminated by java. Execution left me with a vgcore.<pid> of 18 MB. gdb tells me: segmentation fault, one thread, and the backtrace in its entirety ... #0 0x00000000000005d6 in ?? () #1 0x0000000004a226ed in ?? () #2 0x0000000000080a14 in ?? () #3 0x0000000004006a82 in ?? () #4 0x0000000000000000 in ?? ()
Alas, I still get the assertion with commit b08754f, fetched 2014-04-26 01:12 UTC.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b41504503cdf4ac562f82e668bf2fe9217260493 Related fdo#75971 Crash when invoking "Insert > Names > Create" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f24e3d480bb88a568de10b4d81116766b136c91&h=libreoffice-4-3 Related fdo#75971 Crash when invoking "Insert > Names > Create" It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With commit 0426306, fetched 2014-05-28 30:30 UTC, I no longer see a crash. However, as Kohei never saw the crash, I am not sure what my observation is worth. For now, I am leaving bug status NEW. David, Can you get a daily build and let us know if it works for you? Terry.
Put it at NEEDINFO since we're waiting for David's feedback.
David, Can you get a daily build and let us know if it works for you? Terry. I'm sorry, I think I'm out of my depth here. I'm looking at https://wiki.documentfoundation.org/Installing_in_parallel "Windows Version 3.5.z and newer: You downloaded one or more .msi-files: one for the program (LibO_<version>_Win_x86_multi.msi)," I can't find any such file in http://dev-builds.libreoffice.org/daily/libreoffice-4-3/ Advice welcome please on how to get a daily build of 4.3 working on Windows. David Lynch
David: in this case, you may give a try to master (future 4.4.0) daily build, see http://dev-builds.libreoffice.org/daily/master/. Of course, it's just for this specific test, not for your daily work since it's an dev version (not even beta)
On Windows 8.1, I cannot reproduce the bug using Version: 4.4.0.0.alpha0+ Build ID: b447687292334687a371b66d7ad56ba9662b898e TinderBox: Win-x86@42, Branch:master, Time: 2014-06-03_06:27:05 Many thanks for your efforts. On Windows 7, I can build this version of LO, but it aborts with the message MSVCR110.dll is not found. This appears to be bug 68756, which is marked as resolved. Can you suggest what I should do to get it working on Windows 7.
(In reply to comment #27) ... > On Windows 7, I can build this version of LO, but it aborts with the message > MSVCR110.dll is not found. This appears to be bug 68756, which is marked as > resolved. > > Can you suggest what I should do to get it working on Windows 7. Do you mean you're building from sources? If yes, you can find some help here: https://wiki.documentfoundation.org/Development/BuildingOnWindows
No, I'm following the instructions at https://wiki.documentfoundation.org/Installing_in_parallel
(In reply to comment #29) > No, I'm following the instructions at > https://wiki.documentfoundation.org/Installing_in_parallel So I don't understand your previous comment when you wrote: "on Windows 7, I can build this version of LO, but it aborts with the message MSVCR110.dll is not found." "Build" means "build binary from sources". For the test, could you: - rename your LO directory profile (to keep all your customizations) to create a backup - uninstall your current LO version on Win7 - install http://dev-builds.libreoffice.org/daily/master/ - give it a try - uninstall dev version - install the one you used - remove LO directory profile and use your backup (by renaming it back to its previous name) ?
(In reply to comment #30) > (In reply to comment #29) > > No, I'm following the instructions at > > https://wiki.documentfoundation.org/Installing_in_parallel > > So I don't understand your previous comment when you wrote: > "on Windows 7, I can build this version of LO, but it aborts with the > message MSVCR110.dll is not found." > "Build" means "build binary from sources". > > For the test, could you: > - rename your LO directory profile (to keep all your customizations) to > create a backup > - uninstall your current LO version on Win7 > - install http://dev-builds.libreoffice.org/daily/master/ > - give it a try > > - uninstall dev version > - install the one you used > - remove LO directory profile and use your backup (by renaming it back to > its previous name) > ? I have done this and I can't reproduce the bug on Windows 7 either. Many thanks again.
Thank you for your feedback David. I merged the 2 patches for 4.2, here's the changes waiting for review: https://gerrit.libreoffice.org/9645
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a9adf83582069308f7f98c5049256ea5e81c7c68&h=libreoffice-4-2 Resolves fdo#75971 Crash when invoking "Insert > Names > Create" It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So now let's put this at FIXED
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=14ce27cc045bd9bcbbfa3eac56cd99f2be08de1f unify the handling of string position arguments, fdo#75971 related The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=95d9e0641197164fedd2e89d40f5eb9607f87fc3&h=libreoffice-4-3 unify the handling of string position arguments, fdo#75971 related It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e49e49709935d594fa49cbccc4ffbcb4e90400f&h=libreoffice-4-2 unify the handling of string position arguments, fdo#75971 related It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (NotBibisectable) [NinjaEdit]