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 > > > > > > >
