A walking "bug" on Cygwin home page
Have you noticed the walking "bug" appeared today on the Cygwin Home Page (http://www.cygwin.com). I initially thought that it was a real insect inside my PC monitor, but then I realized it was a "graphical" bug walking on the same path, an horizontal "8". I wonder if it doesn't hide some new malaware... Ciao, Angelo. walking_bug.tar.bz2 Description: Binary data -- 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
Re: A walking "bug" on Cygwin home page
On Sat, Aug 17, 2013 at 01:13:14PM +0200, Angelo Graziosi wrote: >Have you noticed the walking "bug" appeared today on the Cygwin Home >Page (http://www.cygwin.com). > >I initially thought that it was a real insect inside my PC monitor, but >then I realized it was a "graphical" bug walking on the same path, an >horizontal "8". > >I wonder if it doesn't hide some new malaware... It's a well known fact that all software (and web sites) have bugs. cgf -- 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
Re: binutils feature request: ld --disable-large-address-aware [PATCH]
Christian Franke wrote:
A few programs are not compatible with --large-address-aware which is
enabled by default in current x86 ld. For example cdrkit, dvd+rw-tools
and smartmontools use IOCTL_SCSI_PASS_THROUGH_DIRECT which apparently
requires user buffers below 2GiB.
Using "LDFLAGS=-Wl,--disable-large-address-aware" would be much easier
than adding an extra Cygwin specific "peflags --bigaddr=false *.exe"
post-build step.
(http://cygwin.com/ml/cygwin/2012-04/msg00342.html :-)
With the attached patch, "gcc -Wl,--disable-large-address-aware ..."
works as expected. Documentation update is missing.
It would probably make sense to add a --enable-large-address-aware
option as a synonym for --large-address-aware to keep enable/disable
options consistent.
There is a similar issue with --tsaware. It is enabled by default in
spec file but cannot be disabled in gcc command line. I don't know
whether there is a need for --disable-tsaware.
Christian
diff -ru binutils-2.23.52-5/origsrc/src/ld/emultempl/pe.em binutils-2.23.52-5/src/src/ld/emultempl/pe.em
--- binutils-2.23.52-5/origsrc/src/ld/emultempl/pe.em 2013-04-29 10:22:16.0 +0200
+++ binutils-2.23.52-5/src/src/ld/emultempl/pe.em 2013-08-17 17:56:52.791228500 +0200
@@ -242,8 +242,10 @@
(OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC + 1)
#define OPTION_LARGE_ADDRESS_AWARE \
(OPTION_DLL_DISABLE_RUNTIME_PSEUDO_RELOC + 1)
-#define OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V1 \
+#define OPTION_DISABLE_LARGE_ADDRESS_AWARE \
(OPTION_LARGE_ADDRESS_AWARE + 1)
+#define OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V1 \
+ (OPTION_DISABLE_LARGE_ADDRESS_AWARE + 1)
#define OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V2 \
(OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V1 + 1)
#define OPTION_EXCLUDE_MODULES_FOR_IMPLIB \
@@ -333,6 +335,7 @@
{"enable-runtime-pseudo-reloc-v2", no_argument, NULL, OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V2},
#endif
{"large-address-aware", no_argument, NULL, OPTION_LARGE_ADDRESS_AWARE},
+{"disable-large-address-aware", no_argument, NULL, OPTION_DISABLE_LARGE_ADDRESS_AWARE},
{"enable-long-section-names", no_argument, NULL, OPTION_ENABLE_LONG_SECTION_NAMES},
{"disable-long-section-names", no_argument, NULL, OPTION_DISABLE_LONG_SECTION_NAMES},
{"dynamicbase",no_argument, NULL, OPTION_DYNAMIC_BASE},
@@ -472,6 +475,8 @@
#endif
fprintf (file, _(" --large-address-aware Executable supports virtual addresses\n\
greater than 2 gigabytes\n"));
+ fprintf (file, _(" --disable-large-address-aware Executable does not support virtual\n\
+ addresses greater than 2 gigabytes\n"));
fprintf (file, _(" --enable-long-section-namesUse long COFF section names even in\n\
executable image files\n"));
fprintf (file, _(" --disable-long-section-names Never use long COFF section names, even\n\
@@ -828,6 +833,9 @@
case OPTION_LARGE_ADDRESS_AWARE:
real_flags |= IMAGE_FILE_LARGE_ADDRESS_AWARE;
break;
+case OPTION_DISABLE_LARGE_ADDRESS_AWARE:
+ real_flags &= ~ IMAGE_FILE_LARGE_ADDRESS_AWARE;
+ break;
case OPTION_ENABLE_LONG_SECTION_NAMES:
pe_use_coff_long_section_names = 1;
break;
--
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
mt and tar fail on LTO-5 drives
Hello People, I have here two SAS connected LTO-5 drives: one IBM and one HP. Both drives work work fine, but sadly mt does not. The size reported by mt is a meager 35 GB, instead of the expected 1.5TB I have tried both an older 32 bit and the 'current' 64 bit cygwin: same result. Writing to tape works fine with tar, but the tape is quickly considered 'full'. Is there any hope of fixing this? LTO-6 is already out there. Thanks - Bartels # IBM ULT3580+HH5 SCSI $ mt -f /dev/nst0 status 3 drive type : 56 (STK 9840) tape capacity: 37108736 KB remaining: 37093376 KB current file :0 active partition :0 current block:0 cur logical block:0 General status bits on (410b8000): BOT ONLINE IM_REP_EN CLN HW_ECC HW_COMP min block size :1 max block size : 1048576 def block size :65536 cur block size :0 density code : 58 (unknown) Drive(r) Capabilities: -- fixed length blocks: yesvar length blocks : yes set block size : yesfixed partitioning : no select partitioning: no initiator partitioning : no get logical blockno: yeslogical block spacing : yes get absolute blockno : yesabsolute block spacing : yes logical block immediate: no absolute block immediate : no relative block spacing : yesbackward spacing : yes immediate rewind : yesfast EOM spacing : yes immediate spacing : no write marks immediate : yes filemark spacing : yeswrite filemarks: yes write long filemarks : no write short filemarks : no report setmarks: no setmark spacing: no write setmarks : no set report setmarks: no sequential filemarks : no sequential setmarks: no load and unload: yesun/load immediate : yes lock and unlock: yesun/lock immediate : no tape retension : no retension immediate: no erase on bop only : no erase immediately : yes long erase : yesshort erase: yes sw ejects media: no report write protection: yes report EOT warn size : no set EOT warn size : no data padding : no set data padding : no returns capacity : yesreturns remaining : yes hw error correction: no set hw error correction: no hw compression : yesset compression: yes set comp. on bop only : no report cleaning request: yes # HP Ultrium-5 $ mt -f /dev/nst0 status 3 drive type : 56 (STK 9840) tape capacity: 37351424 KB remaining: 37351424 KB current file :0 active partition :0 current block:0 cur logical block:0 General status bits on (410b): BOT ONLINE IM_REP_EN HW_ECC HW_COMP min block size :2 max block size :65536 def block size :65536 cur block size :0 density code : 58 (unknown) Drive(r) Capabilities: -- fixed length blocks: yesvar length blocks : yes set block size : yesfixed partitioning : yes select partitioning: yesinitiator partitioning : yes get logical blockno: yeslogical block spacing : yes get absolute blockno : yesabsolute block spacing : yes logical block immediate: yesabsolute block immediate : yes relative block spacing : yesbackward spacing : yes immediate rewind : yesfast EOM spacing : yes immediate spacing : no write marks immediate : yes filemark spacing : yeswrite filemarks: yes write long filemarks : no write short filemarks : no report setmarks: no setmark spacing: no write setmarks : no set report setmarks: no sequential filemarks : no sequential setmarks: no load and unload: yesun/load immediate : yes lock and unlock: yesun/lock immediate : no tape retension : no retension immediate: no erase on bop only : no erase immediately : yes long erase : yesshort erase: yes sw ejects media: yesreport write protection: yes report EOT warn size : no
emacs-nox hogs CPU if backgrounded during compile
Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 Ryan -- 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
Re: emacs-nox hogs CPU if backgrounded during compile
On Sat, Aug 17, 2013 at 02:41:32PM -0400, Ryan Johnson wrote: >The following STC causes emacs-nox to peg a CPU indefinitely. Emacs >remains responsive, but C-c C-k doesn't kill the compile; you have to >exit emacs to remove the "Compiling" status. Killing the buffer or >starting a new compile offers to kill the offending process, but doesn't. > >Attaching gdb shows an endless loop inside >kernelbase.dll!RaiseException, but provides no other clues that I could see. I don't know if this trick works on 64-bit Cygwin or not but you could try: set $rsp=$rbp bt And, if you get something sensible try it on every thread. cgf -- 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
Re: A walking "bug" on Cygwin home page
On 2013-08-17 12:05-0400 Christopher Faylor wrote: On Sat, Aug 17, 2013 at 01:13:14PM +0200, Angelo Graziosi wrote: Have you noticed the walking "bug" appeared today on the Cygwin Home Page (http://www.cygwin.com). I initially thought that it was a real insect inside my PC monitor, but then I realized it was a "graphical" bug walking on the same path, an horizontal "8". I wonder if it doesn't hide some new malaware... It's a well known fact that all software (and web sites) have bugs. Chris, I think you will want to take the original question concerning malware more seriously. If you actually take the time to look at cygwin.org it appears that either the developer of that website has an extremely weird sense of humor or else that website has been hacked into and defaced. Which? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
