UNO API doesn't work as expected when ATT enabled

classic Classic list List threaded Threaded
7 messages Options
Efe Gürkan YALAMAN Efe Gürkan YALAMAN
Reply | Threaded
Open this post in threaded view
|

UNO API doesn't work as expected when ATT enabled

Hi all,

I was trying to find the reason of the fdo#70465. Reproduced the bug and debugged that.

During the load page traverses the options recursively with CuiAboutConfigTabPage::FillItems method. Exit condition of this method is an exception thrown from this line:
"Reference< XHierarchicalNameAccess >xNextHierarchicalNameAccess( aNode, uno::UNO_QUERY_THROW );"

It works if Assistive Technology Tools disabled. But if it is enabled interestingly it jumps another declaration which has same type. Couldn't figure out what may cause the problem is because of this interesting behavior and how it is related to ATT. Any kind of help is appreciated.



Here is some info:

Exception is thrown from cui/source/options/optaboutconfig.cxx#n228 normally, after exception thrown program jumps here and it try-catch block handles it.

But instead, program jumps here cui/source/options/optaboutconfig.cxx::216 which breaks program flow. And causes infinite recursion and lock's page. It explains reported 1.5 GB memory usage before crash.


bt just before exception thrown from reference.

#0  com::sun::star::uno::BaseReference::iquery_throw (pInterface=0x0, rType=...) at /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:72
#1  0x00002aaacaeb62e6 in com::sun::star::uno::Reference<com::sun::star::container::XHierarchicalNameAccess>::iquery_throw (pInterface=0x0) at /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:84
#2  0x00002aaacaeb56bf in com::sun::star::uno::Reference<com::sun::star::container::XHierarchicalNameAccess>::Reference (this=0x7fffffff0db0, rAny=...) at /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:189
#3  0x00002aaacaeb0804 in CuiAboutConfigTabPage::FillItems (this=0x18b6350, xNameAccess=..., sPath=...) at /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:228
#4  0x00002aaacaeb0937 in CuiAboutConfigTabPage::FillItems (this=0x18b6350, xNameAccess=..., sPath=...) at /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:230
#5  0x00002aaacaeb0937 in CuiAboutConfigTabPage::FillItems (this=0x18b6350, xNameAccess=..., sPath=...) at /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:230

--
Efe Gürkan YALAMAN
http://about.me/efegurkan

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled

On 10/19/2013 11:55 PM, Efe Gürkan YALAMAN wrote:
> I was trying to find the reason of the fdo#70465
> <https://bugs.freedesktop.org/show_bug.cgi?id=70465>. Reproduced the bug
> and debugged that.
>
> During the load page traverses the options recursively with
> CuiAboutConfigTabPage::FillItems method. Exit condition of this method
> is an exception thrown from this line:
> "Reference< XHierarchicalNameAccess >xNextHierarchicalNameAccess( aNode,
> uno::UNO_QUERY_THROW );"

...you mean "exit condition from the FillItems recursion," I assume.  In
any event, it would arguably be better to not rely on an exception there
to break the recursion.  Rather, stop once aNode does not reference an
object implementing XHierarchicalNameAccess, by doing

> Reference<XHierarchicalNameAccess> xNextHierarchicalNameAccess(aNode, uno::UNO_QUERY);
> bIsLeafNode = !aNode.is();

However, I cannot reproduce the problem as you describe it below.  Given
your backtrace contains "/home/efe/", I assume it is on Linux?

