Created attachment 193027 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

Also reproduced with debug build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a1a1d8edb9d4a62b747aa7069b3026e2ba75704d
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

In console:

warn:legacy.tools:125993:125993:svx/source/form/fmshimp.cxx:1796: only to be used in alive mode
/opt/rh/gcc-toolset-12/root/usr/include/c++/12/debug/safe_iterator.h:954:
In function:
    gnu_debug::_Safe_iterator<gnu_cxx::
    normal_iterator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>*, 
    std::
    vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>, 
    std::allocator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    > > >, std::
    debug::vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    >, std::random_access_iterator_tag>::_Self gnu_debug::operator-(const 
    _Safe_iterator<gnu_cxx::
    normal_iterator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>*, 
    std::
    vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>, 
    std::allocator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    > > >, std::
    debug::vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    >, std::random_access_iterator_tag>::_Self&, _Safe_iterator<gnu_cxx::
    normal_iterator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>*, 
    std::
    vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>, 
    std::allocator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    > > >, std::
    debug::vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> 
    >, std::random_access_iterator_tag>::difference_type)

Error: attempt to retreat a dereferenceable (start-of-sequence) iterator 1 
steps, which falls outside its valid range.

Objects involved in the operation:
    iterator @ 0x7ffcdbac2f50 {
      type = gnu_cxx::normal_iterator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>*, std::vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>, std::allocator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> > > > (mutable iterator);
      state = dereferenceable (start-of-sequence);
      references sequence with type 'std::debug::vector<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart>, std::allocator<std::shared_ptr<sdext::presenter::PresenterToolBar::ElementContainerPart> > >' @ 0x6368da8
    }

Thank you Stéphane for the console logs, I had forgotten to attach them.

I tried on a non debug build and didn't reproduce the pb quite weirdly.

(In reply to Julien Nabet from comment #3)
> I tried on a non debug build and didn't reproduce the pb quite weirdly.
Same, for 24.2.1 and 24.8alpha0+.

(In reply to Hossein from comment #0)
> Version: 24.2.0.3 (X86_64) / LibreOffice Community
Hossein, is this a debug build? Was it really reproduced in 24.2.0?

(In reply to Stéphane Guillou (stragu) from comment #4)
> (In reply to Julien Nabet from comment #3)
> > I tried on a non debug build and didn't reproduce the pb quite weirdly.
> Same, for 24.2.1 and 24.8alpha0+.
> 
> (In reply to Hossein from comment #0)
> > Version: 24.2.0.3 (X86_64) / LibreOffice Community
> Hossein, is this a debug build? Was it really reproduced in 24.2.0?

You are correct. The crash actually happens on a debug build, and the above build info in comment 0 is wrong. The correct one is this:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f4ba83e82aafc206d17d2fa66a27573ebc5a3624
CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

There are 2 main parts which rely on RTL/LTR layout in sd/source/console/PresenterToolBar.cxx:
1) in PresenterToolBar::Layout line 747
2) in PresenterToolBar::LayoutPart line 846

I thought that instead of 2 different treatments, perhaps we may just use a reversed vector.
"maElementContainer" is defined as "ElementContainer" which is a typedef of ::std::vector<SharedElementContainerPart>.

For 1) it does the trick.

For 2) we do "for (auto& rxElement : *rpPart)"
rpPart is "SharedElementContainerPart" which is defined as "std::shared_ptr<ElementContainerPart>"
so *rpPart is "ElementContainerPart".
This last one is defined as "class PresenterToolBar::ElementContainerPart
    : public ::std::vector<rtl::Reference<Element> >"

I tried to simplify this by creating a new typedef as:
typedef ::std::vector<rtl::Reference<Element> > ElementContainerPart;

but it doesn't know "Element" in sd/source/console/PresenterToolBar.hxx.

IMHO, there are a lot of things defined in sd/source/console/PresenterToolBar.cxx which should be in sd/source/console/PresenterToolBar.hxx
but I got lost with namespaces uses, I didn't succeed in building LO with this refactoring.

I've submitted the patch here:
https://gerrit.libreoffice.org/c/core/+/164592

(In reply to Julien Nabet from comment #7)
> I've submitted the patch here:
> https://gerrit.libreoffice.org/c/core/+/164592

Sorry wrong bug.