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]

Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?


marco atzeri wrote:
On 4/28/2012 6:10 AM, marco atzeri wrote:
On 4/28/2012 12:34 AM, Ken wrote:
Hello,

When attempting to do a download "ONLY", setup.exe caused the following
error to be displayed on Windows 7 64-bit:


=======================================================

Microsoft Visual C++ Runtime Library:

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
=======================================================



I tried a few different mirrors with the same result.


Then, I used a previous version of setup.exe, v2.769, and, aside from
the warning that the setup.ini file is from a newer version of setup, it
worked fine.


Is setup v2.772 broken?

Kind regards,
Ken


I will bet more on BLODA. I already saw something like that in the past
in an old version when downloading the mirror list.


Marco



Hi Ken,
I just noted the same error with 2.772 when downloading from my site
that has only setup.ini and not setup.bz2.
Adding the setup.bz2 bypassed the crash, but crash on missing setup.bz2.sig ; usually I do not see it as I use setup -X that skips the signature check.


BLODA is still a possibility, I have Symantec installed; or there is subtle bug handling the missing files on the website

Marco


Hi Marco,

Nice to see that you can reproduce the problem! I neglected to mention that this seems to occur immediately after the initial setup.ini download (even to a fresh, non-cached, local folder), but it would seem that you have reproduced what I am experiencing. As I mentioned, the download operations work fine with the previous version of setup.exe (from 1.7.13); which is why I question whether or not something is slightly awry in the new version.

As a test, I just tried using the -X option (as I already use a few of the other options for scripting purposes for the downloads) and the same error occurred. The command-line syntax I have been using for a long time is:

setup.exe -q -D -O -R <SOME-UNIQUE-DIR> -s <SOME-MIRROR-SITE> -l <LOCAL-DIR-FOR-MIRROR-SITE> -P <package[,package,...]>

However, even when using SETUP's GUI directly (setup -X) for a download-only operation, the failure persists; and the process never progresses to the package selection screen.

With that, I decided to do some additional testing and it appears that I am being bitten, even more so, by a problem I had reported previously here:

http://cygwin.com/ml/cygwin/2011-03/msg00756.html
With subsequent responses of:
http://cygwin.com/ml/cygwin/2011-04/msg00011.html
http://cygwin.com/ml/cygwin/2011-04/msg00021.html
http://cygwin.com/ml/cygwin/2011-04/msg00128.html
http://cygwin.com/ml/cygwin/2011-04/msg00329.html

Though I never determined the root cause, until now it appeared that I could safely ignore the warnings/failures since the resulting downloads always matched another system; where those pesky errors did not occur. Perhaps a subtle change in the latest setup.exe exacerbates the underlying issue with my PCs I/O sub-system? Could a timing issue in the code execution be the cause (not allowing for the RAID buffer flush or some such nonsense)?

Currently, the setup 2.772 failure ONLY occurs when my local download directory is on a PHYSICAL disk (a simple RAID1 volume). However, no failure occurs when I create, mount, and use a Virtual Hard Drive (VHD) as the download directory - yet the VHD file itself resides on the same physical disk used above. *Please refer to the attached files* for the results of each setup.exe test.

Note that this is all on the same Windows 7, 64-bit, core-i7 system. It would be helpful to know if anyone else has experienced these issues on a similarly configured system.

Perhaps a bit off topic, I have avoided using -X option since my presumption is that this could allow malformed/incomplete package(s) to be download without any error indication. Am I off-base here?

As for BLODA, though I cannot dismiss that just yet, it is odd that the previous version of setup works on this same system. And, the failure does not occur for the VHD. By the way, while I realize that BLODA can be more than antivirus/malware products, I am using Eset's NOD32 Antivirus (I have found Symantec and McAfee products to be system resource hogs - too much so for my liking).

Thank you for your assistance!

Kind regards,
Ken

Attachment: setup_2772_output_for_PHYSICAL_disk_location.txt
Description: Text document

Attachment: setup_2769_output_for_PHYSICAL_disk_location.txt
Description: Text document

Attachment: setup_2772_output_for_VIRTUAL_disk_location.txt
Description: Text document

Attachment: setup_2769_output_for_VIRTUAL_disk_location.txt
Description: Text document

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]