[reSIProcate] RE: iphlpapi.dll in ares

[Scott Godin <slgodin@xxxxxxxxxxxx>]

I've attached the old email on why I changed it.

As far as it failing - did you try putting a call to GetLastError() if the
handle returned from LoadLibrary is NULL?  It will return a Win32 error code
that might help troubleshoot the problem.

Note:  I run Win2k without any issues.

-----Original Message-----
From: Jason Fischl [mailto:jason@xxxxxxxxxxxxxx] 
Sent: Friday, October 29, 2004 2:01 PM
To: Scott Godin
Cc: Resiprocate
Subject: iphlpapi.dll in ares

Hi Scott,

I recently ran into a strange problem on a win2k machine. The call to 
LoadLibrary ("iphlpapi.dll") is failing on one of my win2k systems. If I 
just call the methods directly, it works - but I haven't been able to 
figure out why LoadLibrary is failing. The library is clearly there and 
works for me. Any ideas? What was ther reason for the change to 
explicitly loading the library?

Jason

--- Begin Message ---

• From: Scott Godin <slgodin@xxxxxxxxxxxx>
• Date: Fri, 18 Jun 2004 12:25:36 -0400

Hi Guys!

OK - this is a strange one.  I finally narrowed it down to the following
test program.  The call to gethostname in the thread deadlocks - but the one
in the main thread is OK.  This happens if I link in both ncemgr.lib and
iphlpapi.lib.  Ncemgr.lib is a library our product uses from Nuance
Communications for voice recognition.  Since I don't have any control over
this I'm not sure what the problem really stems from.  If I removed either
iphlpapi.lib or ncemgr.lib - everything works OK.  Please read past the code
for more discussion...

int WINAPI SIPt(void *)
{
   char buffer[1024];  
   Sleep(2000);
   gethostname(buffer, sizeof(buffer));
   return 0;
}

extern "C" int WINAPI _tWinMain(HINSTANCE hInstance, 
    HINSTANCE /*hPrevInstance*/, LPTSTR lpCmdLine, int /*nShowCmd*/)
{
        UINT uiThreadID;        _beginthreadex(NULL, 0, (unsigned int
(WINAPI *)(void *)) SIPt, NULL, 0, &uiThreadID);
   char buffer[1024];   gethostname(buffer, sizeof(buffer));
        Sleep(8000);
     gethostname(buffer, sizeof(buffer));

    return 0;
}

NOTE:  There are other source files to ensure the linkage of ares.lib and
ncemgr.lib - but they are never called.

Linking with iphlpapi.lib dynamically in ares_init seems to make the problem
go away.  Are you guys OK with me checking in changes to ares_init that
dynamically load iphlpapi.lib (ie. Via LoadLibrary)?  If the load fails (ie.
No DLL on target system) I could revert back to using the old method - or
just fail.  

Attached is my proposed solution - with no fallback if iphlpapi.dll does not
exist.  Note:  This also means the app doesn't need to link with
iphlpapi.lib anymore.

What do you think?

Thanks,

Scott

-----Original Message-----
From: Ken Kittlitz [mailto:ken@xxxxxxxxxx] 
Sent: Friday, June 18, 2004 10:16 AM
To: Scott Godin
Cc: Scott Godin; 'Alan Hawrylyshen'
Subject: Re: [reSIProcate] nameserver fix....

Scott Godin wrote:

>Thanks Ken,
>
>I'll work on a test driver tomorrow.  Some answers to your questions are
>below....
>
>  
>
Thanks!

>[Scott] - I noticed the missing GlobalFree too.  I added it in - but it
>didn't change the behavior.  Actually the deadlock happens before the stack
>is even created and without even calling GetNetworkParams.  From what I
have
>seen so far:  If I link with the new library and the first "resip related"
>call I make is Log::initialize - it deadlocks.  Seems very odd to me - I'm
>sure it's something unique to my environment.
>
>  
>
Very odd.  Even if it does turn out to be unique to your environment, I 
apologize for the hassle.  I'd hoped that  using the Iphlpapi library 
would make things better, not worse :-(
    -Ken

Attachment: ares_init.c
Description: Binary data

--- End Message ---