(What I can reproduce is the UI being unresponsive and CPU load being
high for a very long time, see
<https://bugs.freedesktop.org/show_bug.cgi?id=70465#c9>.)

> It works if Assistive Technology Tools disabled. But if it is enabled
> interestingly it jumps another declaration which has same type. Couldn't
> figure out what may cause the problem is because of this interesting
> behavior and how it is related to ATT. Any kind of help is appreciated.
>
>
>
> Here is some info:
>
> Exception is thrown from cui/source/options/optaboutconfig.cxx#n228
> <http://cgit.freedesktop.org/libreoffice/core/tree/cui/source/options/optaboutconfig.cxx#n228>
> normally, after exception thrown program jumps here and it try-catch
> block handles it.
>
> But instead, program jumps here
> cui/source/options/optaboutconfig.cxx::216
> <http://cgit.freedesktop.org/libreoffice/core/tree/cui/source/options/optaboutconfig.cxx#n216>
> which breaks program flow. And causes infinite recursion and lock's
> page. It explains reported 1.5 GB memory usage before crash.
>
>
> bt just before exception thrown from reference.
>
> #0  com::sun::star::uno::BaseReference::iquery_throw (pInterface=0x0,
> rType=...) at
> /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:72
> #1  0x00002aaacaeb62e6 in
> com::sun::star::uno::Reference<com::sun::star::container::XHierarchicalNameAccess>::iquery_throw
> (pInterface=0x0) at
> /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:84
> #2  0x00002aaacaeb56bf in
> com::sun::star::uno::Reference<com::sun::star::container::XHierarchicalNameAccess>::Reference
> (this=0x7fffffff0db0, rAny=...) at
> /home/efe/libreoffice/include/com/sun/star/uno/Reference.hxx:189
> #3  0x00002aaacaeb0804 in CuiAboutConfigTabPage::FillItems
> (this=0x18b6350, xNameAccess=..., sPath=...) at
> /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:228
> #4  0x00002aaacaeb0937 in CuiAboutConfigTabPage::FillItems
> (this=0x18b6350, xNameAccess=..., sPath=...) at
> /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:230
> #5  0x00002aaacaeb0937 in CuiAboutConfigTabPage::FillItems
> (this=0x18b6350, xNameAccess=..., sPath=...) at
> /home/efe/libreoffice/cui/source/options/optaboutconfig.cxx:230

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Efe Gürkan YALAMAN Efe Gürkan YALAMAN
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled


2013/10/22 Stephan Bergmann <[hidden email]>

I'm still not sure I get you.  That the catch(uno::Exception&) block at cui/source/options/optaboutconfig.cxx:234 will eventually catch an exception is obviously not unexpected.  You mean, on Windows you observe that that catch block is never reached?  (If yes, how do you observe that, with a debugger?  If yes, are you sure the debugger does not fool you, as can happen with optimized code?)

 I couldn't make it work a debugger on Windows. I couldn't properly build it actually :( So I can only assume it is. So I assume recursion is not end because of up to 1.5 GB of the ram usage and crash after that. Because exit condition relies exception.

Anyways If i can build LO on Windows tonight I will be a happier person...


On Linux there is no crash as you said. Unresponsive UI and CPU load.
But on windows program crashes without anything shown to user. It is not
related to UNO I think.

Any chance to present a backtrace of that crash on Windows?  (I'm currently doing a local Windows build here and will try to reproduce the problem, if I manage to remember how to enable AT on Windows...)

Stephan

PS, any reason you dropped the mailing list from cc?
Gmail's user interface tricked me on here. :)



--
Efe Gürkan YALAMAN
http://about.me/efegurkan

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled

On 10/22/2013 11:33 PM, Efe Gürkan YALAMAN wrote:

> 2013/10/22 Stephan Bergmann <[hidden email]
> <mailto:[hidden email]>>
>
>
>     I'm still not sure I get you.  That the catch(uno::Exception&) block
>     at cui/source/options/__optaboutconfig.cxx:234 will eventually catch
>     an exception is obviously not unexpected.  You mean, on Windows you
>     observe that that catch block is never reached?  (If yes, how do you
>     observe that, with a debugger?  If yes, are you sure the debugger
>     does not fool you, as can happen with optimized code?)
>
>   I couldn't make it work a debugger on Windows. I couldn't properly
> build it actually :( So I can only assume it is. So I assume recursion
> is not end because of up to 1.5 GB of the ram usage and crash after
> that. Because exit condition relies exception.
>
> Anyways If i can build LO on Windows tonight I will be a happier person...

I cannot reproduce any problem with a current master build, at least on
Windows 7 with MS Narrator (Control Panel - Ease of Access Center -
Start Narrator) enabled.  Expert Config comes up relatively quickly even
and appears fully functional.  Maybe Michael's
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffd0e2911023e684ca1e206d18b45ef5aa6179f9>
"fdo#70465: speed up AccessibleEventNotifier::generateId()" already
solved that?

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled

On 23/10/13 09:58, Stephan Bergmann wrote:

> On 10/22/2013 11:33 PM, Efe Gürkan YALAMAN wrote:
>> 2013/10/22 Stephan Bergmann <[hidden email]
>> <mailto:[hidden email]>>
>>
>>
>>     I'm still not sure I get you.  That the catch(uno::Exception&) block
>>     at cui/source/options/__optaboutconfig.cxx:234 will eventually catch
>>     an exception is obviously not unexpected.  You mean, on Windows you
>>     observe that that catch block is never reached?  (If yes, how do you
>>     observe that, with a debugger?  If yes, are you sure the debugger
>>     does not fool you, as can happen with optimized code?)
>>
>>   I couldn't make it work a debugger on Windows. I couldn't properly
>> build it actually :( So I can only assume it is. So I assume recursion
>> is not end because of up to 1.5 GB of the ram usage and crash after
>> that. Because exit condition relies exception.
>>
>> Anyways If i can build LO on Windows tonight I will be a happier person...
>
> I cannot reproduce any problem with a current master build, at least on
> Windows 7 with MS Narrator (Control Panel - Ease of Access Center -
> Start Narrator) enabled.  Expert Config comes up relatively quickly even
> and appears fully functional.  Maybe Michael's
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffd0e2911023e684ca1e206d18b45ef5aa6179f9>
> "fdo#70465: speed up AccessibleEventNotifier::generateId()" already
> solved that?

well at least on Linux i can still get it to hang up for > 10 minutes by
scrolling with keyboard, so it's only partially solved.

btw this is how you can enable a11y on Gnome (if it is not already
enabled by default as it would be in Fedora 18 or later):

gsettings set org.gnome.desktop.interface toolkit-accessibility true

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled

In reply to this post by sberg
Stephan Bergmann-2 wrote
I cannot reproduce any problem with a current master build, at least on
Windows 7 with MS Narrator (Control Panel - Ease of Access Center -
Start Narrator) enabled.  Expert Config comes up relatively quickly even
and appears fully functional.
Not sure you'd have activated the Java dependent UNO Accessibility API on Windows like that. Narrator uses the UI Automation API. Would still need to activate the Java Accessibility API

From Oracle's JAB site-- Windows...  Enabling Java Access Bridge

To enable Java Access Bridge, run the following command (where %JRE_HOME% is the directory of your JRE):

%JRE_HOME%\bin\jabswitch -enable

Alternatively, in Windows Vista and later, you can enable Java Access Bridge through the Control Panel:

    Go to Start > Control Panel > Ease of Access > Ease of Access Center. Alternatively, press Windows logo key+u to access the Ease of Access Center.
    Select Use the computer without a display.
    In the section Other programs installed, select the check box Enable Java Access Bridge (you may have to scroll down).

Note: After enabling Java Access Bridge, you must restart your assistive technology software and Java applications that use the accessibility API.
Efe Gürkan YALAMAN Efe Gürkan YALAMAN
Reply | Threaded
Open this post in threaded view
|

Re: UNO API doesn't work as expected when ATT enabled

Well I build with debug symbols on windows and debugged. Exception is thrown and catched on here. So no problem on UNO.

I still need to find what cause the crash. I will have some time on monday to work on.

Best


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice