This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, All:
Now, the analysis: according to strace, the spawning process (e.g., the shell) does receive the Windows exception C0000135 (a.k.a. STATUS_DLL_NOT_FOUND), handles it, and uses it to set exit code to 0x35. My guess is that neither cmd.exe nor the Windows launcher install a handler for the exceptions, and thus the default Windows handler (which creates a pop-up) is used.
I used strace and got some interesting results: a.) run with the whole path. $ strace.exe /cygdrive/d/dev/gecko-sdk/bin/xpidl.exe strace.exe: error creating process D:/dev/cygwin/cygdrive/d/dev/gecko-sdk/bin/xp idl.exe, (error 3)
b.) goto that dir, then run $ strace.exe ./xpidl.exe --- Process 1736, exception C0000135 at 7C984ED1 ypwang@ypwang /cygdrive/d/dev/gecko-sdk/bin It will pop-pu the "cannot find Xxx.dll " windows.
These strange behaviour is caused by path.cc in utils. When given a's path, it can not parse it correctly (ONLY when with /cygdrive/xxx, /usr/bin/xxx is OK.) . the attachment shows the evidence.
So It seems cygwin can handle the exception (at least in strace). It is maybe a question to the bash 3.1.
Attachment:
strace-2behaviour.txt
Description: Text document
-- 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/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |