<div dir="ltr"><div id="gmail-:3cv" class="gmail-ii gmail-gt"><div id="gmail-:3cw" class="gmail-a3s gmail-aiL"><div dir="ltr"><div dir="ltr"><div><span style="font-family:monospace">Hi everyone,<br><br>This week marks a critical turning point in our Object Browser investigation.<br>We've completed a comprehensive four-phase analysis that has fundamentally<br>changed our understanding of the crash patterns. While we've made significant<br>progress in stabilizing the IDE, we've also uncovered a new crash scenario<br>that requires immediate attention.<br><u><br><b>Gerrit Patches</b></u><br><b><br>Patch 28 (Week 10): Thread-Safe Initialization System</b><br> <a href="https://gerrit.libreoffice.org/c/core/+/186822/28" target="_blank">https://gerrit.libreoffice.org/c/core/+/186822/28</a><br><br><u>The Problem: <span class="gmail_default"></span>Slaying the Initialization Hydra<span class="gmail_default"> </span></u><u><span class="gmail_default">a</span> Multi-Headed Beast</u><br><br>Our previous initialization system was fundamentally flawed. Multiple threads<br>could trigger initialization simultaneously, creating a race condition that<br>manifested as:<br><br>info:basctl:96852:430736002:</span><span style="font-family:monospace">basctl/source/basicide/</span><span style="font-family:monospace">idedataprovider.cxx:60: UnoHierarchyInitThread starting<br>info:basctl:96852:430736003:</span><span style="font-family:monospace">basctl/source/basicide/</span><span style="font-family:monospace">idedataprovider.cxx:60: UnoHierarchyInitThread starting<br>info:basctl:96852:430736014:</span><span style="font-family:monospace">basctl/source/basicide/</span><span style="font-family:monospace">idedataprovider.cxx:60: UnoHierarchyInitThread starting<br><br><u>This chaotic initialization caused:</u><br>- Severe performance degradation (6+ second startup times)<br>- Resource conflicts between competing threads<br>- IDE freezing during startup<br><br><u>The Solution: A Coordinated State Machine</u><br><br>We implemented a sophisticated thread-safe initialization system using modern<br>C++ concurrency primitives:<br><br>// New Architecture: Double-Checked Locking Pattern<br>enum class InitState { NotInitialized, Initializing, Initialized, Failed, Disposed };<br><br>void ObjectBrowser::Initialize()<br>{<br> // Fast lock-free check first<br> InitState currentState = m_eInitState.load();<br> if (currentState == InitState::Initialized || currentState == InitState::Initializing)<br> return;<br> <br> // Acquire lock for definitive check<br> std::unique_lock<std::mutex> lock(m_InitMutex);<br> currentState = m_eInitState.load();<br> if (currentState == InitState::Initialized || currentState == InitState::Initializing)<br> return;<br> <br> // Set state while holding lock, then release for long operation<br> m_eInitState.store(InitState::</span><span style="font-family:monospace">Initializing);<br> lock.unlock();<br> <br> // ... safe initialization ...<br>}<br><br>void IdeDataProvider::</span><span style="font-family:monospace">AsyncInitialize(...)<br>{<br> // Atomic compare-and-swap ensures single initialization<br> if (!m_bInitializationInProgress.</span><span style="font-family:monospace">compare_exchange_strong(</span><span style="font-family:monospace">expected, true))<br> return; // Only first thread succeeds<br>}<br><br><u>The Result: Order from Chaos</u><br><br>After Patch 28 - Clean, Sequential Initialization:<br>info:basctl:79942:495124713:</span><span style="font-family:monospace">basctl/source/basicide/</span><span style="font-family:monospace">idedataprovider.cxx:60: UnoHierarchyInitThread starting<br>info:basctl:79942:495124973:</span><span style="font-family:monospace">basctl/source/basicide/</span>idedataprovider.cxx<span style="font-family:monospace">:141: UnoHierarchyInitThread completed in 1162 ms<br><br>Performance transformation:<br>- 80% reduction in initialization time (6+ seconds → ~1.2 seconds)<br>- Single, controlled initialization thread<br>- Eliminated resource conflicts and race conditions</span></div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b>Patch 29 (Week</b><b> 10<span class="gmail_default">-11</span>): Deadlock Fix in Data Provider Callback</b><br> <a href="https://gerrit.libreoffice.org/c/core/+/186822/29" target="_blank">https://gerrit.libreoffice.org/c/core/+/186822/29</a></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b>Thread 0x1f10d90f (Main Thread):</b></span></div><div><span style="font-family:monospace">
basctl::ObjectBrowser::</span><span style="font-family:monospace">RefreshUI(bool)
<br></span></div><div>basctl<span style="font-family:monospace">::IdeDataProvider::</span><span style="font-family:monospace">GetTopLevelNodes()</span></div><div><span style="font-family:monospace">
std::__1::lock_guardstd::__1::</span><span style="font-family:monospace">mutex::lock_guard</span></div><div><span style="font-family:monospace"><br></span></div><div><b style="font-family:monospace">
Thread 0x1f1147f9 (Background Thread):</b></div><div><span style="font-family:monospace">
basctl::IdeDataProvider::</span><span style="font-family:monospace">UnoHierarchyInitThread::run()</span></div><div><span style="font-family:monospace">
basctl::ScriptDocument::</span><span style="font-family:monospace">getLibraryNames()
</span></div><div><span style="font-family:monospace">basic::SfxLibraryContainer::</span><span style="font-family:monospace">getElementNames()</span></div><div><span style="font-family:monospace">
basic::SfxLibraryContainer::</span><span style="font-family:monospace">enterMethod()
<br></span></div><div>comphelper<span style="font-family:monospace">::SolarMutex::</span><span style="font-family:monospace">acquire()</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"> <u>Problem: Subtle deadlock in IdeDataProvider::AsyncInitialize</u><br> Solution: Improved thread synchronization with atomic compare-and-swap:<br> void basctl::IdeDataProvider::</span><span style="font-family:monospace">AsyncInitialize(...)<br> {<br> m_pThreadController = pController;<br> bool expected = false;<br><br> // Atomic compare-and-swap ensures only one thread starts initialization<br> if (!m_bInitializationInProgress.</span><span style="font-family:monospace">compare_exchange_strong(</span><span style="font-family:monospace">expected, true))<br> {<br> // If already completed, call callback immediately<br> if (m_bInitialized)<br> Application::PostUserEvent(</span><span style="font-family:monospace">rFinishCallback);<br> return;<br> }<br> // Create and start initialization thread<br> }</span></div><div><span style="font-family:monospace"><br></span></div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><div><span class="gmail_default" style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b>Patch 30 (Week 1<span class="gmail_default">1</span>): Enhanced Disposal Order</b><br> <a href="https://gerrit.libreoffice.org/c/core/+/186822/30" target="_blank">https://gerrit.libreoffice.org/c/core/+/186822/30</a></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"> <u>Problem: TaskPanelList registration failures and disposal order</u><br> Solution: Comprehensive disposal sequence:<br> void ObjectBrowser::dispose()<br> {<br> // 1: Atomic Guard to prevent re-entry<br> bool expected = false;<br> if (!m_bDisposed.compare_</span><span style="font-family:monospace">exchange_strong(expected, true))<br> return;<br> <br> // 2: Check parent hierarchy validity<br> if (!GetParent() || !GetParent()->GetSystemWindow(</span><span style="font-family:monospace">))<br> {<br> // Minimal cleanup if parent is gone<br> DockingWindow::dispose();<br> return;<br> }<br> <br> // 3: Remove pending events and hide<br> EnableInput(false);<br> Hide();<br> Application::</span><span style="font-family:monospace">RemoveMouseAndKeyEvents(this);<br> Application::Reschedule(true);<br> <br> // 4: Update state machine<br> m_eInitState.store(InitState::</span><span style="font-family:monospace">Disposed);<br> m_InitCV.notify_all();<br> <br> // 5: Unregister from TaskPanelList BEFORE widget disposal<br> if (GetParent() && GetParent()->GetSystemWindow()</span><span style="font-family:monospace">)<br> {<br> TaskPaneList* pTaskPaneList = GetParent()->GetSystemWindow()</span><span style="font-family:monospace">->GetTaskPaneList();<br> if (pTaskPaneList)<br> pTaskPaneList->RemoveWindow(</span><span style="font-family:monospace">this);<br> }<br> <br> // 6: Comprehensive cleanup of all resources<br> // ... widget disposal, thread cancellation, etc. ...<br> }</span></div><div><span style="font-family:monospace"><b><u><br></u></b></span></div><div><span style="font-family:monospace"><b><u><br></u></b></span></div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><div><span style="font-family:monospace"><b><u><br></u></b></span></div><div><span style="font-family:monospace"><b><u>The Four Investigation Phases: A Systematic Approach</u></b><br><br><b>I. Investigation Phase 1: Initial Disposal Fixes</b><br><br><b>The Problem:</b><br>We began with a classic use-after-free crash in the macOS event system:<br><br>Thread 0 Crashed:: Dispatch queue: com.apple.main-thread<br>0 libsystem_kernel.dylib 0x18be51388 __pthread_kill + 8<br>1 libvclplug_osxlo.dylib 0x1208e44d4 <b>-[SalFrameView mouseDown:] + 76</b><br><br><b>Root Cause Analysis:</b><br>The crash occurred because mouse events were being delivered to a disposed<br>window object. macOS Cocoa maintains references to view objects even after<br>logical disposal, creating a race condition between VCL's disposal and<br>Cocoa's event delivery.<br><br><b>Initial Fix Attempts:</b><br>- Added atomic disposal flag (m_bDisposed) to prevent re-entry<br>- Added EnableInput(false) and Hide() calls<br>- Added Application::</span><span style="font-family:monospace">RemoveMouseAndKeyEvents(this)<br>- Added event handler disconnection<br><br><b>Result:</b> Crash persisted with the same signature, indicating deeper issues.<br><br><b>Diagram:</b> Initial Disposal Problem<br><br> VCL Disposal Cocoa Event System<br> ----------- ----------------<br> | dispose() | ----> | Event Queue |<br> ----------- ----------------<br> | |<br> v v<br> | Object freed | | Events still |<br> | (C++) | | referencing <span class="gmail_default"> </span>|<br> | disposed obj |<br> ----------------<br></span><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span><br><b>II. Investigation Phase 2: Deep Analysis and Pattern Recognition</b><br><b><br>The Breakthrough:</b><br>Research into LibreOffice's VCL architecture revealed critical patterns:<br><br>1. Frame Tracking System: <i>AquaSalFrame</i> objects are registered when created<br> and deregistered when destroyed.<br><br>2. Frame Validity Checking: The system uses AquaSalFrame::isAlive() checks<br> throughout the codebase.<br><br>3. Standard Disposal Pattern: Other VCL components follow a specific<br> disposal sequence.<br><br><b>Key Discovery:</b> Parent-Child Window Relationship Issue<br><br>The real problem wasn't just in the ObjectBrowser, but in the entire window<br>hierarchy:<br><br>1. Basic Macros dialog (parent) opens<br>2. Basic Macros dialog opens IDE (child)<br>3. IDE creates ObjectBrowser (grandchild)<br>4. User closes IDE - ObjectBrowser disposed<br>5. Critical Issue: ObjectBrowser not properly removed from VCL frame tracking<br>6. User closes Basic Macros dialog (parent)<br>7. CRASH: Basic Macros dialog tries to access dangling frame references<br><br><u>Diagram: Window Hierarchy Problem</u><br><br> [Basic Macros Dialog] (Parent)<br> |<br> v<br> [IDE Window] (Child)<br> |<br> v<br> [ObjectBrowser] (Grandchild) <-- Disposed but not deregistered<br> |<br> v<br> [VCL Frame Tracking] <-- Still has reference to disposed ObjectBrowser<br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">+---------------------------+ +---------------------------+<br>| Main UI Thread | | Background Thread |<br>|---------------------------| |---------------------------|<br>| 1. Acquires SolarMutex | | 3. Needs to get macros |<br>| (for UI/doc access) | | |<br>| | | 4. Tries to acquire |<br>| 2. Waits for Background | <---- | SolarMutex (BLOCKED!) |<br>| Thread to finish. | ----> | |<br>| (BLOCKED!) | | 5. Waits for Main Thread |<br>| | | to release lock. |<br>+---------------------------+ +---------------------------+`</span><span style="font-family:monospace">``<br><br>**The Fix (Patch 29):** We re-architected the data loading. The background<br>thread was simplified to *only* perform the thread-safe task of building the<br>UNO API cache. The non-thread-safe work of querying Basic macros was moved to<br>the `OnDataProviderInitialized` handler, which executes safely on the main<br>thread. This successfully resolved the deadlock.<br><br>// -- PATCH 29: DEADLOCK FIX --<br>IMPL_LINK(ObjectBrowser, OnDataProviderInitialized, void*, /* p */, void)<br>{<br> // This now runs safely on the Main Thread<br> // 1. Create a list of top-level nodes...<br> // 2. Add UNO APIs node (data is ready from background)...<br> // 3. Add Application/Document Macros (safe to query now)...<br> // 4. Set complete data and build indexes ONCE...<br> // 5. Refresh UI...<br>}</span></div><div><span class="gmail_default" style="font-family:monospace"></span></div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><div><span style="font-family:monospace"><b>III. Investigation Phase 3: Mouse Drag Timer Crash</b><br><br><b>New Crash Pattern:</b><br>The problem evolved from simple use-after-free to memory corruption:<br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">Thread 0 Crashed::<br>...<br>6 libvclplug_osxlo.dylib <b>-[SalFrameView mouseDraggedWithTimer:] + 100</b><br>7 Foundation __NSFireTimer + 104<br>...</span></div><div><span style="font-family:monospace"><b><br></b></span></div><div><span style="font-family:monospace"><b>Exception Type:</b> EXC_BAD_ACCESS (SIGSEGV)<br><b>Exception Codes: </b>KERN_INVALID_ADDRESS at 0x00001cb5987c0bde<br><br><b>Root Cause:</b> Incomplete cleanup of macOS-specific resources, particularly<br>timer-based mouse drag operations.<br><br><b>Evidence from Code:</b><br>The SalFrameView creates NSTimers for mouse drag events:<br><br>-(void)mouseDragged: (NSEvent*)pEvent<br>{<br> [self clearPendingMouseDraggedEvent]</span><span style="font-family:monospace">;<br> mpPendingMouseDraggedEvent = [pEvent retain];<br> if ( !mpMouseDraggedTimer )<br> {<br> mpMouseDraggedTimer = [NSTimer scheduledTimerWithTimeInterval</span><span style="font-family:monospace">:0.025f<br> target:self selector:@selector(</span><span style="font-family:monospace">mouseDraggedWithTimer:) <br> userInfo:nil repeats:YES];<br> }<br>}<br><br>These timers can fire after disposal, accessing freed memory.<br><u><br>Diagram: Timer-Based Crash<span class="gmail_default">(My Understanding)</span></u><br><br> Mouse Drag Event<br> |<br> v<br> [NSTimer Created] --> [SalFrameView]<br> | |<br> v v<br> [0.025s Interval] [ObjectBrowser Disposed]<br> | |<br> v v<br> [Timer Fires] -------> [CRASH: Accessing freed memory]<br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b><br></b></span></div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><div><span style="font-family:monospace"><b>IV. Investigation Phase 4: Delayed Disposal Experiment</b><br><u><br>The Hypothesis:</u><br>Perhaps the issue was timing-related. If we delayed disposal, maybe the<br>Cocoa event system would have time to clean up.<br><br><u>Implementation:</u><br>We implemented a delayed disposal pattern:<br><br>void ObjectBrowser::dispose()<br>{<br> // Immediate cleanup<br> Hide();<br> Application::PostUserEvent(</span><span style="font-family:monospace">LINK(this, ObjectBrowser, DelayedDisposeHandler));<br>}<br><br>IMPL_LINK(ObjectBrowser, DelayedDisposeHandler, void*, /*p*/, void)<br>{<br> // Actual disposal happens later<br> performActualDisposal();<br>}<br><br><u>Expected Outcome:</u><br>- Prevent mouse event crashes by allowing proper cleanup<br>- Maintain VCL frame tracking<br>- Allow clean IDE closure<br><br><u>Actual Result: New Problems Introduced</u><br>1. Mouse Event Crash Fixed: Original crashes no longer occurred<br>2. New Problem: UI Artifacts and Freezing<br> - ObjectBrowser disappeared but left visual artifact<br> - IDE became unresponsive, showing <NO_MODULE><br> - Document Recovery UI appeared<br> - IDE reloaded instead of closing cleanly<br><u><br>Root Cause:</u> VCL Synchronous vs. Asynchronous Conflict<br><br>VCL expects immediate disposal:<br> Parent Layout -> Child Disposal -> Layout Update<br><br>Delayed disposal broke this contract:<br> Parent Layout -> Child Scheduled for Disposal -> Layout Updates<br> (but child still exists)<br><br><u>Diagram: Delayed Disposal Conflict</u><br><br> VCL Expectation:<br> [Layout] -> [Dispose Child] -> [Update Layout]<br><br> Delayed Disposal Reality:<br> [Layout] -> [Schedule Dispose] -> [Update Layout]<br> |<br> v<br> [Child still exists]<br> |<br> v<br> [<NO_MODULE> displayed]<br></span></div><div><span style="font-family:monospace"><br></span></div><div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div></div><div><span style="font-family:monospace"><b><u><br></u></b></span></div><div><span style="font-family:monospace"><b><u>New Discovery: Ghost Parent UI Crash</u></b><br><u><br>The Scenario:</u><br>We identified two distinct workflows with different outcomes:<br><br><u>Scenario A (Works Correctly):</u><br>- Context: A document (Calc) is open<br>- Action: Tools > Macros > Edit<br>- Result: BASIC Macros dialog closes, IDE opens cleanly<br>- When closing IDE, everything shuts down properly<br><u><br>Scenario B (Crashes):</u><br>- Context: No document is open (global soffice context)<br>- Action: Tools > Macros > Edit<br>- Result: IDE opens, but BASIC Macros dialog remains open in background<br>- Clicking on this "ghost parent" window causes the mouseDown crash<br><br><u>ASCII Diagram: Ghost Parent Problem</u><br><br> With Document Context: Without Document Context:<br> [Calc Document] [No Document]<br> | |<br> v v<br> [BASIC Macros] [BASIC Macros] <-- Ghost Parent<br> | |<br> v v<br> [IDE Opens] [IDE Opens]<br> | |<br> v v<br> [Parent Closes] [Parent Stays]<br> |<br> v<br> [Click on Parent]<br> |<br> v<br> <span class="gmail_default"> </span>[CRASH]<br><br><u>Root Cause Analysis:</u><br>The issue is that the BASIC Macros dialog is being put into a "zombie" state<br>when no document is open. It's not properly closed when the IDE opens,<br>leaving it in the window hierarchy with an inconsistent state.</span></div><div><span class="gmail_default" style="font-family:monospace"><br></span></div><div><b style="font-family:monospace"><span class="gmail_default">// In </span>sfx2/source/appl/appserv.cxx<span class="gmail_default"></span></b></div><div><span style="font-family:monospace"><b><br></b></span></div><div><span style="font-family:monospace"><b><span class="gmail_default"></span></b>#if HAVE_FEATURE_SCRIPTING<br> case SID_BASICIDE_APPEAR:</span></div><span style="font-family:monospace"> <span class="gmail_default"> { }</span></span><div><span style="font-family:monospace"><br></span></div><div><div class="gmail_default"><span style="font-family:monospace">and</span></div></div><div><span style="font-family:monospace"> case SID_MACROORGANIZER:<br> {<br> SAL_INFO("sfx.appl", "handling SID_MACROORGANIZER");<br> const SfxItemSet* pArgs = rReq.GetArgs();<br> sal_Int16 nTabId = 0;<br> Reference <XFrame> xFrame;<br> if (pArgs)<br> {<br> if (const SfxUInt16Item* pItem = pArgs->GetItemIfSet(SID_</span><span style="font-family:monospace">MACROORGANIZER, false))<br> nTabId = pItem->GetValue();<br> if (const SfxBoolItem* pItem = rReq.GetArg<SfxBoolItem>(FN_</span><span style="font-family:monospace">PARAM_2))<br> {<br> // if set then default to showing the macros of the document associated<br> // with this frame<br> if (pItem->GetValue())<br> xFrame = GetRequestFrame(rReq);<br> }<br> }<br> SfxApplication::</span><span style="font-family:monospace">MacroOrganizer(rReq.</span><span style="font-family:monospace">GetFrameWeld(), xFrame, nTabId);<br> rReq.Done();<br> }<br> break;</span></div><div><span class="gmail_default" style="font-family:monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace"><br></span></div><div><b style="font-family:monospace">// In vcl/osx/<a href="http://salframeview.mm" target="_blank">salframeview.mm</a></b></div><div><span style="font-family:monospace">-(void)mouseDown: (NSEvent*)pEvent<br>{<br> if ( mpMouseEventListener != nil &&<br> [mpMouseEventListener respondsToSelector: @selector(mouseDown:)])<br> {<br> [mpMouseEventListener mouseDown: pEvent];<br> }<br><br> s_nLastButton = MOUSE_LEFT;<br> [self sendMouseEventToFrame:pEvent button:MOUSE_LEFT eventtype:SalEvent::</span><span style="font-family:monospace">MouseButtonDown];<br>}</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><u><b><br></b></u></span></div><div><span style="font-family:monospace"><u><b>Current Status & Next Steps</b></u><br>Successfully Resolved:<br>1. IDE Shutdown Crashes - Eliminated through proper disposal order (Patch 30)<br>2. Multiple Initialization Threads - Solved with performance gains (Patch 28)<br>3. Deadlock in Data Provider - Fixed with proper callback handling (Patch 29)<br><br><b><u>Critical Issues Remaining:</u></b><br>1. Ghost Parent UI Crash (NEW CRITICAL PRIORITY)<br> - Occurs when opening IDE without a document context<br> - Clicking on the lingering BASIC Macros dialog causes crash<br> - Requires immediate investigation and fix<br><br>2. Mouse Event Crashes Post-Disposal (HIGH PRIORITY)<br><br>3. History Navigation Failures (MEDIUM PRIORITY)<br> - Back/forward buttons become disabled after first use<br> - History system doesn't preserve full UI state</span></div><div><span style="font-family:monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace">4</span><span style="font-family:monospace">. <span class="gmail_default">Breaking down this large single patch in multiple chronological pa</span><span class="gmail_default">tches.</span></span></div><div><span style="font-family:monospace"><b><br></b></span></div><div><span class="gmail_default" style="font-family:monospace">5</span><span style="font-family:monospace">. <span class="gmail_default">In Right Pane when we double click on an element it should open the API Page window.</span></span></div><div><span style="font-family:monospace"><b><br></b></span></div><div><span style="font-family:monospace">3. <span class="gmail_default">Adding a small delay in search and make search results better & include Macros results too.</span><br><br></span></div><div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div></div><div><span style="font-family:monospace"><b><br></b></span></div><div><span style="font-family:monospace"><b>Next Steps for Week 12:</b><br>Priority 1: Ghost Parent UI Investigation<br>- Determine why BASIC Macros dialog doesn't close in no-document context<br>- Implement proper dialog closure when IDE opens from global context<br>- Test both document and no-document scenarios<br><br>Priority 2: Enhanced Event Handler Cleanup<br>- Review all event connections in ObjectBrowser<br>- Ensure complete disconnection in disposal method<br>- Add frame validity checks to SalFrameView mouse handlers<br><br>Priority 3: Patch Breakdown Strategy<br>- Break large patches into smaller, focused changes<br>- Enable incremental review and testing by community<br></span></div><div><span style="font-family:monospace"><br></span></div><div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><span style="font-family:monospace"><br></span></div><div><b style="font-family:monospace"><u>Technical Evolution: Lessons Learned</u></b></div><div><span style="font-family:monospace"><br>1. Disposal Order is Critical<br> The sequence of operations in dispose() matters immensely.<br> TaskPanelList removal must happen early.<br><br>2. Thread Safety Requires Multiple Layers<br> Single boolean flags are insufficient.<br> Need atomic operations, mutexes, and condition variables.<br><br>3. macOS Event System is Complex<br> Timer-based events can outlive object disposal.<br> Need comprehensive cleanup of all native resources.<br><br>4. Context Matters<br> The same action can have different results depending on<br> application state (document vs. no-document context).<br></span></div><div><span style="font-family:monospace"><br></span></div><div><div><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace">-<span class="gmail_default">-------------------------------------------------------------------------------</span></span></div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b>Conclusion</b><br><br>Our four-phase investigation has provided deep insights into the complex<br>interactions between VCL and macOS. While we've made significant progress in<br>stabilizing the Object Browser, the discovery of the ghost parent UI crash<br>shows that there are still fundamental issues to resolve.<br><br>The architectural improvements in thread safety and disposal management provide<br>a strong foundation, but we must now address the window lifecycle management<br>issues that cause the ghost parent problem.<br><br>Thanks to mentors for their invaluable guidance throughout this complex<br>investigation.<br></span></div><div><span style="font-family:monospace"><br></span></div><div><div><div class="gmail_default"><div class="gmail_default"><span style="font-family:monospace">The point is the crash which we are seeing is not happening after patch ~26 is with the<br>BASIC IDE rather it is happening with the IDEs parent BASIC Macro UI Window if I am opening it via<br></span></div><div class="gmail_default"><span style="font-family:monospace">the main soffice(LibreOfficeDev) UI</span></div><span style="font-family:monospace"><br></span></div><div class="gmail_default"><font size="4" style="font-family:monospace">Here is the video link to understand better what is exactly going on -</font><span style="font-family:monospace"><br><font size="4"><br><a href="https://www.youtube.com/watch?v=gTwWkYQKLxk" target="_blank">https://www.youtube.com/watch?v=gTwWkYQKLxk</a></font></span></div><span style="font-family:monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace">I do was having this thought about this ghost parent Ui window remaining that it wasn't used to there when</span></div><div><span class="gmail_default" style="font-family:monospace">I started working on after opening the IDE but now I am assured that the IDE with the New OB is closing</span></div><div><span class="gmail_default" style="font-family:monospace">well and now we can break this patch chronologically so that others in community can test it :)<br></span></div><div><span class="gmail_default" style="font-family:monospace">and can do the remaining UI/UX polish and the major part which is code suggestions can be done quickly.</span></div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><b>Previous Updates:</b><br><br>Week 1: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html</a><br><br>Weeks 2-3: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html</a><br><br>Week 4: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html</a><br><br>Week 5: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html</a><br><br>Week 6: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html</a><br><br>Week 7: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html</a><br><br>Week 8: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-July/093572.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-July/093572.html</a><br><br>Week 9-10: <a href="https://lists.freedesktop.org/archives/libreoffice/2025-August/093662.html" target="_blank">https://lists.freedesktop.org/archives/libreoffice/2025-August/093662.html</a><br></span></div><div><span style="font-family:monospace"><br></span></div><div><div class="gmail_default"><span style="font-family:monospace">If there is any mistake or something I missed in my understanding do let me know :)</span></div><font color="#888888" style="font-family:monospace"><br></font></div><font color="#888888" style="font-family:monospace"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><b>Regards,</b></div><div><span style="color:rgb(153,0,255)"><b>Devansh</b></span><br></div></div></div></font></div><div class="gmail-adL">
</div></div><div class="gmail-adL">
</div></div></div><div id="gmail-:3co" class="gmail-hq gmail-gt"><div class="gmail-hp"><span style="font-family:monospace"><br></span></div></div></div>