When the spec doesn't specify expression evaluation order debug and release can behave differently. I got into such situation once... :-(
On 11/13/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
Any assert(expr) can change a control flow of the debug build.... On 11/12/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > On 11/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > Sure, contributors should check debug or even both debug and release > > builds > > > and comment about this in JIRA. > > > > As far as I understand the only person who answers for the commit is a > > committer. So I don't think that establishing a policy that shifts a > > part of responsibility from the committer is a good idea. > > > > Well, I have another silly question to gurus indeed. Is there any > > possibility that some piece of code can break / hang the release build > > if it passes ok on the debug build? > > > > Theoretically it is possible to have problems on release build even if > debug build passes the checks. More sofisticated optimizations applied in > release build may reveal some subtle error in the code. Practically tis is > not a common case though. > > Thanks, > Pavel > > Thanks, > > > > 2006/11/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>: > > > Sure, contributors should check debug or even both debug and release > > builds > > > and comment about this in JIRA. > > > > > > I'm talking about committers, will they test debug build which takes 5 > > times > > > more time? And does it mean they will be able to apply 5 times less > > patches? > > > > > > > > > Actually I'm fine if the committers will check both debug and release > > builds > > > and I encourage them to check on all supported platforms. But I'm not a > > > committer. :) > > > > > > Thanks, > > > Pavel > > > > > > > > > On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > > > I can understand that the contributor may not have access to multiple > > > > platforms, but surely he can test using both debug and release builds > > :-) > > > > What do we gain by asking the contributor to test less? > > > > > > > > Rana > > > > > > > > > > > > On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > +1 for debug testing before submitting a patch. > > > > > > > > > > But, for pre-commit testing we should be careful saying we'll test > > all > > > > the > > > > > patches in debug mode. Though it imprves quality of checks, debug > > build > > > > is > > > > > significantly slower then release, especially when running with > > > > > interpreter > > > > > or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode > > and > > > > it > > > > > takes about 5 times more time than release version on my laptop, The > > > > times > > > > > were as follows: > > > > > > > > > > "build test", Windows XP/ IA32: > > > > > DRLVM release: 22 min 55 sec > > > > > DRLVM debug: 99 min 23 sec > > > > > > > > > > So, may be the good choice will be to ask patch submitters to check > > > > their > > > > > patches on the debug build and, if the JIRA issue contains comments > > that > > > > > this check is passed, committers may test it on release build only. > > > > > > > > > > Thanks, > > > > > Pavel > > > > > > > > > > On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Well, since the problem is repeatable.... :) > > > > > > > > > > > > > > > > > > Gregory Shimansky wrote: > > > > > > > Geir Magnusson Jr. wrote: > > > > > > >> > > > > > > >> > > > > > > >> Alexei Zakharov wrote: > > > > > > >>> Hi DRLVM fans, > > > > > > >>> > > > > > > >>> I encountered a rather strange problem while working on some > > class > > > > > > >>> library tests. At least two tests from the beans module hang > > (or > > > > > > >>> crash) while running on DRLVM debug builds but work fine on > > DRLVM > > > > > > >>> release builds. I thought that debug build is something about > > > > adding > > > > > > >>> debug symbols to VM binaries and this should not affect the > > > > > > >>> functionality. Can someone shed a light on this? > > > > > > >> > > > > > > >> I would think it's just an assertion firing... > > > > > > > > > > > > > > Actually it is more than that. In debug mode TRACE statements > > are > > > > > > > compiled and therefore produce executable code. There may also > > be > > > > some > > > > > > > bugs in compiler generating code in different modes (although > > this > > > > > > > usually happens for release). > > > > > > > > > > > > > > I don't know why hanging happens, but the difference in > > generated > > > > code > > > > > > > is actually quite big. Also assertions or any crashes go to > > > > > > > exceptions/signal handlers which may happen to loop infinitely, > > > > there > > > > > > > were bugs like this happening on the current version of sources, > > > > look > > > > > at > > > > > > > HARMONY-2018 and HADMONY-2006. > > > > > > > > > > > > > >>> This is the first > > > > > > >>> question. The second question - what we should do with such > > tests. > > > > > The > > > > > > >>> tests pass on the downloadable HDK and JRE snapshots as well > > as on > > > > > > >>> classlib + j9. What should be the commit criteria for DRLVM – > > i.e. > > > > > > >>> what is the *true* build? :) I think many people here > > currently > > > > use > > > > > > >>> snapshots to test their patches. > > > > > > >> > > > > > > >> debug :) don't sweep the problems under the rug... > > > > > > > > > > > > > > +1 > > > > > > > > -- > > Alexei Zakharov, > > Intel Enterprise Solutions Software Division > > > >
