cygwin DLL problem?

[Konovalov, Vadim (Vadim)** CTR **]

> From: Will Coleda [mailto:will at coleda.com] 
> On Fri, Oct 16, 2009 at 6:37 AM, Konovalov, Vadim (Vadim)** CTR **
> <vkonovalov at alcatel-lucent.com> wrote:
> > Hi,
> >
> > I am trying Tcl/Tk with parrot, and found some interesting 
> misfeature with loadlib.
> >
> > My parrot program, essentially, tries to do until success:
> >
> >    libname = "tcl85"
> >    library = loadlib libname
> >
> >    libname = "tcl84"
> >    library = loadlib libname
> >
> > If the proper tcl85.dll or tcl84.dll is in %PATH%, all is okay.
> >
> > The problem arises if there is a tcl84.dll on %PATH%, which 
> is inside cygwin.
> > This tcl84.dll works okay within cygwin, and the 
> dependencies on this library are okay:
> >
> > c:\> vc dumpbin /dependents tcl84.dll
> > ....
> > Dump of file tcl84.dll
> >
> > File Type: DLL
> >
> >  Image has the following dependencies:
> >
> >    ADVAPI32.DLL
> >    KERNEL32.dll
> >    USER32.dll
> >    cygwin1.dll
> >
> >
> > But the
> >    library = loadlib libname
> > statement never returns.
> > CPU load is 0%, Ctrl+C does not work, and the only way to 
> continue is to end the task from "Task Manager"
> >
> > Will be grateful on any advices on the matter.
> >
> > Best regards,
> > Vadim.
> > _______________________________________________
> > http://lists.parrot.org/mailman/listinfo/parrot-dev
> >
> 
> Run parrot through gdb and try ^C or ^\ there, and check the 
> backtrace?

My parrot was built with MSVC 6.0, fortunately with debugging switches turned on.

So I used debugger, here is the stack trace:

Parrot_dlopen(const char * 0x004e6588) line 38
dlopen_string(parrot_interp_t * 0x003223d8, parrot_string_t * 0x00459520) line 236 + 9 bytes
get_path(parrot_interp_t * 0x003223d8, parrot_string_t * 0x00459520, void * * 0x0012fde8, parrot_string_t * 0x004a0e00, parrot_string_t * 0x004a0e24) line 324 + 13 bytes
Parrot_load_lib(parrot_interp_t * 0x003223d8, parrot_string_t * 0x00459520, PMC * 0x00000000) line 664 + 25 bytes
Parrot_loadlib_p_sc(long * 0x004e6e80, parrot_interp_t * 0x003223d8) line 1321 + 42 bytes
runops_slow_core(parrot_interp_t * 0x003223d8, runcore_t * 0x004d0750, long * 0x004e6e80) line 843 + 22 bytes
runops_int(parrot_interp_t * 0x003223d8, unsigned int 0) line 545 + 18 bytes
runops(parrot_interp_t * 0x003223d8, unsigned int 0) line 119 + 13 bytes
runops_args(parrot_interp_t * 0x003223d8, PMC * 0x0048f334, PMC * 0x00496fd0, parrot_string_t * 0x00000000, const char * 0x101cac1c `string', char * 0x0012fed4) line 269 + 13 bytes
Parrot_runops_fromc_args(parrot_interp_t * 0x003223d8, PMC * 0x0048f334, const char * 0x101cac1c `string') line 338 + 29 bytes
Parrot_runcode(parrot_interp_t * 0x003223d8, int 1, char * * 0x00324efc) line 827 + 22 bytes
imcc_run_pbc(parrot_interp_t * 0x003223d8, int 0, const char * 0x00000000, int 1, char * * 0x00324efc) line 792 + 17 bytes
imcc_run(parrot_interp_t * 0x003223d8, const char * 0x00324f30, int 1, char * * 0x00324efc) line 1075 + 25 bytes
main(int 1, char * * 0x00324efc) line 60 + 21 bytes

This nails down to the function at file "win32/dl.c":

void *
Parrot_dlopen(const char *filename)
{
    return LoadLibrary(filename);
}

Very straightforward.

Now I've created this simple C program:

#include <windows.h>
void main(void) {
    char *fn = "D:\\cygwin\\bin\\tcl84.dll";
    LoadLibrary(fn);
}

and found out that it has the same behaviour.
This is just Win32 API.

Very strange. Either some sort of fail, or even infinite loop with 100% CPU usage could be explained... but this I can't explain.

Any ideas or bits of knowledge on the matter?

Regards,
Vadim.