Project

General

Profile

Actions

Bug #6790

closed

mingw-w64: rb_libruby_handle and libruby changes when extensions are loaded

Added by luislavena (Luis Lavena) almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Target version:
ruby -v:
ruby 2.0.0dev (2012-07-25 trunk 36527) [x64-mingw32]
Backport:
[ruby-core:46743]

Description

=begin
Hello,

I started to look into this failure when running dl/handle tests:

test_initialize_noargs(DL::TestHandle):
DL::DLError: unknown symbol "rb_str_new"
C:/Users/Worker/Jenkins/workspace/git-ruby-trunk/test/dl/test_handle.rb:110:in []' C:/Users/Worker/Jenkins/workspace/git-ruby-trunk/test/dl/test_handle.rb:110:in test_initialize_noargs'

Above error only happens with compiled 64bits ruby.

After looking a bit more closer, it seems DllMain from libruby gets called several times when (({x64-msvcrt-ruby200.dll})) is loaded but also when extensions are loaded.

Adding some debug strings into DllMain like the following:

diff --git a/ruby.c b/ruby.c
index ab4b674..6d1a715 100644
--- a/ruby.c
+++ b/ruby.c
@@ -315,8 +315,22 @@ static HMODULE libruby;
BOOL WINAPI
DllMain(HINSTANCE dll, DWORD reason, LPVOID reserved)
{

  • HMODULE self;
  • char filename[MAX_PATH];
  • if (reason == DLL_PROCESS_ATTACH)
  •   libruby = dll;
    
  • {
  •    printf("DLL_PROCESS_ATTACH\n");
    
  •    self = GetModuleHandle(NULL);
    
  •    GetModuleFileName(self, filename, MAX_PATH);
    
  •    printf("self: %#x (%s)\n", self, filename);
    
  •    GetModuleFileName(dll, filename, MAX_PATH);
    
  •    printf("dll: %#x (%s)\n", dll, filename);
    
  •    libruby = dll;
    
  • }
    return TRUE;
    }

Produces the following:

32bits compilation:

C:\Users\Luis\Code\ruby\ruby\x86-installed>ruby -v -rdl -e "puts :ok"
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x86-installed\bin\ruby.exe)
dll: 0x66780000 (C:\Users\Luis\Code\ruby\ruby\x86-installed\bin\msvcrt-ruby200.dll)
ruby 2.0.0dev (2012-07-25 trunk 36527) [i386-mingw32]
ok

64bits (mingw-w64):

C:\Users\Luis\Code\ruby\ruby\x64-installed>ruby -v -rdl -e "puts :ok"
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x6f100000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\x64-msvcrt-ruby200.dll)
ruby 2.0.0dev (2012-07-25 trunk 36527) [x64-mingw32]
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x1ee0000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\encdb.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x6aa00000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\iso_8859_1.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x68080000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\trans\transdb.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x623c0000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\dl.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x63d80000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\fiddle.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x6e6c0000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\utf_16le.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x6a340000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\trans\single_byte.so)
DLL_PROCESS_ATTACH
self: 0x400000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\bin\ruby.exe)
dll: 0x1f10000 (C:\Users\Luis\Code\ruby\ruby\x64-installed\lib\ruby\2.0.0\x64-mingw32\enc\trans\utf_16_32.so)
ok

I just tested a simple project which loads multiple DLLs and DllMain of each DLL do not get invoked several times.

Since each extension depends on (({x86-msvcrt-ruby200.dll})), perhaps that is the reason why (({DllMain})) is invoked multiple times.

Maybe there is something I'm missing? Perhaps a workaround will be set (({libruby})) only once?
=end

Actions

Also available in: Atom PDF