On Sat, May 18, 2024, at 9:52 AM, Alexander Dunlap wrote:
> On Sat, May 18, 2024, at 2:30 AM, Niranjana K M wrote:
>> Dear LyX developers,
>> Thank you and congratulations for heading towards much awaited LyX-2.4.
>> I have been using LyX-2.4-RC1 from last 6 months and yesterday accidentally
>> i caught this strange behavior. And I even installed recently released
>> LyX-2.4 and the behavior persisted in this version also. But i am not facing
>> this problem in LyX-2.3.7.
>> The problem is, when I try to copy, by selecting and pressing Ctrl+C (or
>> Copy from edit menu), a math block which is boxed and also having deep
>> nested subscripts to at least 4 levels then my computer memory rapidly got
>> consumed to the full (starting from 1GB to ~10GB) and in the end LyX closed
>> with following message.
>>
>> $ /usr/local/bin/lyx
>> Error: Software exception Detected
>> ----------------------------------------
>> LyX has caught an exception, it will now attempt to save all unsaved
>> documents and exit.
>> Exception: std::bad_alloc
>> Aborted
>>
>> Following is the math block which caused it, (LyX code)
>> \begin_inset Formula
>> \[
>> \boxed{v=\left[v_{p}\right]_{a_{0}}}
>> \]
>> \end_inset
>>
>> The file is also attached in the end and here is the screenshot of the math
>> block.
>> Screenshot from 2024-05-18 11-43-00.png
>>
>> It is a legitimate construction and it gives no problem in LyX-2.3.7
>> (confirmed).
>> If either the box is removed or the subscript 0 is removed from *a*, then it
>> has no issues in copying.
>>
>> All these versions I mentioned were compiled from source on Gentoo Linux.
>> This LyX-2.4 was compiled with the following configuration,
>> $ ./configure --without-included-boost
>> Configuration
>> Host type: x86_64-pc-linux-gnu
>> Special build flags: build=release callback-printing use-hunspell
>> use-aspell use-enchant
>> Bundled libraries: nod
>> C++ Compiler: g++ (13.2.1)
>> C++ Compiler flags: -fPIC -O2 -std=c++17
>> C++ Compiler user flags: -std=c++17 -march=native -O2 -pipe
>> Linker flags: -rdynamic
>> Linker user flags:
>> Qt Frontend:
>> Qt version: 5.15.11
>> Packaging: posix
>> LyX binary dir: /usr/local/bin
>> LyX files dir: /usr/local/share/lyx
>>
>> I loved the new features in LyX-2.4 and don't want to go back to LyX-2.3.7
>> due to this issue. Please help in this regard.
>
> I can reproduce this. I investigated a little and it seems that the problem
> is that the "while (true)" loop in the splitAndWrapInMText function in
> InsetMathBox.cpp is never terminating. I believe that the reason for this is
> that the logic in this function is not correctly identifying the matching
> XHTML end tag for a given start tag, since it doesn't take into account
> nested tags properly.
Here is a patch that fixes the problem for me. It needs extensive
checking/testing though because I do not know too much about XHTML or what all
sorts of input might be seen in this function.
>
>
>>
>> *Regards*
>> *Niranjana*
>> --
>> lyx-devel mailing list
>> lyx-devel@lists.lyx.org
>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>
>>
>> *Attachments:*
>> • test.24.lyx
>
From a9d3e6f960265b9097a321ab8fdff41658e31b96 Mon Sep 17 00:00:00 2001
From: Alexander Dunlap <alexander.dun...@gmail.com>
Date: Sat, 18 May 2024 10:12:04 -0400
Subject: [PATCH] Improving logic in splitAndWrapInMText
---
src/mathed/InsetMathBox.cpp | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index 6feddf9cdd..4295ac0780 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -101,9 +101,32 @@ void splitAndWrapInMText(MathMLStream & ms, MathData const & cell,
const std::size_t tag_name_length = tag_name_end - 1;
const docstring tag_name = inset_contents.substr(1, tag_name_length);
- const std::size_t end_tag_start =
- inset_contents.find(tag_name, tag_name_end + 1);
- const std::size_t end_tag = inset_contents.find('>', end_tag_start);
+ // Here we find the matching end tag. We need to take into
+ // account that there may be new tags with the same name opening // up.
+ int depth = 0;
+ std::size_t end_tag = tag_name_end;
+ std::size_t end_tag_start;
+ while (true) {
+ // Find the next tag with the name we are looking for
+ end_tag_start = inset_contents.find(tag_name, end_tag + 1);
+ end_tag = inset_contents.find('>', end_tag_start);
+ if (inset_contents[end_tag_start-1] == '/') {
+ // if it's a closing tag, then reduce the depth, or if
+ // we are already at depth 0, then we have found the
+ // matching tag
+ if (depth == 0) {
+ break;
+ } else {
+ depth--;
+ }
+ } else {
+ // if it's not a closing tag, then it's a nested opening
+ // tag, so we increase the depth: now we need an
+ // additional closing tag before we have found the
+ // matching one
+ depth++;
+ }
+ }
parts.emplace_back(inset_contents.substr(0, end_tag + 1));
inset_contents = inset_contents.substr(end_tag + 1);
--
2.45.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
