Re: [dev] assertion failure
On 03/02/10 08:28, Terrence Enger wrote: On Mon, 2010-03-01 at 17:28 +0100, Stephan Bergmann wrote: On 02/26/10 14:32, Terrence Enger wrote: I am looking at issue 109146 Assertion: Error: seekEntry() Bad map ... http://www.openoffice.org/issues/show_bug.cgi?id=109146. It just happens to be the first assertion that I saw triggered in my first non-product build. This issue is probably a bad choice to write a test for (at least a bad choice for starters), for at least two reasons: Just my luck to pick an odball. whineMummy, the computer is picking on me./whine The assertion itself is so easy to fix, that I figured I should do more. I fear now that I am am using more of your time than the problem is worth. Should I move on to something else? Move on to unearthing/writing tests for/fixing some other shortcomings of OOo? Yes, please. ;) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
On 02/26/10 14:32, Terrence Enger wrote: I am looking at issue 109146 Assertion: Error: seekEntry() Bad map ... http://www.openoffice.org/issues/show_bug.cgi?id=109146. It just happens to be the first assertion that I saw triggered in my first non-product build. The failing assertion is in a function defined outside of any class, but the cppunit tutorials I have found all have object-oriented examples. I'll see how I get along. One good test is to make the unchanged assertion fire, right? To accomplish this under different compilers, I think the test program is going to compare the addresses of independent variables, and that gives results which are not defined by the C++ standard. (Well, that's if my very old memory is correct.) Anyway, before this is done, I shall need help to find a compiler which sends the test program down the other path by allocating stack variables in the other order. This issue is probably a bad choice to write a test for (at least a bad choice for starters), for at least two reasons: - Checking that an assertion fires is not easy. (It will become easier when http://qa.openoffice.org/issues/show_bug.cgi?id=109142 Let assertions abort is fixed, if you assume that observing an abort implies a fired assertion.) - The DBG_ASSERT expression in the issue is wrong, whether or not it fires depends on factors outside the C++ standard. It is generally not possible to write standard C++ code that reliably causes the assertion to fire or not to fire. (As you noted already. However, note that this is not about stack variables, but about string literals in a library's (read-only) data segment.) That same test will have to cast away constness of MediaTypeEntry::m_pTypeName, and that is a bad thing to do. But I am *trying* to screw things up. Does that give me a pass? Why would you need to cast away constness? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
On Mon, 2010-03-01 at 17:28 +0100, Stephan Bergmann wrote:
On 02/26/10 14:32, Terrence Enger wrote:
I am looking at issue 109146 Assertion: Error: seekEntry() Bad map ...
http://www.openoffice.org/issues/show_bug.cgi?id=109146. It just
happens to be the first assertion that I saw triggered in my first
non-product build.
This issue is probably a bad choice to write a test for (at least a bad
choice for starters), for at least two reasons:
Just my luck to pick an odball. whineMummy, the computer is picking
on me./whine
The assertion itself is so easy to fix, that I figured I should do more.
I fear now that I am am using more of your time than the problem is
worth. Should I move on to something else?
- Checking that an assertion fires is not easy. (It will become easier
when http://qa.openoffice.org/issues/show_bug.cgi?id=109142 Let
assertions abort is fixed, if you assume that observing an abort
implies a fired assertion.)
Er, yes. I was not even going to think about this until I had seen the
assertion fire on the screen. And there is lots I have to do before
that happens. Conspicuously, the test case has to load the library with
the assertion and I-know-not-how-much-more beside.
Meanwhile, the application defines MediaTypeEntry at file scope. So,
there is no #include file to provide the definition. I may end up
having to learn more than I want to know about the build system.
And these are just the issues that come to mind before I try to do
anything.
- The DBG_ASSERT expression in the issue is wrong, whether or not it
fires depends on factors outside the C++ standard. It is generally not
possible to write standard C++ code that reliably causes the assertion
to fire or not to fire. (As you noted already. However, note that this
is not about stack variables, but about string literals in a library's
(read-only) data segment.)
I was thinking of provoking the incorrect assertion by calling
seekEntry() with a second parameter set up by something like ...
MediaTypeEntry badMte[ 2 ] =
{ { , 0, },
{ , 0, }
};
char str1[ 6 ],
str2[ 6 ];
if( str1 str2 ) {
strcpy( str2, alpha ); badMte[ 0 ].m_pTypeName = str2;
strcpy( str1, bravo ); badMte[ 1 ].m_pTypeName = str1;
} else {
strcpy( str1, alpha ); badMte[ 0 ].m_pTypeName = str1;
strcpy( str2, bravo ); badMte[ 1 ].m_pTypeName = str2;
}
I forget whether the comparison above is undefined or
implementation-defined according to the standard. This code is not even
compiled, let alone tested, but still it might succeed in provoking the
assertion on quite a few platforms.
The addresses of literal strings are a bit different in that we know
that some platforms use different placement strategies. For all I know,
different compiler options could change placement of literals.
Of course, the corrected assertion will take this in stride.
That same test will have to cast away constness of
MediaTypeEntry::m_pTypeName, and that is a bad thing to do. But I am
*trying* to screw things up. Does that give me a pass?
Why would you need to cast away constness?
Because my crossed eyes saw const in the wrong place when I was
reading the definition of MediaTypeEntry. Does that cut it as an
excuse?
Cheers,
Terry.
-Stephan
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
Thank you, Stephan, for your thoughtful response. On Wed, 2010-02-24 at 09:31 +0100, Stephan Bergmann wrote: - All directories containing test code are added to the modules' prj/build.lst files. I'll take that as my first reading assignment. Reading: For how to write tests, I would suggest the generic testing and xUnit literature. Ah. That provoked me to google more widely. Suddenly I see lots of things. Let me know if you have any trouble going forward. Maybe you can explain a concrete thing you would like to write a test for, and we can see how to get started with that concrete example. I am looking at issue 109146 Assertion: Error: seekEntry() Bad map ... http://www.openoffice.org/issues/show_bug.cgi?id=109146. It just happens to be the first assertion that I saw triggered in my first non-product build. The failing assertion is in a function defined outside of any class, but the cppunit tutorials I have found all have object-oriented examples. I'll see how I get along. One good test is to make the unchanged assertion fire, right? To accomplish this under different compilers, I think the test program is going to compare the addresses of independent variables, and that gives results which are not defined by the C++ standard. (Well, that's if my very old memory is correct.) Anyway, before this is done, I shall need help to find a compiler which sends the test program down the other path by allocating stack variables in the other order. That same test will have to cast away constness of MediaTypeEntry::m_pTypeName, and that is a bad thing to do. But I am *trying* to screw things up. Does that give me a pass? Again, thank you for your patience. Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
On 02/23/10 18:45, Terrence Enger wrote: On Thu, 2010-02-11 at 10:16 +0100, Stephan Bergmann wrote: On 02/11/10 03:11, Terrence Enger wrote: Let me pick on the first assertion which failed, and one which is failing quite regularly. It is ... Error: seekEntry(): Bad map From File /home/terry/OOo_hacking/DEV300_m71/svl/source/misc/inettype.cxx at line 818 Now addressed by http://www.openoffice.org/issues/show_bug.cgi?id=109146. How can I--or similarly situated newbies--contribute? Particularly, how should I go about creating test cases? In other words where should I start reading? Test cases: Due to me currently working in that area on CWS sb118, things are somewhat in flux right now. Once that CWS is integrated and things have settled, the situation should be somewhat like this: - You can write tests in plain JUnit or CppUnit (JUnit will become a prerequisite for building OOo, CppUnit is available in module cppunit). For CppUnit there is a slightly modified test runner cppunittester, built at sal/cppunittester (for technical reasons, it is preferable if the tester executable uses SAL_MAIN instead of plain main). - Tests that require an elaborate test environment (e.g., a running OOo instance to test against) are supported by Java and C++ libraries that set up and tear down such environments (i.e., to be called from the tests' setUp/tearDown) and makefile helpers to start the test runners appropriately. For now, the libraries (from module test) support starting/stopping an OOo instance to which the tests can connect via UNO, and there is one helper solenv/inc/installationtest.mk makefile. This will probably expand to cover other common needs of tests. - All directories containing test code are added to the modules' prj/build.lst files. Tests that cannot be built/run in a normal OOo build, because they have build/run-time dependencies on other modules higher up in the hierarchy (e.g., all tests requiring a running OOo instance, which is only made available in topmost module smoketestoo_native) have makefiles enclosed in .IF$(OOO_SUBSEQUENT_TESTS)!=. That way, they are ignored on a first build, and a second build to run all tests can be scheduled as cd smoketestoo_native OOO_SUBSEQUENT_TESTS=x build --all. Reading: For how to write tests, I would suggest the generic testing and xUnit literature. Writing tests for specific parts of OOo probably requires the same knowledge as when developing non-test code there, so documentation pointers would be the same as for general newbie developers. Let me know if you have any trouble going forward. Maybe you can explain a concrete thing you would like to write a test for, and we can see how to get started with that concrete example. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
On Thu, 2010-02-11 at 10:16 +0100, Stephan Bergmann wrote: On 02/11/10 03:11, Terrence Enger wrote: Let me pick on the first assertion which failed, and one which is failing quite regularly. It is ... Error: seekEntry(): Bad map From File /home/terry/OOo_hacking/DEV300_m71/svl/source/misc/inettype.cxx at line 818 Now addressed by http://www.openoffice.org/issues/show_bug.cgi?id=109146. How can I--or similarly situated newbies--contribute? Particularly, how should I go about creating test cases? In other words where should I start reading? Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] assertion failure
Thank you for your help. I shall be able to continue hacking with more confidence. On Thu, 2010-02-11 at 10:16 +0100, Stephan Bergmann wrote: Unfortunately running a non-pro OOo results in many assertions popping up. I was just recently frustrated by that once again, and decided (for myself, at least) we should finally address that problem by letting those assertions abort, so just now filed http://www.openoffice.org/issues/show_bug.cgi?id=109142. And, the prevalent notion that those assertions are not fixed, anyway, has let many to no longer bother about them, especially not filing issues for them. This would change when assertions abort, so that P1 reports would be filed (and fixed!) for them. On the one hand, the current state of affairs has the virtue of letting a hacker continue on toward the problem he is looking for. (I did have a purpose. I will someday remember what it was. grin /) A hard abort, on the other hand, might have provoked me either to fix the assertion or to give up trying to use a non-pro build. Would it be feasible and useful to encourage the use of non-pro builds? Back when I first tried to build OOo, something -- perhaps it was a warning like Currently, Non-Product Builds are probably rarely used outside the Hamburg development team in http://wiki.services.openoffice.org/wiki/Non_Product_Build -- gave me the impression that non-pro builds are not something that a newbie should use. Now, I see that it is really easy to create a non-pro build. It remains to be seen whether it gets me any forwarder. FWIW, here is how I came to try a non-pro build. First, I managed a couple of times to send DEV300_m70 into an infinite loop, but I had no idea what I had done to make the program so peeved with me. It would be good to have a trace of the inputs to the program. For all I know, the non-pro build may allow that, although I have not found the facility. Anyway, I guessed it would be easier to try a non-pro build than to explore testautomation. Secondly, I wondered whether my loop was the same as issue 108055 http://www.openoffice.org/issues/show_bug.cgi?id=108055. For reasons which I still do not understand, my breakpoints in gdb did not catch the creation of some objects. From somewhere--but I cannot find it now--I have acquired the notion that a non-pro build will let me track object creation and deletion. I have yet search for that facility, and I do not know whether it will get me any forwarder. Please forgive me for rambling on, and thank you for your patience. Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] assertion failure
Greetings, I have just completed a non-product build of DEV300_m71, my first ever non-product build. http://wiki.services.openoffice.org/wiki/Non_Product_Build tells me that an assertion failure is considered to be a bug and should be reported. However, I had three different assertion failures within the first few minutes using the program. So, I suspect that the messages may be a result of my own misundertanding rather than a problem in the code itself. Let me pick on the first assertion which failed, and one which is failing quite regularly. It is ... Error: seekEntry(): Bad map From File /home/terry/OOo_hacking/DEV300_m71/svl/source/misc/inettype.cxx at line 818 ( It looks to me like the code is testing for pointer values increasing in successive array elements where it should be testing for increasing values of the pointed-to strings. The pointers are initialized from string literals at line 487 of the same file. So, it is not too surprising that the assertion fails. ) First, the issues database: when I query the issues database, I come up empty on (*) [seekEntry] in summary (0 hits) (*) [seekEntry] in description (0 hits) (*) [bad map] (all words) in summary (4 hits: 3 are bitmaps, 1 is an html image map) (*) [bad map] (all words) in description (40 hits: none of the DEFECTs appears at first glance to apply to my situation) How should I do my query? I can't really be the first to find this, can I? All suggestions are welcome. Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
