Good news here. A couple of memory corruption bugs were resolved recently, so I was able to integrate the fix at r602080. As a bonus, total size of drlvm dlls become less for ~4M on Win32 and ~12M on Win64. Not bad IMO ;)
PS Beware to do clean rebuild of drlvm. -- Regards, Alexey 2007/10/19, Gregory Shimansky <[EMAIL PROTECTED]>: > Alexey Varlamov wrote: > > Guys, I've filed HARMONY-4973 with workable patch. > > Bad news is that there are spurious errors in gc_gen shutdown (see the > > JIRA for details), most possibly corrupted heap :(. BTW, I possibly > > found mismatching "delete" vs "free" usage: > > vm/gc_gen/src/thread/marker.cpp:143: delete marker->trace_stack; > > vm/gc_gen/src/thread/collector.cpp:223: delete collector->trace_stack; > > > > But those are not the rootcause. Any help or ideas will be appreciated... > > There was a reported problem with recent updates that some tests crash > on shutdown with diagnostics about corrupted C heap. There is a JIRA > that might help with it (HARMONY-4960). I am currently testing it and > I'll report whether it fixes corrupted heap on interpreter. Maybe heap > is actually corrupted in JIT mode as well, but MSVC checks don't detect > it when VM is built without your patch. > > > 2007/10/17, Alexey Varlamov <[EMAIL PROTECTED]>: > >> A kind of roadblock here is the initial issue of debug vs release > >> runtime DLLs. It is desirable to have fully redistributable debug > >> build, isn't it? So it would be nice to avoid MSVCR71D.DLL dependency. > >> Actually the sole thing which requires debug runtime is the > >> disable_assert_dialogs() feature, which may affect release build as > >> well - e.g. if we compile release but w/o NDEBUG to leave asserts > >> enabled. I'll try to dig if it can be workarounded. > >> > >> -- > >> Alexey > >> > >> > >> 2007/10/17, Gregory Shimansky <[EMAIL PROTECTED]>: > >>> Alexey Varlamov wrote: > >>>> Hi all, > >>>> > >>>> Looking on HARMONY-3964 "[drlvm][build] missing MSVCR71D.DLL > >>>> dependency for debug builds", I'm surprised to realize that only GC > >>>> dlls in VM ever depend on MSVCR*.DLL, no matter release or debug. > >>>> All the rest of VM is linked against static LIBCMTD.LIB so every dll > >>>> carries it's own copy of C runtime, with independent heaps and static > >>>> data! Now it explains all that troubles with bad frees in > >>>> HARMONY-3772, and why each dll has to disable assert dialog > >>>> individually (HARMONY-4715). I've just tried fully dynamic build and > >>>> indeed all these problems are gone. > >>>> > >>>> I guess why it was done so, and the only reason I could think of is > >>>> historycal. Does anyone knows other explanation? Otherwise I believe > >>>> the build must be fixed to link with MSVCRxx.DLL always. Especially as > >>>> we already redistribute them with classlib. > >>> I agree very much that dynamic build would be much better. The only > >>> reason why it wasn't done I think is that it just wasn't easy to do this > >>> in the current ant based build system. If you can do it please go ahead > >>> and commit! > >>> > >>> BTW don't forget about windows x86_64. > >>> > >>> -- > >>> Gregory > >>> > >>> > > > > > -- > Gregory > >
