Mail Archives: cygwin/2003/10/05/20:46:22
On Sun, 5 Oct 2003, Christopher Faylor wrote:
> On Sun, Oct 05, 2003 at 07:43:53PM -0400, Igor Pechtchanski wrote:
> >On Sat, 4 Oct 2003, Christopher Faylor wrote:
> >>Who's going to find these functions? cygpath.exe is not going to
> >>accidentally use ar function with the same name from another DLL.
> >>That's not how it works. msvcrt is being loaded by SHLWAPI.DLL so
> >>there isn't much likelihood of toe stepping between it and cygwin. I
> >>would suspect that cygpath isn't the only program which loads msvcrt in
> >>this fashion. There's not much we can do about it, and if it was a
> >>problem, I think we'd know about it by now.
> >
> >Well, I doubt it, as it is reiterated over and over on this list and in
> >the FAQ that mixing cygwin1.dll with msvcrt.dll is a bad idea.
>
> For *user* programs. Say what you will about Microsoft, but presumably
> they know what they are doing with their DLLs.
>
> Usually when I mention this, I say something like "If you really know
> what you're doing you can do this". I would assume that Microsoft knows
> what they are doing.
>
> (And, please, no Microsoft jokes here.)
>
> >The only application I could find on my system with such a property is
> >/usr/X11R6/bin/XWin.exe (through DDRAW.dll). I may have described the
> >actual mechanism overly simplistically (and frankly, I'm not too sure
> >on exactly how it works), but it seemed likely to be the reason for the
> >hang. And before you ask, I'm unable to reproduce the actual hang, so
> >I can't debug it.
>
> Windows DLLs have been including MSVCRT for years and, in fact,
> cygpath.exe includes msvcrt.dll on my system and it doesn't hang. On my
> system, these programs include msvcrt.dll due to it's inclusion in some
> system dll:
>
> cygpath, exim, gdb, lpr, mkshortcut, passwd,
Oops, the case difference strikes again. Make that "gdb, passwd, wish84
(through tk84.dll)" on my system as well. Sorry. However, AFAIK, none of
them are called from postinstall scripts...
> I think that it is very unlikely that this is the problem.
>
> >> Adding cygstart just adds another non-cygwin process in the mix, causing
> >> cygwin's exec stub to behave differently.
> >
> >So does adding "setup".
>
> I don't know what this means. It is a given that running this from
> setup causes a problem, since that is what the bug report is all about.
> Adding another program (apparently cygstart *is* a cygwin program) to
> the mix doesn't really provide any useful information, AFAICT.
There seems to be a misunderstanding. I wasn't suggesting adding
"cygstart" to a postinstall script, but rather simply calling the program
using cygstart on the command line. I assumed that cygstart and setup.exe
would use the same mechanism to spawn the subprocess (turns out I was
wrong -- cygstart uses ShellExecute, while setup.exe uses CreateProcess).
Using "run -wait" would have been more appropriate.
> >It would be easy to check if the above was the reason for the hang by
> >trying to call the following program from a postinstall script and seeing
> >if it also hangs:
> >------------------------ BEGIN tdll.c -------------------------
> >#include <stdio.h>
> >static int counter = 0;
> >int hello() {
> > fprintf (stderr, ""); /* to pull in msvcrt.dll */
> > return counter++;
> >}
> >------ Note: cutting here may damage your screen surface ------
> >------------------------ BEGIN tapp.c -------------------------
> >int hello();
> >int main() {
> > printf("%d\n", hello());
> > printf("%d\n", hello());
> >}
> >------ Note: cutting here may damage your screen surface ------
> >
> >$ gcc -mno-cygwin -shared -g -o tdll.dll tdll.c
> >$ gcc -g -o tapp.exe tapp.c -L./ -ltdll
> >$ cygcheck tapp.exe
> >Found: .\tapp.exe
> >tapp.exe
> > C:\cygwin\bin\cygwin1.dll
> > C:\WINNT\System32\KERNEL32.dll
> > C:\WINNT\System32\NTDLL.DLL
> > .\tdll.dll
> > C:\WINNT\System32\msvcrt.dll
> >$ ./tapp.exe
> >0
> >1
> >$
> >
> >This would probably be easier to debug than cygpath, too...
>
> Why? The above presupposes that the windows DLLs are doing I/O to FILE
> pointers which AFAICT is not a given.
>
> cgf
Yes, that's true. But if this one hangs too on the machines that exhibit
the cygpath problem, it might confirm or deny my (and Cliff's) WAG.
Mine, at least, is that cygpath hits some condition in SHLWAPI.DLL that
triggers the initalization of some mechanism in MSVCRT.DLL, if not the
actual I/O, which, in turn, causes this hang.
Anyway, as I cannot reproduce the hang on my machine, and cannot
contribute anything but WAGs to the discussion, let's close this thread
until someone produces the actual debugging info.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -