Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Aug 3, 2013 1:29 PM, "Lionel Elie Mamane" <lionel@mamane.lu> wrote:

And that's because file xmloff/util/xo.component contains:
  <implementation name="XMLVersionListPersistence">
    <service
name="com.sun.star.document.DocumentRevisionListPersistence"/>
  </implementation>

which is the service about with it was complaining. OK, I understand
and I'm one step more removed from "cargo cult unittest writing".

Now, it fails because it cannot find the tango theme; actually there
is no solver/unxlngx6/unittest/install/share directory at all. How do
I get it into the unittest environment?

I have no idea when the file should be created. If it already exists when
we build test we can just copy it similar to the profile files in test/
package_unittest.mk otherwise we might need to move the test to the
subsequent check target.

But in general it might be an idea to check if that exception should be
handled somewhere so that we don't have problems if a icon theme is not
found during the test.

Regards,
Markus


Details:

warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<dbaccess/res/tables_32.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<dbaccess/res/queries_32.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<dbaccess/res/forms_32.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<dbaccess/res/reports_32.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<res/plus.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<res/minus.png>
warn:legacy.osl:20196:1:vcl/source/gdi/bitmapex.cxx:106:
BitmapEx::BitmapEx( const ResId& rResId ): could not load image
<dbaccess/res/forms_16.png>
warn:legacy.osl:20196:1:vcl/source/window/window.cxx:4463: Window () with
live children destroyed:  N5dbaui12OTasksWindowE ()
Window () with live children destroyed:  N5dbaui12OTasksWindowE ()

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE            # for exception catching
export GDBCPPUNITTRACE="gdb --args" # for interactive debugging
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_dbaccess_dialog_save

make: ***
[/home/master/src/libreoffice/workdirs/master/workdir/unxlngx6/CppunitTest/dbaccess_dialog_save.test]
Error 1


I ran it under gdb, and I see that this vcl/Window abort() hides the
underlying exception / error:

$2 = uno::Any {
  <com::sun::star::ucb::InteractiveIOException> = {
    <com::sun::star::task::ClassifiedInteractionRequest> = {
      <com::sun::star::uno::Exception> = {
        Message = "an error occurred during file opening",
        Context = uno::Reference to (fileaccess::BaseContent *)
        0x7fffd99774a8
      },
      members of com::sun::star::task::ClassifiedInteractionRequest:
      Classification =
      com::sun::star::task::InteractionClassification_ERROR
    },
    members of com::sun::star::ucb::InteractiveIOException:
    Code = com::sun::star::ucb::IOErrorCode_NOT_EXISTING
  },
  members of com::sun::star::ucb::InteractiveAugmentedIOException:
  Arguments = uno::Sequence of length 2 = {uno::Any {
  Name = "Uri",
  Handle = -1,
  Value = uno::Any

"file:///home/master/src/libreoffice/workdirs/master/solver/unxlngx6/unittest/install/share/config/images_tango.zip",
  State = com::sun::star::beans::PropertyState_DIRECT_VALUE
}, uno::Any {
  Name = "ResourceName",
  Handle = -1,
  Value = uno::Any

"/home/master/src/libreoffice/workdirs/master/solver/unxlngx6/unittest/install/share/config/images_tango.zip",
  State = com::sun::star::beans::PropertyState_DIRECT_VALUE
}}
}


So it is again this images stuff, but this time it is considered
fatal.


On Sat, Aug 03, 2013 at 06:39:49PM +0200, Markus Mohrhard wrote:
OK that contains all the necessary information. You need to add
xmloff/util/xo to the component list.

This component file contains the missing service specification.
On Aug 3, 2013 11:32 AM, "Lionel Elie Mamane" <lionel@mamane.lu> wrote:

On Sat, Aug 03, 2013 at 05:51:37PM +0200, Markus Mohrhard wrote:

I'm until September in vacation so i can only give you some General
advice.

I see. If I don't get it to work, it will have to wait.

Most of the time loading fails because of a wrong path or missing
component
files. I suppose you checked the first so you might need a dbgutil
build
that prints information about failed loading of component files for
uno
interfaces.

Well, I have a dbgutil build, but it is not enlightening:

  [build CUT] dbaccess_dialog_save
  warn:xmloff.core:29588:1:xmloff/source/core/xmlimp.cxx:851:
