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
