Re: [dev] Should assertions abort?
On 03/18/10 19:16, Terrence Enger wrote: Long version: I just managed to provoke ... Error: Invalid MediaDescriptor detected: Found no URL. From File /home/terry/OOo_hacking/DEV300_m75/comphelper/source/misc/mediadescriptor.cxx at Line 586 Abort ? (Yes=abort / No=ignore / Cancel=core dump) I suppose I should create an issue for this, just because the guidelines say that every assertion failure should be raised as an issue. Still, I shall hold off in case somebody cares to comment. The reasoning is: If we fix the harmless assertion failures, the remaining ones might point us to more serious problems. So, yes, this should be changed. Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 2010-03-19 at 10:16 +0100, Niklas Nebel wrote: On 03/18/10 19:16, Terrence Enger wrote: Long version: I just managed to provoke ... Error: Invalid MediaDescriptor detected: Found no URL. From File /home/terry/OOo_hacking/DEV300_m75/comphelper/source/misc/mediadescriptor.cxx at Line 586 Abort ? (Yes=abort / No=ignore / Cancel=core dump) I suppose I should create an issue for this, just because the guidelines say that every assertion failure should be raised as an issue. Still, I shall hold off in case somebody cares to comment. The reasoning is: If we fix the harmless assertion failures, the remaining ones might point us to more serious problems. So, yes, this should be changed. Thank you for the nudge. I have created issue 110260 http://www.openoffice.org/issues/show_bug.cgi?id=110260. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 2010-02-12 at 09:11 +0100, Frank Schoenheit, Sun Microsystems Germany wrote: Hi, issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142) requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and friends) to abort if their condition is not met. The current behavior is that the assertion text is reported to the user, usually by a message box. All of the above applies to non-product builds only, in particular, the request, as I understand it, is *not* to extend assertions to product builds. Since this is a controversial topic, I think we should discuss it in a wider audience before actually implementing the change - so, let's get the party started ... Short version: Here is an example of an assertion which I whould not want to see abort. Maybe it is an argument in favour of having assertions of different severities. Long version: I just managed to provoke ... Error: Invalid MediaDescriptor detected: Found no URL. From File /home/terry/OOo_hacking/DEV300_m75/comphelper/source/misc/mediadescriptor.cxx at Line 586 Abort ? (Yes=abort / No=ignore / Cancel=core dump) The bit Found no URL sounds like an entirely fair discription of the situation. (In Calc, I took External Data Link to External Data ...; in the dialog box External Data, for the field URL of external data source, I clicked the dropdown icon, decided I did not want to go there, and clicked the dropdown icon again.) Under the circumstatnces, if the assertion aborted, I would feel that OO was punishing me severely for a trivial error. As it is, the message is a small nuisance (And it would have been a really small nuisance if I had bothered to actually read the message before I rushed off to recreate the situation, carefully writing down each step along the way grin /.) I suppose I should create an issue for this, just because the guidelines say that every assertion failure should be raised as an issue. Still, I shall hold off in case somebody cares to comment. Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Thorsten Behrens wrote: Mathias Bauer wrote: The idea is the unification of pro and non-pro build. We have discussed that only as an idea to save time in release engineering and a nice opportunity for additional diagnostic abilities for customer problems, but maybe it can help in our current discussion also. Please don't. stlport_debug mode has found so many serious (and potentially serious, wrt. later code rework) errors, that I don't want to miss it. Additionally, I have code in place for non-pro builds that does similar expensive (in terms of runtime space) checks. If the build size/time is the problem, fix the root cause (which you, personally, are already doing ;)). Yes, stlport is one of the cons we have noted already, but without a clear idea how important it is. Thanks for your judgement. Indeed we considered the win in build time as not important enough to take the risk to lose something important. I only wanted to present this idea in the context discussed currently as it *could* help to find a compromise. OTOH the replies from you and Eike have shown us that most probably the potential pros are not big enough. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Eike Rathke wrote: Hi Mathias, On Monday, 2010-02-15 12:34:10 +0100, Mathias Bauer wrote: startup would become ~6% larger by converting all #ifdef DBG_UTIL to if (bDBG_UTIL==true). The influence on startup performance would be a little bit less than this 6%, but probably measurable. [...] bDBG_UTIL would be a global variable that can be set from the environment, a configuration file etc. [Before someone asks: all #if(n)def PRODUCT statements have been converted to use DBG_UTIL instead already.] Careful, some DBG_UTIL respectively former non-/PRODUCT code uses different data or class layouts when activated during compile time, it is not possible to replace all DBG_UTIL macros with a runtime equivalent in these cases. For the same reason it is not feasible to mix non-DBG_UTIL with DBG_UTIL compiled code if one doesn't know the exact impact of such an approach. Yes, but I'm sure that we could find a way to change the code in a away that keeps everything that has a performance impact or produces unwanted output in if (bDBG_UTIL) blocks. Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 17:18, Christian Lippka wrote: If you change code at one place, you may cause an assertion to trigger at another place. Since triggered assertions indicate programming errors, the above sentence is equivalent to If you change code at one place, you may introduce a programming error, the symptoms of which can be witnessed at another place. One reportedly effective measure against such errors is testing. I think we all know that we need lots of tests, regularly run (with the average developer in the driver's seat, passionately writing and executing tests). The test cleanup project wants to improve things here, and it is by deliberation that the assertion cleanup issue has a later target than test cleanup. But unlike compiler warnings there is no way to check the complete office for assertion automaticly. Therefore assertions will pop up in the master and annoy others, causing sooner or later that all people use only pro again. FAIL. Not necessarily. The point is that triggered assertions need to be sufficiently rare. Just like people tolerate the occasional master build breaker, addressed promptly by a masterfix (which you can easily pull into your affected CWS), I would argue that they would also tolerate the occasional assertion abort---fixed promptly by a masterfix, too. The important point, of course, is that we first need to reach a plateau where triggered assertions *are* sufficiently rare. We need to address the false assertions that do not diagnose programming errors (that the program cannot handle) but rather interesting events (that the program must handle). We need to have sufficient testing in place so that no CWS or MWS can any longer introduce triggered assertions on well-visited code paths. Therefore assertions will and do pop up in the master. which is no problem if they get fixed in time. If there is a milestone that has to many assertions, you can already redirect them in a window (right after you wrote the author of that assertion a P1 issue). This I see differently. First, I believe in the principle of no broken windows. As soon as you tolerate a single (harmless) triggered assertion (which people can oh so easily work around by clicking it away or redirecting it) you are on your way down the slippery slope. We are already pretty much at the bottom of that hill; once we are at the top, we must make sure to stay there. Second, in an environment where assertions regularly trigger, automated processes *do* have a hard time coping with them. Automated tests need to have extra complexity to hide assertions, Ause manually needs to unlock feedme builds that got stuck with a triggered assertion window from one of the build tools, etc. If this is still not understandable, I will draw you a flow chart on monday at your office :-) Christian, rather than becoming primitive, I would like to ask you the same question I already asked Frank: [A]ssuming we have somehow reached that land [where assertions trigger rarely, and if they do indicate true programming errors], would you then still have objections against aborting assertions? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/15/10 10:16, Stephan Bergmann wrote: On 02/12/10 17:18, Christian Lippka wrote: If you change code at one place, you may cause an assertion to trigger at another place. Since triggered assertions indicate programming errors, the above sentence is equivalent to If you change code at one place, you may introduce a programming error, the symptoms of which can be witnessed at another place. One reportedly effective measure against such errors is testing. I think we all know that we need lots of tests, regularly run (with the average developer in the driver's seat, passionately writing and executing tests). The test cleanup project wants to improve things here, and it is by deliberation that the assertion cleanup issue has a later target than test cleanup. But unlike compiler warnings there is no way to check the complete office for assertion automaticly. Therefore assertions will pop up in the master and annoy others, causing sooner or later that all people use only pro again. FAIL. Not necessarily. The point is that triggered assertions need to be sufficiently rare. Just like people tolerate the occasional master build breaker, addressed promptly by a masterfix (which you can easily pull into your affected CWS), I would argue that they would also tolerate the occasional assertion abort---fixed promptly by a masterfix, too. The important point, of course, is that we first need to reach a plateau where triggered assertions *are* sufficiently rare. We need to address the false assertions that do not diagnose programming errors (that the program cannot handle) but rather interesting events (that the program must handle). We need to have sufficient testing in place so that no CWS or MWS can any longer introduce triggered assertions on well-visited code paths. Therefore assertions will and do pop up in the master. which is no problem if they get fixed in time. If there is a milestone that has to many assertions, you can already redirect them in a window (right after you wrote the author of that assertion a P1 issue). This I see differently. First, I believe in the principle of no broken windows. As soon as you tolerate a single (harmless) triggered assertion (which people can oh so easily work around by clicking it away or redirecting it) you are on your way down the slippery slope. We are already pretty much at the bottom of that hill; once we are at the top, we must make sure to stay there. Second, in an environment where assertions regularly trigger, automated processes *do* have a hard time coping with them. Automated tests need to have extra complexity to hide assertions, Ause manually needs to unlock feedme builds that got stuck with a triggered assertion window from one of the build tools, etc. If this is still not understandable, I will draw you a flow chart on monday at your office :-) Christian, rather than becoming primitive, I would like to ask you the same question I already asked Frank: [A]ssuming we have somehow reached that land [where assertions trigger rarely, and if they do indicate true programming errors], would you then still have objections against aborting assertions? I have an objection against aborting assertions also in that case. If you make the pressure on assertions that high, you will not necessarily get a better code quality. In contrast the result could be that people will simply stop using assertions. That would be a pity and a great loss of information! Ingrid -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Stephan, Not necessarily. The point is that triggered assertions need to be sufficiently rare. Okay, perhaps we can agree to strive for this goal first, and postpone the rest of the discussion. Perhaps we can try aborting discussions, and see how they work, perhaps we have other ideas 'til then. But first lets get a effectively assertion-free office. Be sure you have all my support on this (and supposedly Ingrid's and Christian's and Philipp's as well). So, where do we start? Beg our managers for 2 weeks for fixing all known assertion issues in one CWS? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Frank Schoenheit, Sun Microsystems Germany wrote: Hi Bjoern, Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Ah! Did you know that testtool, the program for running automated UI level tests on OOo, can capture and report assertions? If you claim that assertions should be tested with the common tests, this immediately implies that testtool runs should be done on non-product builds. Which brings the QA should use non-products topic back onto the plate. And I continue to think that if we're serious about assertions being a cheaply available first line of defense against bugs (and it seems we all agreed on that), then non-product builds should get a much higher standing than they have now - in all departments: engineering, QA, release engineering. As it seems, most of us believe that at least in its current state our code is not ready for aborting assertions, so discussing whether having aborting assertions are a good idea or not perhaps is superimposed by the fear to get an unusable product for months. My suggestion is to leave that out for now and think about how we can first reduce the number of assertions found when executing code. Recently I made a CAT0 test with a non-pro build and I was astonished (or should I say: horrified) by the large number of assertions I got. Some of them have been asserts for missing resources - this definitely points to a problem in our ability to detect severe errors. Getting all autotests assertion-free could be a first step to improve the situation considerably. Next step would be to keep that state and it is interesting to think about how we could achieve that. I tend to like the idea of using non-pro builds in QA, but we must recall why we have stopped to do that in the past. Rüdiger mentioned the performance problem, maybe there have been others. The general statement QA should use the code that the user gets sound reasonable, but it is interesting to see where we are getting with it when we have a look on what happens in the code. Let's have a look at the performance first. IMHO the tests are so slow anyway that you never get a result of a test the same day you started it (usual working hours assumed ;-)). A Cat0 test lasts ~8 hours (net time), so waiting for one or two hours more wouldn't be a killer. I doubt that the performance decrease would be larger than this, though of course that needs verification. Or do we have some (at least approximated) data already that would help to judge my rough estimation? Now lets look at QA should use the code that the user gets. This burns down to the question: does a non-pro build hide bugs that a pro build would show? Think about that - do you really think that the probability of such an incident is so high that it justifies to abandon the superior bug detection abilities that a test with activated debugging code gives to us? Should we follow a dogma (in a neutral meaning!) or should we just measure the trade-off: by using non-pro builds in QA we lose something (100% certainty to test the exact code we deliver to users), but we could gain a lot. A short litmus test: all errors I found in the CAT0 test with a pro build of my CWS also appeared in the CAT0 test with the non-pro build I mentioned above, so nothing got lost. But in the test with the non-pro build I found a lot of additional problems(because I got assertions) that I never would have seen in the pro build. The fact that none of these problems had been created by the CWS is another story that should be told another time. A variant of everybody uses builds that give assertions could be that the QA uses assertion enabled builds for CWS, but for tests on master uses pro builds. OK, but what about the release code lines where we only do pro builds? I want to throw in an idea that has been discussed some months ago, just to see if this could be a good compromise. As all compromises it has its pros and cons. So I would like to encourage you to think about the pros as (I'm sure ;-)) you immediately will discover its cons. The idea is the unification of pro and non-pro build. We have discussed that only as an idea to save time in release engineering and a nice opportunity for additional diagnostic abilities for customer problems, but maybe it can help in our current discussion also. When we thought about getting rid of the pro/nonpro differences I made a rough estimation for the influence on code size. I listed all libraries that are load on startup and compared their sizes in the pro and non-pro builds (Windows and Linux). On both platforms the code to load on startup would become ~6% larger by converting all #ifdef DBG_UTIL to if (bDBG_UTIL==true). The influence on startup performance would be a little bit less than this 6%, but probably measurable. IMHO bearable, but - as always - YMMV. From a closer look on what code exactly will be loaded, I
Re: [dev] Should assertions abort?
Hi Mathias, On Monday, 2010-02-15 12:34:10 +0100, Mathias Bauer wrote: startup would become ~6% larger by converting all #ifdef DBG_UTIL to if (bDBG_UTIL==true). The influence on startup performance would be a little bit less than this 6%, but probably measurable. [...] bDBG_UTIL would be a global variable that can be set from the environment, a configuration file etc. [Before someone asks: all #if(n)def PRODUCT statements have been converted to use DBG_UTIL instead already.] Careful, some DBG_UTIL respectively former non-/PRODUCT code uses different data or class layouts when activated during compile time, it is not possible to replace all DBG_UTIL macros with a runtime equivalent in these cases. For the same reason it is not feasible to mix non-DBG_UTIL with DBG_UTIL compiled code if one doesn't know the exact impact of such an approach. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpAfodYf43G6.pgp Description: PGP signature
Re: [dev] Should assertions abort?
Hi Mathias, I tend to like the idea of using non-pro builds in QA, but we must recall why we have stopped to do that in the past. Rüdiger mentioned the performance problem, maybe there have been others. Would be interesting to know. The only thing I heard in the past whenever I asked is, hmm, not quotable in public :) Think about that - do you really think that the probability of such an incident is so high that it justifies to abandon the superior bug detection abilities that a test with activated debugging code gives to us? Should we follow a dogma (in a neutral meaning!) or should we just measure the trade-off: by using non-pro builds in QA we lose something (100% certainty to test the exact code we deliver to users), but we could gain a lot. Indeed. I surely think it's worth it, and what you told about assertions in CAT0 tests seems to strengthen this (assuming that most of those assertions indeed point to bugs). A variant of everybody uses builds that give assertions could be that the QA uses assertion enabled builds for CWS, but for tests on master uses pro builds. kinda like that idea. I want to throw in an idea that has been discussed some months ago, just to see if this could be a good compromise. As all compromises it has its pros and cons. So I would like to encourage you to think about the pros as (I'm sure ;-)) you immediately will discover its cons. Hmm. Okay, trying to focus on the pros ... We have assertion facilities in each and every build - great! We can enable assertions at a customer's site - nice for remote debugging purpose. On the other hand ... there's surely cons. Thinking about it, the changed class layout mentioned by Eike seems to be the only one which cannot be discussed away, i.e. is not bearable. Would be interesting to know how many places are affected there. Other than that, there's just my ... gut feeling that shipping a product with that much of diagnostic code is not good ... but that might be /me only :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Mathias Bauer wrote: The idea is the unification of pro and non-pro build. We have discussed that only as an idea to save time in release engineering and a nice opportunity for additional diagnostic abilities for customer problems, but maybe it can help in our current discussion also. Please don't. stlport_debug mode has found so many serious (and potentially serious, wrt. later code rework) errors, that I don't want to miss it. Additionally, I have code in place for non-pro builds that does similar expensive (in terms of runtime space) checks. If the build size/time is the problem, fix the root cause (which you, personally, are already doing ;)). Cheers, -- Thorsten pgpQebLE8lUh8.pgp Description: PGP signature
Re: [dev] Should assertions abort?
Hi Björn, As said before an aborting assertion should only be used for corrupt internal state. Well, to me that wasn't that clear 'til now. If we add unrecoverable before corrupt (and here we're back at the question of how an office suite should behave to the user in case of internal errors, a question which Christian and /me could never reach consensus about with Stephan), then what you say immediately implies that we need an additional assertion (OSL_ASSERT_ABORT?), simply because, as said before, existing assertions in their majority are used for things other than unrecoverable corrupt internal state. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 2010-02-12 at 17:18 +0100, Christian Lippka wrote: If this is still not understandable, I will draw you a flow chart on monday at your office :-) If you send me pictures of the whiteboard or scans of the paper, I will try to key them in. Or course, before there is any benefit, we shall need ... (*) review and correction by somebody who knows what is right (*) a place in the devloper documentation. This place is, of course, the place where a newcomer to assertions and tracing would naturally go first if he wanted a flowchart. If there is the possibility of a benefit here, I will do what I can to help. Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Should assertions abort?
Hi, issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142) requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and friends) to abort if their condition is not met. The current behavior is that the assertion text is reported to the user, usually by a message box. All of the above applies to non-product builds only, in particular, the request, as I understand it, is *not* to extend assertions to product builds. Since this is a controversial topic, I think we should discuss it in a wider audience before actually implementing the change - so, let's get the party started ... Actually, /me thinks we should *not* change the behavior as suggested. An ::std::assert, which also aborts when hit, basically means something like My state is that inconsistent and unrecoverable, I can't legitimately continue execution. In such a case, an abort is justified. (However, in opposite to what seems to be suggested in the issue, this case also justifies an abort in the product build, i.e. when running at the customer's machine. Whether this is something a product like ours should use more than to a negligible extent, is a separate question, eligible for an even more controversial discussion). However, OSL_*, and even more DBG_*, are a little bit different. In particular, I always understood them (and I know a lot of others used them that way, too) as Something didn't go the way it was intended/expected.. This surely indicates a bug which needs attention, but it does *not necessarily* imply that an abort is the only legitimate reaction. Contrary, a lot of code tries to get out of that concrete situation gracefully, continuing with what still can be done. So, an abort is not justified here, IMO. When asking for the goal of the change, the issue says Without such a strict measure, the many assertions occurring in a run of OOo (...) would probably never go a away, and the assertion tool would remain practically useless (...) But making assertions abort instead of just being reported would worsen the situation, IMO: We have that many assertions in non-product builds because a) too few developers actually use non-product builds (which means they silently introduce new ones) and b) fixing existing assertions is not a priority [1]. Aborting in case of an assertion would just make a) much worse. Also, it would put the burden onto the shoulders of those actually *using* the non-product builds, not of those *causing* the pain. I.e., it would punish the wrong people. Having said all this, I'd say the mentioned issue should be a WONTFIX. The problem which the issue tries to address, however, is still valid, and highly legitimate, in my opinion. Assertions are a cheap and already-existing measure to improve our product quality (and in my personal opinion, both the 3.1 and the 3.2 release have shown that we should improve here). Still, too few people use non-product builds, which means new assertions are introduced, which means more people are scared away from using non-product builds ... which renders assertions nearly useless. So, my suggestions would be the following (admittedly, they're more on a social level, than on a technical one, and thus harder to enforce): - Developers should use non-product builds *only*. That's a very apparent measure, still, a lot of people don't do. If you ask why, often the answer is it's unusable 'cause of the many assertions. Hmm? - QA should use non-product builds *only*. Yes, I am not kidding about this. An assertion which fails indicates a *bug*, that's the very original intention of assertions: report bugs. Speaking strictly, QA which refuses to use non-product builds refuses to do their job, which at least in parts consists of finding bugs. - Report assertions as you find them, and fix them as you get the issues assigned. Give them high priority, as every assertion might be a little effort for you to fix, but it is a lot of paint for a lot of other people as long as it is not fixed. - Get *serious* management backup for the three previous items. (insiderThat's something which is highly missing since MA left years ago :) /insider) - Provide non-product builds for release code lines, too. At least do so much longer than we did with OOO320 (This item strictly applies to Sun-internal workflows.): For OOO320, we stopped providing non-product builds at branch-off day, which was about half a year before the product was actually released. During a significant part of this time, there still happened heavy development on that code line, which is prone to introducing new assertion failures, going unnoticed in product builds. - Basically: Understand that assertions are not there to hinder your work. They exist to help you (at pretty low costs) finding bugs in your code, and thus improving our product - which is something we all should be interested in, right? - Consequently, *use* assertions when writing new
Re: [dev] Should assertions abort?
Frank Schoenheit, Sun Microsystems Germany wrote: Hi, issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142) requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and friends) to abort if their condition is not met. The current behavior is that the assertion text is reported to the user, usually by a message box. All of the above applies to non-product builds only, in particular, the request, as I understand it, is *not* to extend assertions to product builds. ... But making assertions abort instead of just being reported would worsen the situation, IMO: We have that many assertions in non-product builds because a) too few developers actually use non-product builds (which means they silently introduce new ones) and b) fixing existing assertions is not a priority [1]. Aborting in case of an assertion would just make a) much worse. Also, it would put the burden onto the shoulders of those actually *using* the non-product builds, not of those *causing* the pain. I.e., it would punish the wrong people. a strong NO to the question in subject. strong support to the opinion expressed in this email, for asserts not to abort. speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. i'd like to point out one thing i've noticed in other projects with user vs developer mentality. if a user reports program closing, it is a _crash_ for them. you might call that assert, controlled quit - it does not matter. at all. to the user, software crashed. and that is the last thing i want from any software, especially one i rely some of my most important data ever to. ... -- Rich - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 09:11, Frank Schoenheit, Sun Microsystems Germany wrote: issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142) requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and friends) to abort if their condition is not met. The current behavior is that the assertion text is reported to the user, usually by a message box. All of the above applies to non-product builds only, in particular, the request, as I understand it, is *not* to extend assertions to product builds. Right, for now I would be fine keeping it the way it is, that assertions are only active in non-product builds. Mostly on the rationale that there might be assertion code in OOo that has negative impact on performance, so would not be acceptable in product builds. However, contrary to how you read it below, I never intended to suggest that aborting on an assertion was not appropriate in a product build. It is my firm belief that a program that aborts upon assertions is arguably more robust than one that carries on (however paradoxical that may superficially sound). Since this is a controversial topic, I think we should discuss it in a wider audience before actually implementing the change - so, let's get the party started ... Actually, /me thinks we should *not* change the behavior as suggested. An ::std::assert, which also aborts when hit, basically means something like My state is that inconsistent and unrecoverable, I can't legitimately continue execution. In such a case, an abort is justified. (However, in opposite to what seems to be suggested in the issue, this case also justifies an abort in the product build, i.e. when running at the customer's machine. Whether this is something a product like ours should use more than to a negligible extent, is a separate question, eligible for an even more controversial discussion). However, OSL_*, and even more DBG_*, are a little bit different. In particular, I always understood them (and I know a lot of others used them that way, too) as Something didn't go the way it was intended/expected.. This surely indicates a bug which needs attention, but it does *not necessarily* imply that an abort is the only legitimate reaction. Contrary, a lot of code tries to get out of that concrete situation gracefully, continuing with what still can be done. So, an abort is not justified here, IMO. If common understanding indeed is that OSL/DBG asserts flag situations where [s]omething didn't go the way it was intended/expected *in the sense that it is a bug,* then, honestly, for a product like OOo, I see absolutely no reason not to abort in such a case. Self healing software (i.e., software that can cope with bugs in the software itself) is probably great, and there are application domains where the immense additional effort to write such software is probably warranted. However, my understanding is that none of us in the OOo developer community has deep experience writing such software, that OOo is in an application domain where the additional effort is not really warranted, and, ultimately, that any dilettante attempts at it incur severe costs in overall product stability and maintainability (everybody probably has stories to tell about tracing a bug where some piece of code masked an unrecoverable situation instead of propagating it out). The thing I would agree on is that there are most probably uses of OSL/DBG asserts in the OOo code base that do not flag bugs in the software itself, but rather flag inappropriate or otherwise interesting events, like unexpected user input or a full disk when the user tries to save a document. These inappropriate asserts have to be changed to things like OSL_TRACE. My hope would be that this---trivial---adjustment would happen over time, whenever somebody stumbles over such an inappropriate assert firing. (And, enabling aborting assertions in product builds should seriously only be considered when it is known that there are no obviously inappropriate assertions in the code. One more reason why for now I am fine with keeping assertions disabled in product builds.) When asking for the goal of the change, the issue says Without such a strict measure, the many assertions occurring in a run of OOo (...) would probably never go a away, and the assertion tool would remain practically useless (...) But making assertions abort instead of just being reported would worsen the situation, IMO: We have that many assertions in non-product builds because a) too few developers actually use non-product builds (which means they silently introduce new ones) and b) fixing existing assertions is not a priority [1]. Aborting in case of an assertion would just make a) much worse. Also, it would put the burden onto the shoulders of those actually *using* the non-product builds, not of those *causing* the pain. I.e., it would punish the wrong people. OK, something is obviously missing from my
Re: [dev] Should assertions abort?
On 02/12/10 09:30, Rich wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. The irony is, once you have hit a programming error, you can no longer have confidence in the program's behavior. It could happen that the data you still manage to save is subtly corrupted, so subtly that you do not notice immediately. This is indeed a dilemma, and there is no golden way out. That said, in the event of a crash (which would include the abort from an assertion in a non-product build) OOo already tries to save your open documents (and it appears to be somewhat effective at it). i'd like to point out one thing i've noticed in other projects with user vs developer mentality. if a user reports program closing, it is a _crash_ for them. you might call that assert, controlled quit - it does not matter. at all. to the user, software crashed. and that is the last thing i want from any software, especially one i rely some of my most important data ever to. Sure, nobody wants to suffer the consequences of programming errors. However, the software industry happens to be in a state where errors are a frequent reality. The question, then, is how best to carry on once a programming error has been encountered (if the software has the luxury at all to even notice). Fail fast (abort) has the potential to cause the least data loss and the least confusion (the program does not continue running in an uncontrolled state, corrupting the user's data or giving wrong answers to the user). Carry on regardless (ignoring the detection that the program has reached an uncontrolled state; what effectively happens when assertions are disabled in production systems) can be considered unacceptable behavior. It potentially leads to corrupting the user's data or giving wrong answers to the user, with the user not being aware that those answers are wrong. Working around the detected *programming error* is probably the best for the user, but, as I outlined in my other response, nothing you can expect to happen in OOo in the near future (probably as unlikely as OOo not having any program errors to begin with). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Stephan Bergmann wrote: On 02/12/10 09:30, Rich wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. The irony is, once you have hit a programming error, you can no longer have confidence in the program's behavior. It could happen that the data you still manage to save is subtly corrupted, so subtly that you do not notice immediately. This is indeed a dilemma, and there is no golden way out. That said, in the event of a crash (which would include the abort from an assertion in a non-product build) OOo already tries to save your open documents (and it appears to be somewhat effective at it). i'd like to point out one thing i've noticed in other projects with user vs developer mentality. if a user reports program closing, it is a _crash_ for them. you might call that assert, controlled quit - it does not matter. at all. to the user, software crashed. and that is the last thing i want from any software, especially one i rely some of my most important data ever to. Sure, nobody wants to suffer the consequences of programming errors. However, the software industry happens to be in a state where errors are a frequent reality. The question, then, is how best to carry on once a programming error has been encountered (if the software has the luxury at all to even notice). Fail fast (abort) has the potential to cause the least data loss and the least confusion (the program does not continue running in an uncontrolled state, corrupting the user's data or giving wrong answers to the user). yes, that i can totally agree to. so we should distinguish two things here (which you already did in the previous email). 1. a problem, caused by outside data - opening a corrupted document, image or whatever - should never ever result in closure; 2. a problem inside code. yeah, i understand that often figuring out which one has happened is hard or impossible, but hey :) so we're interested in second category only here. still, i'd argue that software should attempt to let me revive as much of data as possible... it should not carry on ignoring the error, of course. it should popup some message, tell me to save my work and restart it. maybe it should add some nagging bar to inform me about it all the time and motivate to restart it. what i have encountered in oo.org several times - i'm working on 4 or 5 documents at the same time, let's say 3 text documents and 2 presentations. if suddenly a problem arises in presentation code, i definitely do not want it to close and lose my changes to the text documents. i want to be notified and given a chance to check them. while automatic saving for recovery is useful, it is also not easy enough to use and efficient : 1. it seems to ignore the fact that i have saved the document and offers it for restoring as well. that takes more time. 2. after all those files are restored i have to manually check each for differences from the manually saved versions (it is possible that either manually saved or automatically saved version is newer). again, this is cumbersome or near impossible for some types of documents. 3. if one of the input files triggered the failure, oo.org will crash again upon restoring them. yes, theoretically i can recover them manually from profile and remove, or i could hit cancel at first and then save files when prompted (but i am never sure when i will be offered to save them, and there is no way for user to know that there will be such a chance - huge usability problem, imho) while problems with recovery are semi-offtopic, i hope they help to highlight reasons why i'd prefer a chance to salvage the data myself, especially when working on many files of different types. i completely understand the argument about masked failures and data corruption risks. and i can't agree with them enough :) i'm not arguing against being in-your-face about such problems - it's just that i've been burned by such problems with oo.org and other software before, and lost data (or time :) ) Carry on regardless (ignoring the detection that the program has reached an uncontrolled state; what effectively happens when assertions are disabled in production systems) can be considered unacceptable behavior. It potentially leads to corrupting the user's data or giving wrong answers to the user, with the user not being aware that those answers are wrong. Working around the detected *programming error* is probably the best for the user, but, as I outlined in my other response, nothing you can expect to happen in OOo in the near future (probably as unlikely as OOo not having any program errors to begin with). a short summary - i'd prefer working around it only for as long as it would take for me to decide what data i want out and get it.
Re: [dev] Should assertions abort?
Hi Frank, I am indifferent regarding whether assertions should abort, but please let me comment your suggestions below: On 02/12/10 09:11, Frank Schoenheit, Sun Microsystems Germany wrote: Hi, issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142) requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and friends) to abort if their condition is not met. The current behavior is that the assertion text is reported to the user, usually by a message box. All of the above applies to non-product builds only, in particular, the request, as I understand it, is *not* to extend assertions to product builds. Since this is a controversial topic, I think we should discuss it in a wider audience before actually implementing the change - so, let's get the party started ... [...] The problem which the issue tries to address, however, is still valid, and highly legitimate, in my opinion. Assertions are a cheap and already-existing measure to improve our product quality (and in my personal opinion, both the 3.1 and the 3.2 release have shown that we should improve here). Still, too few people use non-product builds, which means new assertions are introduced, which means more people are scared away from using non-product builds ... which renders assertions nearly useless. So, my suggestions would be the following (admittedly, they're more on a social level, than on a technical one, and thus harder to enforce): - Developers should use non-product builds *only*. That's a very apparent measure, still, a lot of people don't do. If you ask why, often the answer is it's unusable 'cause of the many assertions. Hmm? - QA should use non-product builds *only*. Yes, I am not kidding about this. An assertion which fails indicates a *bug*, that's the very original intention of assertions: report bugs. Speaking strictly, QA which refuses to use non-product builds refuses to do their job, which at least in parts consists of finding bugs. Here I strongly disagree. Assertions should be fought before a CWS sees QA. That's something developers should do. Testers have to test what the customer will get. - Report assertions as you find them, and fix them as you get the issues assigned. Give them high priority, as every assertion might be a little effort for you to fix, but it is a lot of paint for a lot of other people as long as it is not fixed. +1 - Get *serious* management backup for the three previous items. (insiderThat's something which is highly missing since MA left years ago :) /insider) - Provide non-product builds for release code lines, too. At least do so much longer than we did with OOO320 (This item strictly applies to Sun-internal workflows.): For OOO320, we stopped providing non-product builds at branch-off day, which was about half a year before the product was actually released. During a significant part of this time, there still happened heavy development on that code line, which is prone to introducing new assertion failures, going unnoticed in product builds. That's not correct. OOO320 started end of September 2009. Branch date was code freeze, afterwards only stopper bugs got accepted. We once decided to restrict non-product builds for code lines where active development happens, and I still believe that is a good decision. Release branches as we currently handle them are definitely not the place for heavy development. - Basically: Understand that assertions are not there to hinder your work. They exist to help you (at pretty low costs) finding bugs in your code, and thus improving our product - which is something we all should be interested in, right? - Consequently, *use* assertions when writing new code. There's no such thing as too much assertions in the code - as long as they never fire, of course :) Ciao Frank Rüdiger - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 10:30:59 +0200 Rich ric...@nakts.net wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. We are talking about product builds, so this does not effect and affect (pun intended) end-users. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Fri, 12 Feb 2010 10:30:59 +0200 Rich ric...@nakts.net wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. We are talking about product builds, so this does not effect and affect (pun intended) end-users. (non-product, i assume ?) oh, it does. if you want any testers at all from the community :) it was discussed almost a year ago on this same mailing list - if you want testers, make test builds usable. of course, if the plan is to use these non-product builds for developers only, then i stand corrected and have no opinion on the issue :) BR, Bjoern -- Rich - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Ruediger, - QA should use non-product builds *only*. Yes, I am not kidding about this. An assertion which fails indicates a *bug*, that's the very original intention of assertions: report bugs. Speaking strictly, QA which refuses to use non-product builds refuses to do their job, which at least in parts consists of finding bugs. Here I strongly disagree. Assertions should be fought before a CWS sees QA. Sure. And we should not give a CWS to QA which introduced regressions. Nonetheless, rumors say this happened. That's something developers should do. Testers have to test what the customer will get. Qa engineers, sloppily called testers :), have the responsibility to ensure quality. A means to point out bugs are assertions. So, testers should use this means, as it helps them doing their job. I see your testers should test what the customer gets point, actually, that one was always raised whenever we talked about that topic in the past. See, we had a time where our QA worked on non-product builds (nearly) exclusively. Still, they found the bugs, and I do not know of any case where they did *not* find a bug which they would have found in a product-build. Still, I know *a lot of* bugs which could have been found if more people, explicitly including QA, would have used non-product builds. For instance, one of the stoppers I had for 3.1 would have been found if anybody would simply have *opened the respective dialog* in a non-product build, and would have cared for the assertion which immediately sprung at him. Nobody did - either open the dialog or care for the assertion, whatever ... So, the bottom line is: I think the overall gain, when QA would use non-product builds, is positive: QA would find more bugs than they would miss. For OOO320, we stopped providing non-product builds at branch-off day, which was about half a year before the product was actually released. During a significant part of this time, there still happened heavy development on that code line, which is prone to introducing new assertion failures, going unnoticed in product builds. That's not correct. OOO320 started end of September 2009. Branch date was code freeze, afterwards only stopper bugs got accepted. We once decided to restrict non-product builds for code lines where active development happens, and I still believe that is a good decision. Release branches as we currently handle them are definitely not the place for heavy development. That's my gut feeling only, but: If we would count the lines of code changed in the OOO320 code line, then I believe the sheer number would justify the term heavy development ... To back this feeling a little bit: EIS says that there are 113 CWS' with 414 tasks, based on OOO320, targeted for OOo 3.2, in state integrated. Add a few which were still based on DEV300, in the early days of OOO320. No matter whether we can agree to call this heavy development, I'd say it is enough change happening to justify that we use non-product builds on this code line. As for the decision to not use non-product builds on release code lines: Formerly we had a feature freeze, UI freeze, and code freeze, and the release line was split at code freeze. Today, we have branch-off, which is earlier (relative to the intended release time) than code freeze was. Effectively, this means that a release branch now lives longer than it did formerly. So, at least *one* fact which might influence such a decision has changed, since this decision has been made. So, maybe it is worth re-considering it. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:12:08 +0200 Rich ric...@nakts.net wrote: (non-product, i assume ?) ahem, yes. if the plan is to use these non-product builds for developers only, then i stand corrected and have no opinion on the issue :) Thats the plan as I understood Stephan (didnt he clarify that already in one of his followups?). BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Rich, (non-product, i assume ?) oh, it does. if you want any testers at all from the community :) it was discussed almost a year ago on this same mailing list - if you want testers, make test builds usable. On the medium run, it indeed might be interesting to give out non-product builds for developer snapshots (perhaps even exclusively). So, we indeed should keep end users in mind when discussing about non-product builds. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Bjoern, I am one of the devs that rarely use a non-pro build, but not because it's unusable 'cause of the many assertions, but because there are simply to many differences from the product build in them, causing issues (first of all: annoying build breakers). So you prefer not using them, and leave it to others to fix those? Really? I do, however build with DEBUG=true to see assertions. This will only give you OSL assertions, not the tools-based ones, which still are the majority. Also, it only gives you the assertions from files you explicitly compile with this setting - i.e., if you use a component in a library which you did not compile with debug, and this component would report client errors via assertions, the you miss those, too. On the topic of what is an assertion: Yes, assertions should abort. Otherwise, they are not an assertion, but something that is better covered by OSL_TRACE. Sigh. Again: No matter how the term assertion is defined in theory, in practice there are *hundreds* or *thousands* of assertions (aka usages of DBG_*) which do not match the definition. Saying Assertions should abort because otherwise they're not assertions is, sorry, just closing your eyes against reality. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Am 12.02.2010 12:05, schrieb bjoern michaelsen - Sun Microsystems - Hamburg Germany: On Fri, 12 Feb 2010 09:11:21 +0100 Frank Schoenheit, Sun Microsystems Germanyfrank.schoenh...@sun.com wrote: - Developers should use non-product builds *only*. That's a very apparent measure, still, a lot of people don't do. If you ask why, often the answer is it's unusable 'cause of the many assertions. Hmm? I am one of the devs that rarely use a non-pro build, but not because it's unusable 'cause of the many assertions, but because there are simply to many differences from the product build in them, causing issues (first of all: annoying build breakers). I do, however build with DEBUG=true to see assertions. So you see OSL_ASSERTS from your code, but you never see asserts from code that your code uses. Or things you break with your code in other places. Can you elaborate on the issues that bother you? And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. On the topic of what is an assertion: Yes, assertions should abort. Otherwise, they are not an assertion, but something that is better covered by OSL_TRACE. Assertions are different to build breakers enforced by the changes for warning free code. You can very easy verify that you have not introduced any compiler warning with your changing by simply build the complete office (yes not 100% I know, but you can be very sure). But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. Assertions are the first, cheapest and easiest way of defense in the fight for software quality. My 2c, assertions must not abort, developer must use non pro builds, assertions should be used in every new peace of code. Regards, Christian (using non pro builds for his daily work since 1999) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Frank Schoenheit, Sun Microsystems Germany wrote: Hi Rich, (non-product, i assume ?) oh, it does. if you want any testers at all from the community :) it was discussed almost a year ago on this same mailing list - if you want testers, make test builds usable. On the medium run, it indeed might be interesting to give out non-product builds for developer snapshots (perhaps even exclusively). So, we indeed should keep end users in mind when discussing about non-product builds. reading your other build about non-prod builds allowing to find issues sooner, i think that indeed has a potential to increase quality a lot. which reminds me... i stumbled upon a problem where pre-3.3 would corrupt my documents, but 3.1.1 would work just fine. http://www.openoffice.org/issues/show_bug.cgi?id=107775 would trying to reproduce with non-prod allow to find cause for the corruption ? i'm afraid to upgrade to 3.2 because of this issue, i spent two days diagnosing the problem and trying to recover my documents - if i could discover the cause by some additional work, that would motivate me a lot. also... if it would, then i'm back to the strong opinion about oo.org not closing as long as possible to allow me to recover data from non-prod builds, which i might start using on a more regular basis. Ciao Frank -- Rich - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Christian Lippka wrote, On 02/12/10 12:34: Assertions are the first, cheapest and easiest way of defense in the fight for software quality. My 2c, assertions must not abort, developer must use non pro builds, assertions should be used in every new peace of code. I fully agree. -1 for assertions to abort +1 for developers to use non-pros -1 for discussing here whether or not QA should use non-pros, because it IMHO has absolutely no influence on how assertions should behave. And if you want QA to use non-pros, they for sure would give up quite soon when assertions always abort. Malte. Christian Lippka wrote, On 02/12/10 12:34: Am 12.02.2010 12:05, schrieb bjoern michaelsen - Sun Microsystems - Hamburg Germany: On Fri, 12 Feb 2010 09:11:21 +0100 Frank Schoenheit, Sun Microsystems Germanyfrank.schoenh...@sun.com wrote: - Developers should use non-product builds *only*. That's a very apparent measure, still, a lot of people don't do. If you ask why, often the answer is it's unusable 'cause of the many assertions. Hmm? I am one of the devs that rarely use a non-pro build, but not because it's unusable 'cause of the many assertions, but because there are simply to many differences from the product build in them, causing issues (first of all: annoying build breakers). I do, however build with DEBUG=true to see assertions. So you see OSL_ASSERTS from your code, but you never see asserts from code that your code uses. Or things you break with your code in other places. Can you elaborate on the issues that bother you? And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. On the topic of what is an assertion: Yes, assertions should abort. Otherwise, they are not an assertion, but something that is better covered by OSL_TRACE. Assertions are different to build breakers enforced by the changes for warning free code. You can very easy verify that you have not introduced any compiler warning with your changing by simply build the complete office (yes not 100% I know, but you can be very sure). But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. Assertions are the first, cheapest and easiest way of defense in the fight for software quality. My 2c, assertions must not abort, developer must use non pro builds, assertions should be used in every new peace of code. Regards, Christian (using non pro builds for his daily work since 1999) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Stephan, However, contrary to how you read it below, I never intended to suggest that aborting on an assertion was not appropriate in a product build. It is my firm belief that a program that aborts upon assertions is arguably more robust than one that carries on (however paradoxical that may superficially sound). ... If common understanding indeed is that OSL/DBG asserts flag situations where [s]omething didn't go the way it was intended/expected *in the sense that it is a bug,* then, honestly, for a product like OOo, I see absolutely no reason not to abort in such a case. I intentionally did not want to discuss this in this thread here, we both know that we have absolutely contrary opinions on this, and it doesn't really help us solving the current question. So, please let's leave out that question whether an end user program such as ours is allowed to crash, if it could prevent this - we won't come to an agreement on this here and now, as we never did whenever we discussed that :) The thing I would agree on is that there are most probably uses of OSL/DBG asserts in the OOo code base that do not flag bugs in the software itself, but rather flag inappropriate or otherwise interesting events, like unexpected user input or a full disk when the user tries to save a document. These inappropriate asserts have to be changed to things like OSL_TRACE. Which again (what a revenant ...) touches the question of available diagnostics ... Well, I know for sure that I wrote thousands of assertions in the last 10 years which *do* indicate bugs, and changing them to something like OSL_TRACE is a no-go for me (since this would downgrade them to purely informational status). So, at the moment we have assertions which a) should be traces, really b) indicate real bugs, but are recoverable (yes!) and c) indicate bugs, and are unrecoverable. All of those are currently mapped to a message box, which is the problem. I suppose a main point where we disagree is how we solve this, by mapping each and every occurrence to what it really should be. My hope would be that this---trivial---adjustment would happen over time, whenever somebody stumbles over such an inappropriate assert firing. Yes. I also think that we should let this evolve a little bit. Where we disagree is that I don't think aborting is an appropriate measure. (And, enabling aborting assertions in product builds should seriously only be considered when it is known that there are no obviously inappropriate assertions in the code. One more reason why for now I am fine with keeping assertions disabled in product builds.) Yes. I assume that software developers strive to produce quality software, that they are intrinsically motivated, and that they are interested in using whatever adequate tools are available to help them. Like tests, I consider assertions useful tools here. However, as I outlined in the issue, the current state of assertions in OOo is such that they are not useful, so developers do not consider them an adequate tool, so keep away. My hope is that once assertions in OOo *are* a useful tool (i.e., once that backdrop of existing assertion noise is weeded out, and each assertion a developer sees fire with high likelihood points to an error in the code she wrote five minutes ago) people will actually use them. We're on the same track here. One nit to pick: Changing, hmm, medium level code such as svtools will always bear the risk that you cannot check *all* existing clients, and all existing call combinations / code paths. That's simply impossible with a lot of classes there. So, stumbling over an assertion not necessarily means you introduced the bug 5 minutes ago. However, it still means somebody should be *urged* to fix it. Of course, what I want to reach with that issue is not reached (and the issue not fixed) by simply letting assertions abort. Okay, misunderstood this then. We need a plan how to reach the desired zero assertion state. I consciously left it open for now how that plan should look like---I simply do not have the time right now to think about it in the necessary depth. Well, I read the issue as the plan is to let assertions abort, which I think, as said, won't work. However, what is my firm belief, is that aborting assertions are the only viable way to ultimately reach---and then keep---the zero assertion state. I consider this technical approach a beautiful, highly effective measure. I might change my opinion on this once we have an effectively assertion-free product. At the moment, we don't have, and we didn't have back in times where assertions were considered P2 (like: fix immediately) bugs. Much more effective than any social approach, which would be prone to be circumvented, and which we have seen fail for too long by now. (There are analogies to our earlier warning-free code project. If compilers would not technically
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:43:29 +0100 Malte Timmermann malte.timmerm...@sun.com wrote: -1 for discussing here whether or not QA should use non-pros, because it IMHO has absolutely no influence on how assertions should behave. And if you want QA to use non-pros, they for sure would give up quite soon when assertions always abort. With assertions being assertions and give up meaning reporting it, thats exactly the desired behavior. Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging For example, Frank is claiming his asserts are all serious issues and thus shouldnt be degraded to mere traces. So keeping his asserts as assertions, even if they abort should not scare anyone, right? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Am 12.02.2010 13:10, schrieb bjoern michaelsen - Sun Microsystems - Hamburg Germany: For example, Frank is claiming his asserts are all serious issues and thus shouldnt be degraded to mere traces. So keeping his asserts as assertions, even if they abort should not scare anyone, right? No it would make working with a non pro unusable. Also assertions must not always point to bugs, just like compiler warnings are not always point to bugs. But it is still a good idea to keep your code warning and assertion free. Regards, Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Fri, 12 Feb 2010 12:43:29 +0100 Malte Timmermann malte.timmerm...@sun.com wrote: -1 for discussing here whether or not QA should use non-pros, because it IMHO has absolutely no influence on how assertions should behave. And if you want QA to use non-pros, they for sure would give up quite soon when assertions always abort. With assertions being assertions and give up meaning reporting it, thats exactly the desired behavior. nope. not meaning that for sure. give up means stop using anything but some older, proven to be stable, version. just like me. make development versions hard or impossible to use, and nobody will. also, i think question whether qa should use non-prod builds is very on topic - this decision will pretty much determine that. Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging For example, Frank is claiming his asserts are all serious issues and thus shouldnt be degraded to mere traces. So keeping his asserts as assertions, even if they abort should not scare anyone, right? Best Regards, Bjoern -- Rich - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 2/12/10 11:02 AM, Stephan Bergmann wrote: On 02/12/10 09:30, Rich wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. The irony is, once you have hit a programming error, you can no longer have confidence in the program's behavior. It could happen that the data you still manage to save is subtly corrupted, so subtly that you do not notice immediately. This is indeed a dilemma, and there is no golden way out. That said, in the event of a crash (which would include the abort from an assertion in a non-product build) OOo already tries to save your open documents (and it appears to be somewhat effective at it). Pardon me, but you are confusing me. If as you say we should crash ASAP because an assertion may have subtly corrupted your data, then consequently we shouldn't save the documents either. That may be the puristic vantage point, but crashing and loosing the user's work with 100% probability instead of saving it with 99.5% probability seems a bad idea to me. Because if you're honest, those subtle ways the document may have changed erroneously are really really rare compared to the number of assertions hit. Sure, nobody wants to suffer the consequences of programming errors. However, the software industry happens to be in a state where errors are make that the universe, you may have noticed that errors are not a pure software thing ;-) a frequent reality. The question, then, is how best to carry on once a programming error has been encountered (if the software has the luxury at all to even notice). Fail fast (abort) has the potential to cause the least data loss and the least confusion (the program does not continue running in an uncontrolled state, corrupting the user's data or giving wrong answers to the user). On the contrary, fail fast = abort, is the only way to make 100% sure that the user's work is lost. Carry on regardless (ignoring the detection that the program has reached an uncontrolled state; what effectively happens when assertions are disabled in production systems) can be considered unacceptable behavior. It potentially leads to corrupting the user's data or giving wrong answers to the user, with the user not being aware that those answers are wrong. Yes, shit occasionally happens. But with the same reasoning we should abandon all traffic, because there have been accidents. Simply crashing *on purpose* is IMHO not a solution. Give the user the choice to continue at least. If warning boxes pop up all over the place, the point of users filing issues is also achieved but at the same time gives the user the opportunity to save his work. Just my 2 cents, pl -- Sanity is just a bad excuse for a lack of imagination. -- Author unknown Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Thomas Schröder, Wolfgang Engels Chairman of the Supervisory Board: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 12:34, Christian Lippka wrote: But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. If with introducing them you mean introducing assertions: People who write extremely bad code (code that contains programming errors and additionally lacks assertions, that would allow to identify those programming errors more easily) have to be handled in some way, yes. But, if left unhandled, those people will write bad code whether or not assertions abort. If with introducing them you mean introducing [i.e., using] non-pro builds: The logic of preferring a pro over a non-pro here, as, upon encountering a programming error the pro carried on regardless (and potentially silently corrupted data, or silently gave wrong results) whereas the non-pro failed fast, looks faulty to me. Assertions are the first, cheapest and easiest way of defense in the fight for software quality. Yes. And we have that tool at our disposal, but let in run blunt, so that it is largely unused today. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 2/12/10 12:32 PM, Frank Schoenheit, Sun Microsystems Germany wrote: On the topic of what is an assertion: Yes, assertions should abort. Otherwise, they are not an assertion, but something that is better covered by OSL_TRACE. Sigh. Again: No matter how the term assertion is defined in theory, in practice there are *hundreds* or *thousands* of assertions (aka usages of DBG_*) which do not match the definition. Saying Assertions should abort because otherwise they're not assertions is, sorry, just closing your eyes against reality. +1 -- Sanity is just a bad excuse for a lack of imagination. -- Author unknown Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Thomas Schröder, Wolfgang Engels Chairman of the Supervisory Board: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:34:33 +0100 Christian Lippka christian.lip...@sun.com wrote: So you see OSL_ASSERTS from your code, but you never see asserts from code that your code uses. Or things you break with your code in other places. Im covering very broad ranges of modules with DEBUG=true, not just the module were I changed code. Can you elaborate on the issues that bother you? Various little annoyances, each not taking long to debug, but those are adding up. And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. Which is a bug. DBG_ASSERT should be killed if favor of OSL_ASSERT anyway, or is there any valid use for having those two? Assertions are different to build breakers enforced by the changes for warning free code. You can very easy verify that you have not introduced any compiler warning with your changing by simply build the complete office (yes not 100% I know, but you can be very sure). But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Assertions should be visible enough to get reported and rare enough to allow usual testing and development on the nonpro builds. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Am 12.02.2010 13:28, schrieb Stephan Bergmann: On 02/12/10 12:34, Christian Lippka wrote: But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. If with introducing them you mean introducing assertions: People who write extremely bad code (code that contains programming errors and additionally lacks assertions, that would allow to identify those programming errors more easily) have to be handled in some way, yes. But, if left unhandled, those people will write bad code whether or not assertions abort. If with introducing them you mean introducing [i.e., using] non-pro builds: The logic of preferring a pro over a non-pro here, as, upon encountering a programming error the pro carried on regardless (and potentially silently corrupted data, or silently gave wrong results) whereas the non-pro failed fast, looks faulty to me. No I ment you change something in the code which causes an assertion to fire. Regards, Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:10:01 +0100 bjoern michaelsen - Sun Microsystems - Hamburg Germany bjoern.michael...@sun.com wrote: Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging On a second thought: Frank is afaid his asserts will get lost in all the OSL_TRACEs we have today, Stephan wants assertions to be assertions. Proposal: - Make all current OSL_TRACEs to a new OSL_TRACE_VERBOSE (available by OSL_DEBUG_LEVEL2 or something) - Make all current OSL_ASSERTs and DBG_ASSERTs to OSL_TRACEs - Keep OSL_ASSERT for real asserts that abort (and creates an P1 when firing on a master) The migration will not change the behavior much but allows the introduction of real assertions. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 13:38, Christian Lippka wrote: Am 12.02.2010 13:28, schrieb Stephan Bergmann: On 02/12/10 12:34, Christian Lippka wrote: But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. If with introducing them you mean introducing assertions: People who write extremely bad code (code that contains programming errors and additionally lacks assertions, that would allow to identify those programming errors more easily) have to be handled in some way, yes. But, if left unhandled, those people will write bad code whether or not assertions abort. If with introducing them you mean introducing [i.e., using] non-pro builds: The logic of preferring a pro over a non-pro here, as, upon encountering a programming error the pro carried on regardless (and potentially silently corrupted data, or silently gave wrong results) whereas the non-pro failed fast, looks faulty to me. No I ment you change something in the code which causes an assertion to fire. ??? Stopping people from chang[ing] something in the code which causes an assertion to fire (in other words: stopping people from introducing programming errors) would be great, no? What am I missing? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 2/12/10 1:33 PM, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On a second thought: Frank is afaid his asserts will get lost in all the OSL_TRACEs we have today, Stephan wants assertions to be assertions. Proposal: - Make all current OSL_TRACEs to a new OSL_TRACE_VERBOSE (available by OSL_DEBUG_LEVEL2 or something) - Make all current OSL_ASSERTs and DBG_ASSERTs to OSL_TRACEs - Keep OSL_ASSERT for real asserts that abort (and creates an P1 when firing on a master) The migration will not change the behavior much but allows the introduction of real assertions. The obvious optimization for that process would be leaving things as they are and introduce an OSL_ASSERT_ABORT for those who really want that. Kind regards, pl -- One SVN to rule them all, One SVN to check out from, One SVN to commit them all and on the harddisks bind them In Las Vegas where the server lies. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 14:38:18 +0100 Philipp Lohmann philipp.lohm...@sun.com wrote: The obvious optimization for that process would be leaving things as they are and introduce an OSL_ASSERT_ABORT for those who really want that. still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 2/12/10 3:05 PM, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). Feel free to do that in gsl. Anything that makes you happier ;-) - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. Please note the for those who really want that. Frank also didn't want assertions to crash, so perhaps he actually doesn't want them to. But anyway that would be up to him IMHO. No need for any should be the first from you or me ;-) Kind regards, pl -- Sanity is just a bad excuse for a lack of imagination. -- Author unknown Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Thomas Schröder, Wolfgang Engels Chairman of the Supervisory Board: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Bjoern, - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). Welcome to the How should our diagnostics system look like discussion. I think we started that topic at least three times in the last 4 years :) - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. Hmm, seems I expressed myself wrong somewhere. I never claimed that my assertions are so serious that they should be aborts. I claimed that the assertions I write point to a bug, if they fire. However, I try my very best all the time to nonetheless gracefully handle the situation, to let the user continue her work, even if not everything went as expected, internally. So, this kind of assertions are no traces, since if they fire, they indicate a bug. Nonetheless, they (usually) should not abort ... (more on this below) For the diagnostics system, and how it could look like: I strongly agree that having two systems is weird, and they should be unified. This was consensus everytime we discussed this in the past. Also, I am fine with introducing assertions which abort when they fail. Though, I believe they should be used with extreme caution only. There's a reason why we spent *so much* time with crash reports, and fixing crashes: In the user's perception, a crash/abort is one of the worst things which can happen. I'd claim that we, as developers, usually have more options than abort, which can lead to a much better user experience. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Bjoern, With assertions being assertions and give up meaning reporting it, thats exactly the desired behavior. Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging I'm somewhat unlucky with the terms tracing and logging ... I don't want this to be a mere trace here: Tracing is used for Oh, by the way, user just selected Font X into Device Y, and stuff like that (try enabling traces in the Ctrl-Shift-Alt-Dialog to see what I mean). Tracing is *merely* informational, and usually carrying information which is useful for following the program flow without a debugger. This is what I would define as tracing. With this, an OSL_ENSURE is not tracing, it is an error report: At the moment of the writing the context, it was assumed some condition is always true. Over time, as the context evolved, this was violated - reporting this violation surely is not tracing or logging. (Whether or not one should try to gracefully handle the violation is exactly the question which is good for some more religious wars.) I had hope that we would not need to start the whole discussion about the diagnostics system, again, but it seems it might be necessary before finding consensus ... (and finally, perhaps it's good for something) So, in my opinion we would need 3 levels, at least, not 2: (1) traces (today: OSL_TRACE, DBG_TRACE) (2) error reports (today: DBG_ERROR, DBG_ASSERT, OSL_ENSURE, OSL_ASSERT, OSL_PRECOND, OSL_POSTCOND, and more) (3) error reports which the program does not survive, in particular in a product build, i.e. at the customer's machine (future: OSL_ASSERT_ABORT?) Whether or not (2) should abort in non-product builds - well, multiple people here said that they think that this would undermine the acceptance of non-product builds, both for developers, and for users brave enough to test developer snapshots as non-product builds. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Hi Bjoern, Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Ah! Did you know that testtool, the program for running automated UI level tests on OOo, can capture and report assertions? If you claim that assertions should be tested with the common tests, this immediately implies that testtool runs should be done on non-product builds. Which brings the QA should use non-products topic back onto the plate. And I continue to think that if we're serious about assertions being a cheaply available first line of defense against bugs (and it seems we all agreed on that), then non-product builds should get a much higher standing than they have now - in all departments: engineering, QA, release engineering. Assertions should be visible enough to get reported and rare enough to allow usual testing and development on the nonpro builds. Full agreement. Still, we need the plan Stephan mentioned ... the plan how to reach that. And effectively, I don't think we'll get anywhere without a concentrated effort, much like it was done with warning-free code. That is, we should dedicate time for making smoketest and cat-0 tests, at the very least, assertion-free. Ideally, let's make all testtool-tests assertion-free. Optionally, make API tests and complex test assertion-free, too (though I think this would not be strictly necessary in a first run). Then, let's oblige everybody to use them in their daily work - at least all developers and all QA engineers. And finally, let's discuss how this obligation should look like, and if it can reasonably be enforced by technical means (e.g. by aborting in non-product builds). Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 15:05, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Fri, 12 Feb 2010 14:38:18 +0100 Philipp Lohmann philipp.lohm...@sun.com wrote: The obvious optimization for that process would be leaving things as they are and introduce an OSL_ASSERT_ABORT for those who really want that. still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. I also cannot see any benefit in having both DBG_ASSERT and OSL_ASSERT. So +1 for that cleanup. But still after reading the whole thread I do not understand why an assertion should abort at all. Assertions are for informations. A non-informal aborting assertion mixes up concepts in my opinion. For a place where you would place the suggested OSL_ASSERT_ABORT I would suggest to place a normal assertion and in addition throw an exception. The exception should be normal product code, if you know that the reached state is that bad. I (as many other developers I believe) use assertions for all those places where I expect things to be a certain way. In case the expectations are not met the willing listener is informed about a potential problem. We have quite nice tooling for our assertions. If there are too many, you can pipe them all in a window and check them later for new introduced ones. So even many assertions occuring is no reason to not use a non pro build. -1 for assertions to abort +1 for developers to use non-pros (though one must be allowed to use pro builds for performance relevant work of course) +1 for assertion bugs getting a higher priority +1 for providing non pro builds during release branch +1 for cleaning up DBG_ASSERT and OSL_ASSERT Ingrid BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Am 12.02.2010 13:44, schrieb Stephan Bergmann: On 02/12/10 13:38, Christian Lippka wrote: Am 12.02.2010 13:28, schrieb Stephan Bergmann: On 02/12/10 12:34, Christian Lippka wrote: But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. If with introducing them you mean introducing assertions: People who write extremely bad code (code that contains programming errors and additionally lacks assertions, that would allow to identify those programming errors more easily) have to be handled in some way, yes. But, if left unhandled, those people will write bad code whether or not assertions abort. If with introducing them you mean introducing [i.e., using] non-pro builds: The logic of preferring a pro over a non-pro here, as, upon encountering a programming error the pro carried on regardless (and potentially silently corrupted data, or silently gave wrong results) whereas the non-pro failed fast, looks faulty to me. No I ment you change something in the code which causes an assertion to fire. ??? Stopping people from chang[ing] something in the code which causes an assertion to fire (in other words: stopping people from introducing programming errors) would be great, no? What am I missing? Let me re explain it :-) I compared warning free code which breaks the build to assertions which schould not break the build. If you change code at one place, you may cause a compiler warning at another place. This is easy to catch if you do a complete build so chances are high you will not introduce build breaker in the master. If this would not be the case, release eng. would disable warning free code rather sooner than later since the get tired to fix other peoples build breakers. If you change code at one place, you may cause an assertion to trigger at another place. But unlike compiler warnings there is no way to check the complete office for assertion automaticly. Therefore assertions will pop up in the master and annoy others, causing sooner or later that all people use only pro again. FAIL. Therefore assertions will and do pop up in the master. which is no problem if they get fixed in time. If there is a milestone that has to many assertions, you can already redirect them in a window (right after you wrote the author of that assertion a P1 issue). If this is still not understandable, I will draw you a flow chart on monday at your office :-) Before anyone argue, yes you can introduce compiler warnings on other plattforms. Since at least most sun developers do 3-4 plattforms on each cws before they give them to QA, this is a minor issue. Christian. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
Am 12.02.2010 15:05, schrieb bjoern michaelsen - Sun Microsystems - Hamburg Germany: On Fri, 12 Feb 2010 14:38:18 +0100 Philipp Lohmannphilipp.lohm...@sun.com wrote: The obvious optimization for that process would be leaving things as they are and introduce an OSL_ASSERT_ABORT for those who really want that. still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). Thats a given, you have spare time your manager does not know about? - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. If we make the office crash in non pro than there will be never a chance to get the qa to work on non pro again. By the way as said earlier, qa used to look at non pro all the time for years. Then at some point in time the vcl based auto tests got so slow on non pro, the qa stoped using non pro. Also, an assertion that aborts hinders my work with the office as long as the assertion is not fixed. One abort assertion in writer with 100 people working on the writer causes one to fix the issue and 99 to idle until he has finished and commited the fix. If you like your assertions to abort, you can press the cancel button. I remember times before we introduced cws handling where we had developer masters which would not be usable because of crashes. I'm not eager to go back to those times. Also again, assertions are good to have, if an assertion fires, thats bad. And not only if this assertion is implemented by Frank or me. If you have a function that accepts integer values from 0 to 100 as a parameter and you get a -1, thats an assertion, not a trace! If your function is a real time killer if the caller does not sort the array he gives you beforehand, thats an assertion, not a trace! If the xml filter reads customer data from an xml file and can not find the property at the model to set it, thats an assertion, not something to log! Maybe we all should put away our modern and cool scrum books for a while and re read some boring and old fashioned coding principles 11 from the past... Regards, Christian PS: I'm hopefully not to sarcastic on this issue, but its hard to be calm on an issue that we discuss once a year with the same arguments and the same outcome :-) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 17:31:18 +0100 Christian Lippka christian.lip...@sun.com wrote: If we make the office crash in non pro than there will be never a chance to get the qa to work on non pro again. Depends. If we make the master crash on tests in every milestone, sure. As said before an aborting assertion should only be used for corrupt internal state. If you notice a pointer to dead objects flying around or invalidated iterators that are used it is _Good_ to crash on non-pro, simply because continuing from there is pure luck (and its so much more fun to debug if dead objects have devastated the program state by a decent fandango on core). Also, an assertion that aborts hinders my work with the office as long as the assertion is not fixed. One abort assertion in writer with 100 people working on the writer causes one to fix the issue and 99 to idle until he has finished and commited the fix. If you like your assertions to abort, you can press the cancel button. It not difficult to temporarily comment out the one assertion that went past the tests on the cws and on the master until that P1 is fixed. IIRC, Stephan said on FOSDEM that he intends to get tests to run on the master too. Assertion-free execution of those should be part of that. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On 02/12/10 17:54, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Fri, 12 Feb 2010 17:31:18 +0100 Christian Lippka christian.lip...@sun.com wrote: If we make the office crash in non pro than there will be never a chance to get the qa to work on non pro again. Depends. If we make the master crash on tests in every milestone, sure. As said before an aborting assertion should only be used for corrupt internal state. If you notice a pointer to dead objects flying around or invalidated iterators that are used it is _Good_ to crash on non-pro, simply because continuing from there is pure luck (and its so much more fun to debug if dead objects have devastated the program state by a decent fandango on core). If those disastrous states cannot be detected in the pro than ok for an additional ASSERT_ABORT, but as long as you can detect the disastrous states also in the normal product build, they should be handled there. Throw a normal exception from the normal product code. The calling code then can decide what to do with that exception. Ingrid - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 2010-02-12 at 15:53 +0100, Frank Schoenheit, Sun Microsystems Germany wrote: finding consensus ... (and finally, perhaps it's good for something) So, in my opinion we would need 3 levels, at least, not 2: (1) traces (today: OSL_TRACE, DBG_TRACE) (2) error reports (today: DBG_ERROR, DBG_ASSERT, OSL_ENSURE, OSL_ASSERT, OSL_PRECOND, OSL_POSTCOND, and more) (3) error reports which the program does not survive, in particular in a product build, i.e. at the customer's machine (future: OSL_ASSERT_ABORT?) Not having much knowledge, let me offer a factoid instead. This is from the core tarfile. Script ... #!/bin/bash # # count assertions in OOo source # # execute within top unpacked directory of OOo # echo counting assertions and so forth in $(pwd) for str in OSL_TRACE DBG_TRACE \ DBG_ERROR OSL_ENSURE OSL_ASSERT \ OSL_PRECOND OSL_POSTCOND \ OSL_ASSERT_ABORT do printf %.25s : $str . grep--recursive \ --regexp=$str \ . \ | wc--lines done echo done Result ... counting assertions and so forth in /tmp/DEV300_m71 OSL_TRACE ... : 2427 DBG_TRACE ... : 290 DBG_ERROR ... : 4007 OSL_ENSURE .. : 10372 OSL_ASSERT .. : 3867 OSL_PRECOND . : 735 OSL_POSTCOND : 108 OSL_ASSERT_ABORT : 0 done Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
