Hi Michael,
Good catch with this :-)
On Fri, 2011-10-21 at 12:28 +0200, Michael Stahl wrote:
> is there any authoritative documentation on when exactly the SolarMutex
> should be locked when coming from the UI?
So - with the gtk+ backend, it should mirror the GDK_THREADS lock that
protects the toolkit.
> i know that it must be locked on UNO API method entry in the parts of
> the code that are not otherwise threadsafe, but i have no idea how the
> UI stuff / VCL works.
Luckily I have a pretty good idea of what is going on there :-) I spent
a lot of time on this locking integration in the past.
> for example, somebody has put a DBG_TESTSOLARMUTEX() assertion in
> ImplWindowFrameProc, which can easily be triggered by just creating a
> new Writer document, entering a letter or whatever and hitting the
> 'Save' icon.
Sure - that seems reasonable to me - it should be locked there.
> > #0 0x00007ffff7d6fdb1 in osl_assertFailedLine () from
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
> > #1 0x00007ffff32cfacd in ImplDbgTestSolarMutex () at
> > /data/lo/core/vcl/source/app/dbggui.cxx:1978
> > #2 0x00007ffff4457265 in DbgFunc (nAction=15, pParam=0x0) at
> > /data/lo/core/tools/source/debug/debug.cxx:1301
> > #3 0x00007ffff34be129 in DbgTestSolarMutex () at
> > /data/lo/core/solver/unxlngx6/inc/tools/debug.hxx:322
> > #4 0x00007ffff3782fe0 in ImplWindowFrameProc (pWindow=0x134b490, nEvent=2,
> > pEvent=0x7fffffff6fd0) at /data/lo/core/vcl/source/window/winproc.cxx:2370
> > #5 0x00007fffe56641d7 in SalFrame::CallCallback (this=0x134b910, nEvent=2,
> > pEvent=0x7fffffff6fd0) at /data/lo/core/vcl/inc/salframe.hxx:294
> > #6 0x00007fffe568e55e in GtkSalFrame::signalCrossing (pEvent=0x1e3c8e0,
> > frame=0x134b910) at /data/lo/core/vcl/unx/gtk/window/gtkframe.cxx:2866
> > #7 0x000000337114ef33 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
..
> > #21 0x0000003363c2a2e2 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> > #22 0x000000337128cc86 in gtk_widget_show () from
> > /usr/lib64/libgtk-x11-2.0.so.0
> > #23 0x00000033710c4f13 in gtk_dialog_run () from
> > /usr/lib64/libgtk-x11-2.0.so.0
> > #24 0x00007fffdda123c2 in RunDialog::run() () from
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
> > #25 0x00007fffdda192b8 in SalGtkFilePicker::execute() () from
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
it should be locked down this entire call-frame. This looks like an
'easy' case - there is no main-loop running or anything complicated.
> > #46 0x00007fffe5083249 in SalDisplay::DispatchInternalEvent (this=0x779ce0)
> > at /data/lo/core/vcl/unx/generic/app/saldisp.cxx:2160
> > #47 0x00007fffe566387a in GtkXLib::userEventFn (data=0x6fcc80) at
> > /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:900
> > #48 0x00007fffe5663737 in call_userEventFn (data=0x6fcc80) at
> > /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:865
> > #49 0x0000003360c44add in g_main_context_dispatch () from
> > /lib64/libglib-2.0.so.0
> > #50 0x0000003360c452d8 in ?? () from /lib64/libglib-2.0.so.0
It is missing here - the call_userEventFn should have it.
Good catch; I fixed another three missing instances and committed the
patch to feature/gtk3 - it should get merged soon (in the next few
days).
In the meantime - patience much appreciated, and thanks for the report
- well worth leaving that assertion there for the future I think.
Thanks,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
