Re: printf + pthreads+gdb+mintty = hang?
On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote: >Hi all, > >Running the attached STC inside gdb hangs (zero CPU util, have to kill >gdb from Task Manager, killing a.exe doesn't cut it). > >Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp > >I currently have the following package versions: >cygwin-1.7.18(0.263/5/3) 2013-04-19 >mintty-1.1.3-1 >gdb-7.6.50-1 >gcc-4.5.3-3 > >The problem seems to be related to threads calling fprintf inside gdb, >it runs fine from the command line, or with printf instead; both fprintf >and printf sometimes trigger "warning: SuspendThread failed. (winerr 6)" >(not sure if that matters). > >Known issue? Easy workaround? New bug? Known, long-standing issue. I put a workaround in the latest snapshot. 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: Installing VIM installs lots of other stuff
Greetings, Rick Patterson! > I am wondering why installing VIm installs so many other things: After > doing a default install of Cgwin, and then not finding VIm, I added VIM to > the install as well, but found it greatly increased my Cygwin install as > follows. > Dependencies listed to be installed: > crypt > libdb4.5 > libgbdm4 > libopenssl100 > libssp0 > perl > vim-common > xxl > After vi install: 439 M, 19349 files, 1941 folders > Before vi install: 275 M, 11602 files, 921 folders. > Change to get vim: 164 M, 7747 files, 1020 folders > %Change to get vim: +60%M, 66.7%files, +110% folders > So, my Cygwin gets 60% bigger just to install VIm? That's the price for the job well done. Jokes aside, do you really need it installed, if you're that worried about used space? There's tons of more useful editors for Windows. -- WBR, Andrey Repin (anrdae...@freemail.ru) 08.05.2013, <22:43> Sorry for my terrible english...
RE: Installing VIM installs lots of other stuff
Rick Patterson sent the following at Tuesday, May 07, 2013 10:09 PM >I am wondering why installing VIm installs so many other things: After >doing a default install of Cygwin, and then not finding VIm, I added VIM >to the install as well, but found it greatly increased my Cygwin install >as follows. > >Dependencies listed to be installed: > >crypt >libdb4.5 >libgbdm4 >libopenssl100 >libssp0 >perl >vim-common >xxl > >After vi install: 439 M, 19349 files, 1941 folders >Before vi install: 275 M, 11602 files, 921 folders > Change to get vim: 164 M, 7747 files, 1020 folders >%Change to get vim: +60%M, 66.7% files, +110% folders > >So, my Cygwin gets 60% bigger just to install VIm? Evidently. ;-> You need to look recursively at the '^requires: ' line of setup.ini. Vim: alternatives bash libiconv2 libintl8 libncursesw10 vim-common => vim-common: bash gawk perl xxd => perl: libssp0 libgcc1 libgdbm4 libdb4.5 crypt libbz2_1 perl_vendor _autorebase => perl_vendor: perl libssp0 libgcc1 libbz2_1 zlib0 libopenssl100 libncurses10 libreadline7 libncursesw10 libxml2 libiconv2 libexpat1 _autorebase Etc. Doing a complete analysis is left as an exercise for [ the reader | insomniacs | the masochistic ]. (That's why we let setup do it.) -- 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: Installing VIM installs lots of other stuff
On Wed, May 08, 2013 at 10:43:59PM +0400, Andrey Repin wrote: > Greetings, Rick Patterson! > There's tons of more useful editors for Windows. I heartily disagree with that statement. I'm not altogether convinced that Cygwin's Vim _needs_ to include the Perl interface, but then again, I usually have Perl installed anyway, so the extra HD space is comprised of stuff I need. If all one needs is an up-to-date build of Vim on a Windows box, I recommend looking at Cream - which is a dumbed-down Vim for noobs. The maintainer of this project also provides pre-packaged Windows builds of vanilla Vim that are more up-to-date than what can be had from www.vim.org. This will set you back a few tens of megabytes. http://cream.sourceforge.net/download.html -- Erik Falor http://unnovative.net Registered Linux User #445632 http://linuxcounter.net signature.asc Description: Digital signature
Re: printf + pthreads+gdb+mintty = hang?
On 08/05/2013 2:36 PM, Christopher Faylor wrote: On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote: Hi all, Running the attached STC inside gdb hangs (zero CPU util, have to kill gdb from Task Manager, killing a.exe doesn't cut it). Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp I currently have the following package versions: cygwin-1.7.18(0.263/5/3) 2013-04-19 mintty-1.1.3-1 gdb-7.6.50-1 gcc-4.5.3-3 The problem seems to be related to threads calling fprintf inside gdb, it runs fine from the command line, or with printf instead; both fprintf and printf sometimes trigger "warning: SuspendThread failed. (winerr 6)" (not sure if that matters). Known issue? Easy workaround? New bug? Known, long-standing issue. I put a workaround in the latest snapshot. Hmm. The STC still hangs about 25% of the time (down from ~100%), so things are improved but not fixed. Also, when I hit an assertion failure in my code, gdb successfully breaks in at my breakpoint on abort()---which used to hang---but then hangs as soon as I say "up 2" to see the actual source of the assertion failure. Unfortunately, I haven't been able to distill that one down to a reasonable STC: just arranging for a threaded toy app to call abort from multiple threads simultaneously doesn't seem to tickle the bug. 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: printf + pthreads+gdb+mintty = hang?
On Wed, May 08, 2013 at 04:47:46PM -0400, Ryan Johnson wrote: >On 08/05/2013 2:36 PM, Christopher Faylor wrote: >> On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote: >>> Hi all, >>> >>> Running the attached STC inside gdb hangs (zero CPU util, have to kill >>> gdb from Task Manager, killing a.exe doesn't cut it). >>> >>> Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp >>> >>> I currently have the following package versions: >>> cygwin-1.7.18(0.263/5/3) 2013-04-19 >>> mintty-1.1.3-1 >>> gdb-7.6.50-1 >>> gcc-4.5.3-3 >>> >>> The problem seems to be related to threads calling fprintf inside gdb, >>> it runs fine from the command line, or with printf instead; both fprintf >>> and printf sometimes trigger "warning: SuspendThread failed. (winerr 6)" >>> (not sure if that matters). >>> >>> Known issue? Easy workaround? New bug? >> Known, long-standing issue. I put a workaround in the latest snapshot. >Hmm. The STC still hangs about 25% of the time (down from ~100%), so >things are improved but not fixed. Ok. Then I'll go with "long standing issue" then. I've mentioned the problem with outputting lots os stuff to a pty here many times. 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
Junctions + "pwd -P" = only skin deep resolution
Junctions seem to respond differently to symlinks with commands like "pwd - P", getcwd(), or Perl's Cwd::getcwd. This is the last stop of a wild goose chase for a bug that I thought was centered around File::chdir. More details here: https://rt.cpan.org/Ticket/Display.html?id=84988 However, upon further inspection, the buck stop here. Here's the problem: Let's say I have a junction of /var/bin pointing to /usr/local/bin. It looks just like a symlink in a "ls -l" on /var lrwxrwxrwx 1 bbyrd Domain Users 14 May 8 20:23 bin -> /usr/local/bin So, starting from /var, here's what I get from "pwd -P": bbyrd@PC:/var$ pwd -P /var bbyrd@PC:/var$ cd bin bbyrd@PC:/var/bin$ pwd -P /usr/local/bin bbyrd@PC:/var/bin$ mkdir asd bbyrd@PC:/var/bin$ cd asd bbyrd@PC:/var/bin/asd$ pwd -P /var/bin/asd What the hell? Everything was going fine until you dive deeper into the directory, past the junction point. This should have read "/usr/local/bin/asd", since the "-P" means to find ALL of the symlinks and resolve them. This actually works exactly like that with symlinks, but symlinks suck outside of Cygwin. (Windows just gives me a stupid "System folder" in Explorer.) I'd like to have the best of both worlds: Junctions that play nice in both Cygwin and Windows. -- 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
parentheses in environment variable name
I have the problem described here - http://stackoverflow.com/questions/3735922/issue-with-oledbconnection-open-when-running-as-a-service Basically, I've installed cygwin plus openssh for the purpose of remotely logging into my windows machine from a linux machine over ssh to run an executable on the windows machine. My first problem was that my original executable I was trying to run (written in FoxPro) insisted on attempting to create a GUI window even though there was no desire to have visual feedback or user interaction, so attempts to call the executable through cygwin resulted in a hung command in the shell. It appears that FoxPro can't actually create an executable that doesn't also create a GUI window. After reading lots of comments about services interacting with the desktop and limitations that MSFT has put on recent versions of windows with respect to that feature, I abandoned this approach. I decided that perhaps I could accomplish the same thing I was trying to accomplish with the FoxPro executable with a simple C# console application that would not attempt to create a GUI (with an oledb connection to the FoxPro data I'm trying to access). The C# program works well outside of cygwin, but the cygwin+openssh shell (apparently) doesn't contain lots of the environment variables that .NET expects, so it blows up opening the oledb connection with some complaint about MDAC 2.6 or greater not being installed. It's been a while since I've had to install MDAC, so I knew that was a false error message. Google-fu (and the link I referenced above) suggests that perhaps some environment variables are missing, which of course is true. I understand the logic for not creating said environment variables, and although I tend to disagree with that logic, frankly I just don't know enough about it and I'm probably biased due to banging my head against this particular problem. Anyway, at least one suggestion I found was that my problem may be caused by the CommonProgramFiles(x86) environment variable needing to be set to 'C:\Program Files (x86)\Common Files'. So, can anyone suggest how to set an environment variable whose VARIABLE NAME (not just the VALUE) contains parentheses?!? The standard backslash escape character doesn't appear to work in this scenario. That, or perhaps I'm on the wrong track altogether. I'm open to any suggestions. Thanks! -BJ Quinn -- 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: parentheses in environment variable name
BJ Quinn wrote: > Anyway, at least one suggestion I found was that my problem may be caused by > the CommonProgramFiles(x86) environment variable needing to be set to > 'C:\Program Files (x86)\Common Files'. So, can anyone suggest how to set an > environment variable whose VARIABLE NAME (not just the VALUE) contains > parentheses?!? The standard backslash escape character doesn't appear to > work in this scenario. That, or perhaps I'm on the wrong track altogether. > I'm open to any suggestions. env - "CommonProgramFiles(x86)"="...whatever" /bin/bash.exe (or another program...) will set the name with parens in the environment... -- 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
