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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

Buchbinder, Barry (NIH/NIAID) [E] schrieb:
Dirk Napierala wrote on Friday, October 10, 2008 5:36 AM:
Buchbinder, Barry (NIH/NIAID) [E] schrieb:
From: Dirk Napierala wrote on Thursday, October 09, 2008 11:48 AM

I'll presume the following.
- You've a "good" reason (company policy?) that you cannot use the
simplest solution -- using the cygwin1.dll version that you know
works.

Is that true? Please confirm. (Just so I don't keep wondering.) Care to share the reason?
The workaround would be to continue using the old one. But as part of a lot of other software release updates, the version currently in
use was also a candidate to be updated to the latest release. And with this new one we discovered the problem. Thats where it all started :-)
OK. One more try at a work-around.

I assume that
  - the script cannot be changed,
  - bash actually does the launching, and
  - company policies allow you to somehow set an alias in the bash
shell that launches sfx-file.exe.

The idea is that when the script tells bash to run sfx-file.exe, bash
actually runs "something else" and that "something else" runs
sfx-file.exe successfully. 

In /etc/profile or .bashrc or your script or somewhere, set up two
aliases.  (You only need one but I don't know which.)

	alias sfx-file.exe=/path/sfx-file.sh
	alias sfx-file=/path/sfx-file.sh

Write the following two-line script.

	#!/bin/sh
	cygstart /path/sfx-file.exe

An alternative three-line script.

	#!/bin/sh
	cd /path
	cmd /c sfx-file.exe

Putting the script in the same directory as sfx-file.exe is probably
the safest possibility. 

When your script wants to run sfx-file.exe, it will actually run
sfx-file.sh and that will launch sfx-file.exe.

Let us know ...
Thanks Barry
Tested successfully .That works fine. But it is not just about one
file. There are hundreds of them called this way.
With various names. Also not all sfx files, but also other .exe files.

Assuming that there are no duplicate file names, put the following in .bashrc (or wherever).

	for Dir in list_of_directories_where_the_EXEs_are_located
	do
		pushd "${DIR}" > /dev/null
		for File in *.exe
		do
			#	make sure that File is executable
			#	and not named "*.exe"
			if [ -x "${File}" ]
			then
				eval alias_or_function
				# now get rid of the filename extension.
				# if the extension can be either exe or EXE
				#	you may have check that basename
				#	does what you want.
				File="$(basename "${File}" .exe)"
				eval alias_or_function
			fi
		done
		popd > /dev/null
	done

"eval alias_or_function" may be one of the following.

eval alias "${File}"="pushd "${DIR}" > /dev/null ; cmd /c "${File}" ; popd > /dev/null"

	# if cmd /c is a problem, use /path_to_non-cygwin_info-zip/unzip
	eval alias "${File}"="pushd "${DIR}" > /dev/null ; /path_to_non-cygwin_info-zip/unzip "${File}" ; popd > /dev/null"
	eval alias "${File}"="pushd "${DIR}" > /dev/null ; /path_to_non-info-zip/unzip "${File}" ; popd > /dev/null"

	# The following assumes that there are no spaces in ${DIR} or ${File}.
	eval alias "${File}"="cygstart -d ${DIR} ${File}"

	# If there are spaces in ${DIR} or ${File}.  But I tend to mess up putting double quotes in double quotes in eval.
	eval alias "${File}"="cygstart -d \"${DIR}\" \"${File}\""

Constructions of functions instead of aliases is left as an exercise for the reader.

Note: None of the above has been tested. I rarely use eval.
I usually have to experiment to make eval work
See comments, above, regarding quoting.
So YMMV.

Something we have to check out. Maybe this is an option. I have to discuss this internally.
I really appreciate any feedback that is suggesting a workaround, and
I would like to thank everybody who is so lastingly to follow up
this, but what I do not understand is that after we found that only
replacing the dll cause the prob and fix it again when reverted, why
isn't that enough to troubleshoot the dll now? Also because it does
not work with the 1.7 version.

You forget a possibility: The ability to load sfx-file.exe may have been a bug that you used unknowingly as a feature. When the bug was fixed, something outside of cygwin1.dll that was always "wrong" finally became visible.

If, indeed, your problem occurred because a cygwin1.dll bug was fixed that was masking a bug on your system, the developers are going to be even less enthusiastic about working on this.
Yes, that is true, but hopefully not the reason, cause that means we will never be able to update to the latest under the current circumstances.
So I keep my fingers crossed, that we will be able to fix it somehow :-)
____

