Oliver Deakin wrote:
Thanks Gregory - I applied the patch from HARMONY-3772 but I still
receive the same assertion after rebuilding. The Harmony stack seems to
end at line 54 in logparams.h, which is:
LogParams& operator<<(const char* message) {
if (!is_def_messageId_set) {
def_messageId = strdup(message); <---- Line 54
is_def_messageId_set = 1;
return *this;
} else {
string logger_string;
logger_string += message;
values.push_back(logger_string);
return *this;
}
}
but I don't know why this might cause the assertion I'm seeing.
Anyone have any ideas?
There is a known strange behavior of MSVC runtime in debug mode. For
some reason memory allocated in one DLL cannot be freed in another one.
I am not sure how to disable this check (BTW it is useful sometimes,
e.g. I found bug in HARMONY-2669). I suspect this is the same problem in
this case.
Gregory Shimansky wrote:
Oliver Deakin wrote:
Hi all,
I was taking a look at HARMONY-4006 and thought I'd try creating a
simple launcher as a test. I updated my federated build checkout and
rebuilt everything, giving me the usual hdk structure under the
target directory (drlvm+classlib). I can successfully use the Harmony
launcher to run simple classes (i.e. HelloWorld) but when I try to
run HelloWorld using my own launcher I get the following message:
EM: Can't read configuration from './client.emconf'
and an assertion pop-up window appears giving me the following
information:
Debug Assertion Failed!
Program: C:\harmony\temp\jnitest\simpleLaunchFederated.exe
File: dbgheap.c
Line: 1132
Expression: _CrtIsValidHeapPointer(pUserData)
The stack trace windbg shows me at the point of assertion is:
ntdll!DbgBreakPoint
ntdll!RtlpBreakPointHeap+0x28
ntdll!RtlpValidateHeapEntry+0x113
ntdll!RtlValidateHeap+0xe0
kernel32!HeapValidate+0x14
em!_CrtIsValidHeapPointer+0xa4
[f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 1807]
em!_free_dbg_lk+0x102
[f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 1132]
em!_free_dbg+0x41 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @
1070]
em!operator delete+0xaa
[f:\vs70builds\3077\vc\crtbld\crt\src\dbgdel.cpp @ 54]
em!std::allocator<char>::deallocate+0x17 [c:\program files\microsoft
visual studio .net 2003\vc7\include\xmemory @ 132]
em!std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Tidy+0x66 [c:\program files\microsoft visual studio .net
2003\vc7\include\xstring @ 1519]
em!std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::~basic_string<char,std::char_traits<char>,std::allocator<char>
>+0x1a [c:\program files\microsoft visual studio .net
2003\vc7\include\xstring @ 458]
em!LogParams::~LogParams+0x44
[c:\harmony\svn-checkouts\federated\working_vm\vm\port\include\logparams.h
@ 54]
em!readFile+0x54b
[c:\harmony\svn-checkouts\federated\working_vm\vm\em\src\drlemimpl.cpp
@ 332]
em!DrlEMImpl::readConfiguration+0x366
[c:\harmony\svn-checkouts\federated\working_vm\vm\em\src\drlemimpl.cpp
@ 355]
em!DrlEMImpl::init+0x48
[c:\harmony\svn-checkouts\federated\working_vm\vm\em\src\drlemimpl.cpp
@ 364]
em!DrlEMFactory::createAndInitEMInstance+0xa9
[c:\harmony\svn-checkouts\federated\working_vm\vm\em\src\drlemimpl.cpp
@ 55]
em!CreateInstance+0x3c
[c:\harmony\svn-checkouts\federated\working_vm\vm\em\src\em_intf.cpp
@ 132]
harmonyvm!CmCreateInstance+0xac
[c:\harmony\svn-checkouts\federated\working_vm\vm\vmstart\src\compmgr\component_manager_impl.cpp
@ 584]
harmonyvm!process_properties_dlls+0x1bd
[c:\harmony\svn-checkouts\federated\working_vm\vm\vmcore\src\init\vm_init.cpp
@ 135]
I can successfully use exactly the same launcher to create the RI and
J9 VMs and run simple classes, so was surprised to hit this problem
with the Harmony vm. Am I missing something?
This stack trace looks similar to stack in HARMONY-3772. There is a
patch there which changes localized logging output to plain and solves
the problem with log4cxx destructors in this way. The main problem
however is that EM cannot find client.emconf file and tries to print
an error message.
--
Gregory