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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640543
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... m_aDataArray.push_back(Item()); 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.