ASSERT (r2692) module_load_event:modules.dll.c:98

[derekbruening]

From byron.c....@gmail.com on June 04, 2014 06:36:56

On Windows 7, the module name found in (module_data_t.names.module_name) can be lowercase, in which case this test will fail. On my machine I get lowercase in some builds and uppercase in others. Since Windows is case insensitive in regard to module names, I think the test should be changed to case-insensitive name comparison on Windows.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1452

[derekbruening]

From bruen...@google.com on June 04, 2014 07:40:22

Yes please

Status: Accepted
Owner: byron.c....@gmail.com
Labels: Component-Tests OpSys-Windows

[derekbruening]

From byron.c....@gmail.com on June 05, 2014 00:56:00

On the linux side, the 32-bit build of this test fails in my environment because Ubuntu no longer installs the i386 version of libz.so.1 by default. Should I update the test output with a hint for the user when dlerror() reports "file not found"?

[derekbruening]

From bruen...@google.com on June 05, 2014 03:57:53

Should I update the test output with a hint for the user when dlerror() reports "file not found"?

Or even better, switch to some other library that is there?

[derekbruening]

From byron.c....@gmail.com on July 08, 2014 17:42:54

There's a problem with aux libs and memory protections. When an aux lib is unloaded, the corresponding vmarea gets marked as empty, but does not get removed. If an UNMOD image later gets loaded into the same location in memory, core/unix/memcache.c:memcache_handle_mmap() thinks there is a memory protection change. This leads to an assert failure:

Internal Error: DynamoRIO debug check failure: /scratch/dr1/dynamorio/core/vmareas.c:987 TEST(VM_UNMOD_IMAGE, v-buf[i].vm_flags) || !TEST(VM_UNMOD_IMAGE, vm_flags)

The reason this problem appears now is that the new appdll module happens to be the same size as the aux test lib, making it possible (and quite common) for the OS to load both modules into the same memory location (since one module is loaded after the other is unloaded). There is a comment in memcache_handle_mmap() which may not be quite correct:

/* We detect some alloc-based prot changes here. app_memory_pre_alloc()

• should have already processed these (issue NtAllocateVirtualMemory can change protection bits on existing pages #1175) but no harm calling
• app_memory_protection_change() again just in case.
  */

Though maybe the real problem is that the vmarea for the aux lib should have been completely removed. I think it's over my head at this point.