Download it now!
Bug 94715 - Crash when closing Table Design
Summary: Crash when closing Table Design
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.0.2 target:5...
Keywords: haveBacktrace, notBibisectable, regression
Depends on:
Blocks:
 
Reported: 2015-10-02 23:07 UTC by Julien Nabet
Modified: 2016-10-25 19:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (8.52 KB, text/plain)
2015-10-02 23:07 UTC, Julien Nabet
Details
valgrind log (49.90 KB, application/x-tar-gz)
2015-12-05 13:29 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2015-10-02 23:07:08 UTC
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
Comment 1 Julien Nabet 2015-10-02 23:08:17 UTC
I don't reproduce this with LO Debian package 5.0.2.2=>regression
Comment 2 Terrence Enger 2015-10-03 15:38:15 UTC
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.
Comment 3 Julien Nabet 2015-10-10 05:55:10 UTC
Michael: tdf#91310  (VclPtr) related?
Comment 4 Julien Nabet 2015-12-05 13:29:56 UTC
Created attachment 121049 [details]
valgrind log
Comment 5 Julien Nabet 2015-12-05 13:49:47 UTC
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)
Comment 6 Robinson Tryon (qubit) 2015-12-10 01:26:35 UTC Comment hidden (obsolete)
Comment 7 Terrence Enger 2015-12-29 23:33:50 UTC
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.
Comment 8 Terrence Enger 2015-12-29 23:36:57 UTC
I meant the platform that I mentioned in comment 7 to be
debian-squeeze.  (I cannot imagine what I was thinking.)
Comment 9 Terrence Enger 2015-12-29 23:38:05 UTC
I meant the platform that I mentioned in comment 7 to be
debian-stretch.  (Fooey.  Twice in a row!)
Comment 10 Michael Meeks 2016-01-04 21:36:09 UTC
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. =)
Comment 11 Michael Meeks 2016-01-04 21:36:09 UTC Comment hidden (obsolete)
Comment 12 Michael Meeks 2016-01-04 21:56:06 UTC
Apparently fixed, according to Julien, thanks for testing - hoping that CI will recover soon =)
Comment 13 Commit Notification 2016-01-05 10:23:04 UTC
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.
Comment 14 Commit Notification 2016-01-06 08:26:25 UTC
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.
Comment 15 Commit Notification 2016-01-07 14:44:27 UTC
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.
Comment 16 Terrence Enger 2016-01-16 15:45:24 UTC
With a local build of commit a7f3a0e, fetched 2016-10-15 21:29 UTC,
the crash is gone.

Thank you, Michael.