harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm] linking with runtime libraries on windows
Date Fri, 19 Oct 2007 09:37:20 GMT
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 <alexey.v.varlamov@gmail.com>:
>> 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 <gshimansky@apache.org>:
>>> 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


Mime
View raw message