Bug 159961 - LibreOffice becomes unresponsive and crashes, accompanied by a significant increase in memory usage, when attempting to declare a new object instance of a class module, leading to severe data loss.
Summary: LibreOffice becomes unresponsive and crashes, accompanied by a significant in...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
7.6.5.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: QA:needsComment
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-29 12:50 UTC by Henrry John
Modified: 2024-03-15 03:15 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Henrry John 2024-02-29 12:50:16 UTC 
Description:
Note to Developers:
The code for reproducing the crash is provided in the "Steps to Reproduce" section. Please be aware of the potential data corruption and loss due to the abrupt termination of all LibreOffice instances. Exercise with caution when testing and reproducing this issue, and ensure that no critical or unsaved work is present to avoid unintended data loss.

Description:
After declaring an instance of the class module ('UserClass') using the line `Public Example As New UserClass` and executing the provided BASIC code, LibreOffice becomes unresponsive and crashes. The crash is accompanied by a significant increase in memory usage, resulting in LibreOffice freezing and abrupt termination of all instances. Notably, no crash report is generated, and there is no attempt at recovery, which raises concerns about potential data loss.

The issue persists regardless of the declaration scope (public, private, or global). This indicates that the problem is not limited to a specific declaration context. Moreover, whether the declaration is within the class module itself or in a separate module, the crash occurs consistently. This would suggest that the problem might not be specific to the class module itself but rather it might be related to the instantiation of objects from the class.

Steps to Reproduce:
1. Open LibreOffice and create a new Basic module named "UserClass"
2. Add the following Basic subroutine
```basic
Option Explicit
Option Compatible
Option ClassModule '''UserClass'''
REM Uncommenting the following line causes LibreOffice to become unresponsive
REM Public Example As New UserClass
Property Get ExampleProperty As String
    ExampleProperty = "Example String"
End Property
Sub TestRun
    REM Include the below code to ensure the entire class functions properly.
    REM Comment it out as well as uncommented the above problematic code to reproduce the crash.
    Dim Example As New UserClass
    MsgBox Example.ExampleProperty
End Sub`
3. Uncomment the line `Public Example As New UserClass` as well as comment out the line `Dim Example As New UserClass`
4. Compile and execute the "TestRun" method.
Additional steps to reproduce the crash in different module.
5. Create a new Basic module within the same library as the "UserClass" module.
6. Add the following Basic subroutine:
```basic
Option Explicit
REM Uncommenting the following line causes LibreOffice to become unresponsive
REM Public Example As New UserClass
Sub TestRun
    REM Include the below code to ensure the entire class functions properly.
    REM Comment it out as well as uncommented the above problematic code to reproduce the crash.
    Dim Example As New UserClass
    MsgBox Example.ExampleProperty
End Sub`
7. Uncomment the line `Public Example As New UserClass` as well as comment out the line `Dim Example As New UserClass`.
8. Compile and execute the "TestRun" subroutine.



Actual Results:
LibreOffice becomes unresponsive, with an observed increase in memory usage. No crash report or recovery attempt is initiated. All LibreOffice instances terminate abruptly, leading to data loss.

Expected Results:
LibreOffice should handle the declaration of a new object instance without becoming unresponsive. The software should not terminate abruptly, and users should not experience data loss.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b
CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded Jumbo
Comment 1 Henrry John 2024-02-29 13:34:27 UTC 
Personal insights of the matters:

The crash appears to occur before any opportunity for manual or automatic cleanup processes. Since the object instance is declared outside the scope of any subroutines or functions, both manual cleanup (using `Nothing`) and automatic cleanup via garbage collection might not be triggered. This lack of cleanup could lead to a memory leak, possibly explaining the unresponsiveness and crash of all LibreOffice instances and the sudden spike in memory usage.

In situations where crashes happen during the instantiation phase, understanding how the BASIC interpreter allocates and manages memory for class objects, especially when declared globally or at a module level, becomes crucial.

It's important to note that these insights are speculative, providing a hypothesis for consideration. The real root cause may lie elsewhere in the handling of class objects within the LibreOffice BASIC interpreter. Further analysis of the interpreter's internals is necessary for a conclusive understanding of the issue.
Comment 2 Henrry John 2024-02-29 15:30:37 UTC 
**New Information and Steps to Mitigate the Crash:**
After in-depth testing and profile resets, I observed a notable behavior related to the crash. Specifically, excluding the "TestRun" method and the problematic instantiation code within the "UserClass" module seems to prevent the crash. This discovery suggests a potential correlation between the crash and the action of declaring an instance of the "UserClass" within the "UserClass" module itself.

**Steps to Mitigate the Crash:**
1. Open LibreOffice and navigate to the "UserClass" module.
2. Exclude the "TestRun" method and the problematic instantiation code.
3. Save and compile the modified code.
4. Execute the modified code and observe if the crash still occurs.

**Analysis and Insights:**
The exclusion of the "TestRun" method appears to be a workaround to mitigate the crash. This aligns with the hypothesis that the crash might be related to the instantiation of the class within its own module. 

As mentioned in a previous comment, the potential issue could be akin to recursion, where the object creates an instance of the class, and the class itself tries to create an object instance of itself, leading to resource over-utilization and the subsequent crash of LibreOffice instances.

Notably, in a new module within the same library as "UserClass," declaring the instance of "UserClass" outside the scope of subs or functions encountered no issues. This could indicate that the problem might be specific to certain instantiation contexts within the same module.

**Potential Implications and Future Considerations:**
If the hypothesis regarding the recursion-like issue is confirmed, it would be advisable to implement a mechanism preventing users from inadvertently creating such recursion. This could involve introducing safeguards in the BASIC interpreter to detect and handle instances of potential recursion during class instantiation.

**Additional Notes:**
These steps serve as a temporary mitigation measure and do not address the root cause of the issue. Further analysis of the LibreOffice BASIC interpreter's handling of class instantiation within the same module is necessary for a comprehensive resolution.

Reproducible: Yes (Mitigated)