exception
caught
  warn:legacy.osl:29588:1:xmloff/source/core/xmlimp.cxx:852: caught an
exception!
  in function:virtual void SvXMLImport::setTargetDocument(const
com::sun::star::uno::Reference<com::sun::star::lang::XComponent>&)
  type: com.sun.star.lang.NotInitializedException
  context: N8dbaccess17ODatabaseDocumentE

This one is usual / not a fatal problem: I get it each time I open an
.odb file "normally". I once tried to get rid of it, but never got
anywhere. But the following one, I'm more clueless about:


warn:legacy.osl:29588:1:dbaccess/source/filter/xml/dbloader2.cxx:519:
caught an exception!
  in function:virtual void dbaxml::DBContentLoader::load(const
com::sun::star::uno::Reference<com::sun::star::frame::XFrame>&, const
rtl::OUString&, const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&,
const

com::sun::star::uno::Reference<com::sun::star::frame::XLoadEventListener>&)
  type: com.sun.star.uno.DeploymentException
  message: component context fails to supply service
  com.sun.star.document.DocumentRevisionListPersistence of type
  com.sun.star.document.XDocumentRevisionListPersistence
  context: N4cppu16ComponentContextE

  This used to be an assertion failure: Desktop disposed before
terminating it, but nothing bad seems to happen anyway?
  macros_test.cxx:43:Assertion
  Test name: DialogSaveTest::test
  assertion failed
  - Expression: xComponent.is()
  - loading failed:
  file:///home/master/src/libreoffice/workdirs/master/dbaccess/
  qa/extras/testdocuments/testDialogSave.odb

It looks weird that the path is cut in two like that, but I added a
 std::cerr << fileName << std::endl;
and there it comes out without newline; I assume it is the cppunit
stuff that does some word-wrapping.


The changes to the existing unit tests are fine.

OK, will commit them.


On Aug 3, 2013 10:36 AM, "Lionel Elie Mamane" <lionel@mamane.lu>
wrote:

Thanks for these pointers. I think I mostly got it, but it fails
for
me, and not at the place I expected it to.

Could you please take a look at branch private/lmamane/basetest ?

It contains:

 commit d965888eb4a0be4c0bdd33fb0b401546de48af0b
 Author: Lionel Elie Mamane <lionel@mamane.lu>
 Date:   Sat Aug 3 10:50:14 2013 +0200

    proposed changes to other unittests

    Change-Id: I64769fee917c5d8c6450a19ad53fdf795e280c98

Just things I found weird in existing tests I took inspiration
of, but
before pushing to master, want a quick check by you.

Then it contains:

 commit bbcc93b3ad2eec0a717b5c59053519cc668cb27b
 Author: Lionel Elie Mamane <lionel@mamane.lu>
 Date:   Sat Aug 3 10:49:41 2013 +0200

    first stab at unittest for fdo#67685

    Change-Id: I44500717109a026d7c71e6494daacbea1f224263

Which is the unittest I wanted to add, but it does not work. It
fails
at:

Test name: DialogSaveTest::test
assertion failed
- Expression: xComponent.is()
- loading failed:
file:///home/master/src/libreoffice/workdirs/master/dbaccess/
qa/extras/testdocuments/testDialogSave.odb

Dunno what wrong. Thanks in advance for your help.


On Sat, Aug 03, 2013 at 02:35:49AM +0200, Markus Mohrhard wrote:
Hey Lionel,

So you basically have two options. We already have a test
concept
where
we
open a file and execute a basic macro in it. You can find an
example
for
it
in sc/qa/extras/macros-test.cxx

The other more flexible option is that you open a document and
call
the
uno
calls yourself from c++. The advantage of the second option is
that
it
allows to add additional assertions and easier debugging but it
takes a
bit
more code.

Regards,
Markus
On Aug 2, 2013 5:59 PM, "Lionel Elie Mamane" <lionel@mamane.lu>
wrote:

I'd appreciate some help in writing a unittest
(subsequenttest?)
for
https://bugs.freedesktop.org/67685

It is the second time such a bug crops up, I'd like to
prevent it.

Basically, we "just" need to open an .odb file, run a Basic
macro
(we
can set it to autorun on document load), then save the file,
and
inspect the result.

Thanks in advance!

--
Lionel


_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.