Created attachment 119219 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today (e4ddba2b5f8ff32dd35e8c8f66f145597407be42), I had a crash when closing Table Design. 1) Launch LO Base 2) Create a brand new HSQL Embedded file (select only by default options) 3) In Table pane, launch "Table Design" 4) Just close the Table Design window => crash
I don't reproduce this with LO Debian package 5.0.2.2=>regression
I have provoked a SIGSEGV in localbuilt commit 78216d, fetched 2015-09-21 02:45 UTC, configured ... CC=ccache /home/terry/lo_hacking/associated/gcc/bin/gcc CXX=ccache /home/terry/lo_hacking/associated/gcc/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --disable-gstreamer-1-0 --enable-gstreamer-0-10 --disable-gtk3 built on debian-wheezy with localbuilt gcc 5.2.0 and its libraries, running in an environment chroot'ed to debian-sid. So, setting status NEW. However, I have not managed to provoke a failure with daily dbgutil bibisect versions 2015-10-02 or 2015-10-03. So setting whiteboard notBibisectable. And I have not provoked a failure on Windows Vista with daily build from 2015-08-13_05:36:16 (build id 5605b75...). Given that not all Linux versions crash, my lack of crash on Windows may not mean much. An embedded Firebird database also crashes. `make debugrun` in progress.
Michael: tdf#91310 (VclPtr) related?
Created attachment 121049 [details] valgrind log
I noticed this interesting part: ==24276== Invalid read of size 8 ==24276== at 0xBDFBF82: com::sun::star::uno::BaseReference::is() const (Reference.h:94) ==24276== by 0xBE095AB: VCLXAccessibleComponent::WindowChildEventListener(VclWindowEvent&) (vclxaccessiblecomponent.cxx:122) ==24276== by 0xBE09576: VCLXAccessibleComponent::LinkStubWindowChildEventListener(void*, VclWindowEvent&) (vclxaccessiblecomponent.cxx:120) ==24276== by 0xD307B30: Link<VclWindowEvent&, void>::Call(VclWindowEvent&) const (in /home/julien/compile-libreoffice/libreoffice/instdir/program/libvcllo.so) ==24276== by 0xD30534F: vcl::Window::CallEventListeners(unsigned long, void*) (event.cxx:252) ==24276== by 0xD26FE46: vcl::Window::ImplResetReallyVisible() (stacking.cxx:752) ==24276== by 0xD4152FE: vcl::Window::Show(bool, ShowFlags) (window.cxx:2371) ==24276== by 0xD24B399: vcl::Window::Hide() (window.hxx:1008) ==24276== by 0xD40BB4B: vcl::Window::dispose() (window.cxx:406) ==24276== by 0xD47D6CE: Control::dispose() (ctrl.cxx:77) ==24276== by 0xD582E4B: OutputDevice::disposeOnce() (outdev.cxx:202) ==24276== by 0x339B6B52: VclPtr<FixedLine>::disposeAndClear() (vclptr.hxx:206) ==24276== by 0x339FB351: dbaui::ODataView::dispose() (dataview.cxx:66) ==24276== by 0x33CF5FAD: dbaui::OTableDesignView::dispose() (TableDesignView.cxx:200) ==24276== by 0xD582E4B: OutputDevice::disposeOnce() (outdev.cxx:202) ==24276== by 0xBE17400: VclPtr<OutputDevice>::disposeAndClear() (vclptr.hxx:206) ==24276== by 0xBE67E26: VCLXWindow::dispose() (vclxwindow.cxx:937) ==24276== by 0x300830E5: (anonymous namespace)::Frame::setComponent(com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, com::sun::star::uno::Reference<com::sun::star::frame::XController> const&) (frame.cxx:1572) ==24276== by 0x30083B1A: (anonymous namespace)::Frame::close(unsigned char) (frame.cxx:1774)
Migrating Whiteboard tags to Keywords: (notBibisectable)
I have managed to provoke the the segfault with the following completely underwhelming steps ... (*) Open a .odb, for example a completely empty (no tables, no data, no nothing) embedded Firebird database. Program presents Base window. (*) Type "<Alt>+F C". KABOOM. In the resulting backtrace, 15 out the top 16 functions have the same name as in Julien's attachment from October 2nd. Execution with paramter --valgrind results in output very much like Julien's in comment 5, but no crash. And, like before, the daily dbgutil bibisect repository version 2015-12-29 does not crash. The crashing LibreOffice is commit 30b8dcb, fetched 2015-12-22 03:55 UTC, configured ... CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src # --disable-remote built and running on debian-squeeze.
I meant the platform that I mentioned in comment 7 to be debian-squeeze. (I cannot imagine what I was thinking.)
I meant the platform that I mentioned in comment 7 to be debian-stretch. (Fooey. Twice in a row!)
Tested and couldn't reproduce on Linux/master with dbgutil - which is annoying. Had a quick read around the code, and could see several problems; with reasonably easy fixes - but without knowing which one is the nasty - its really not clear what to do. It seems pretty clear that: pVCLXindow->GetWindow()->AddEventListener( LINK( this, VCLXAccessibleComponent, WindowEventListener ) ); is called - then then 'this' is deleted (cf. trace) - and then we get another event with an invalid this. I imagine that by the time we delete this: VCLXAccessibleComponent::~VCLXAccessibleComponent() ... if ( mpVCLXindow && mpVCLXindow->GetWindow() ) mpVCLXindow->GetWindow()->RemoveEventListener( LINK( this, VCLXAccessibleComponent, WindowEventListener ) ); no longer has a window to remove itself from. Not very safe that pattern. The band-aid is to just store a VclPtr to the window to remove ourselves from - which should be rather safe; but ... https://gerrit.libreoffice.org/21088 testing appreciated etc. =)
Apparently fixed, according to Julien, thanks for testing - hoping that CI will recover soon =)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7576f273257531a2228668cb215b137169b7ae54 tdf#94715 - ensure we remove ourselves from the same event source. It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9288631d11987087da7b9997937ae4b7b556fabc&h=libreoffice-5-1 tdf#94715 - ensure we remove ourselves from the same event source. It will be available in 5.1.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a22f9f5fe528c7c0f45813a025b377f79c8372e&h=libreoffice-5-0 tdf#94715 - ensure we remove ourselves from the same event source. It will be available in 5.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With a local build of commit a7f3a0e, fetched 2016-10-15 21:29 UTC, the crash is gone. Thank you, Michael.