This was reported to the Debian bug tracking system. I can still reproduce it with LO 3.5.2:
Detailed steps on how to reproduce it and the affected XLS are are provided in the Debian bug report:
I have confirmed this as well. I have no clue if this will be addressed as it's so specific to a particular macro enabled page that I personally have no clue what it's intended purpose is.
Markig as NEW and prioritzing:
Major: I'm hesitant to mark this as Major but since it causes a crash, I'm going by my normal flowchart and marking it as so.
Lowest: So specific that it's unlikely another user would have face this furthermore there is a workaround to just go slow.
If someone could do a bt that would be nice, I may be able to do one tomorrow.
Created attachment 107551 [details]
backtrace of where things go wrong
at the bottom of the stack we have m_aDataArray.clear() but *mile* up the stack in frame 110 we have...
Item& rItem = m_aDataArray.back();
rItem.maString = m_pDocument->GetString(aAdr);
so during the GetString the m_aDataArray is cleared, so rItem is no longer valid and we cannot assign to it anymore legally
With the straightforward approach of http://cgit.freedesktop.org/libreoffice/core/commit/?id=deed6dcacd355ce84cada955887a31e7d8cb5fb1
it no longer crashes.