Going back to the error message you originally reported http://sources.redhat.com/ml/cygwin/2008-09/msg00440.html

bash: ./*selfextracting_zipfile*.exe: Cannot allocate memory

- I, in my ignorance and naïveté, am still sort of surprised that "Changing Cygwin's Maximum Memory" didn't work. Are you sure that you did the registry key correctly? Does company policy let the change "stick"? (Around here, only administrators can use regedit and the only part of the registry that we can access seems to be HKCU. I periodically thank the Flying Spaghetti Monster for regtool.)
That was done as part of troubleshooting using the regtool mentioned in "Changing Cygwin's Maximum Memory"
The result was checked manually by using regedit navigating to the key and rebooting the system after the key was verified.
- Might a bigger swap file help?
No. Unfortunately not.
- Might your antivirus selectively* block loading such a humongous executable. (* selectively = when launching from cygwin but not cmd.)
Good point. I tested it with having Norton AV Autoprotect disabled. Guess what. the problem remains the same :-)
Speaking of "Changing Cygwin's Maximum Memory" <http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html> ...

Curiously (since I've never played with heap_chunk_in_mb), when I tried max_memory.exe I got the exact same result as you did.
	5fffe000 bytes (1536.0Mb)
So I recompiled it with the much-reviled-and-soon-to-be-eliminated -mno-cygwin flag.  Interestingly, the result was different.
	77ffe000 bytes (1920.0Mb)
I confirmed that the first executable is linked to cygwin1.dll and that the second is not.
	> cygcheck /usr/local/bin/max_memory.exe
	c:\cygwin\usr\local\bin\max_memory.exe
	  c:\cygwin\bin\cygwin1.dll
	    C:\WINDOWS\system32\ADVAPI32.DLL
	      C:\WINDOWS\system32\ntdll.dll
	      C:\WINDOWS\system32\KERNEL32.dll
	      C:\WINDOWS\system32\RPCRT4.dll
	        C:\WINDOWS\system32\Secur32.dll
	> cygcheck ./max_memory.exe
	.\max_memory.exe
	  C:\WINDOWS\system32\msvcrt.dll
	    C:\WINDOWS\system32\KERNEL32.dll
	      C:\WINDOWS\system32\ntdll.dll

So between both of us getting 1536.0Mb in cygwin and 1536.0Mb being less than -mno-cygwin gave, I wonder whether 1536.0Mb might possibly have been compiled into the cygwin1.dll. So I'd suggest that you download and browse the current source browse looking for a likely culprit. (Disclaimer: My "programming" abilities are limited to bash, gawk, and below, so I don't know what I'm talking about.)
Me too ;-)
And this also contributed to my wondering whether you did "Changing Cygwin's Maximum Memory" correctly.

Of course, if the 1536.0Mb limit was set as a constant, a developer should have already remembered it.  So I'm almost certainly wasting your time.  Note the word "almost".  (Also note the above disclaimer.)  Also note the word "almost" does not remove the word "certainly".  But you're desperate, aren't you?  ;-)
____

Other data that you might obtain:

- Take sfx-file.exe to a machine (your home machine?) that has cygwin but not the restrictions of "company policy". See if bash can load it. Maybe the company machines have other restrictions that only became visible after cygwin1.dll upgraded.
We tried that during testing. The latest (and the old) cygwin was installed on another system (my laptop) but with the same test result.
Also no different if you use win2000 or xp as the base OS. This issue appears on all systems.
- Can you run sfx-file.exe from other shells than bash, e.g., ash.exe, where the shell does not have bash as a parent? (E.g., the shell was started from the Start Menu's "run" box.)
ash also gives you an error message about memory (cant remember the correct output)
- If you've been doing this from inside X, does running from a non-X console work?
We are going to try this using non-X console. 
  - Does playing with consoles change anything?  (I'd guess not, but if everything that's likely to work doesn't its time to try the unlikely.)
	- starting bash with cmd as the parent, e.g., from cygwin.bat or as cmd /c bash.
	- starting bash from the Start Menu's "run" box.
	- cygwin's rxvt
	- cygputty
	- etc.

Good luck.

Thanks for your your efforts.
Regards Dirk
- Barry

--
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]