http://permalink.gmane.org/gmane.os.cygwin hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.cygwin/133904 <pre> Works for me now. I also ran the libapr1 tests in case this touched any of the various mutex stuff and they all passed, too. </pre> David Rothenberger 2012-05-23T20:33:49 http://permalink.gmane.org/gmane.os.cygwin/133903 <pre>The isomaster package is now part of the Cygwin distribution. http://www.littlesvr.ca/isomaster/ Description from README: ISO Master is an open-source, easy to use, graphical CD image editor for Linux and BSD. Basically you can use this program to extract files from an ISO, add files to an ISO, and create bootable ISOs - all in a graphical user interface. It can open ISO, NRG, and some MDF files but can only save as ISO. ISO Master is based on bkisofs - a library for reading, modifying and writing ISO images. Christian Franke </pre> Christian Franke 2012-05-23T20:14:49 http://permalink.gmane.org/gmane.os.cygwin/133902 <pre> I think I found the problem. I've uploaded a new snapshot. Please give it a try. Thanks, Corinna </pre> Corinna Vinschen 2012-05-23T20:10:41 http://permalink.gmane.org/gmane.os.cygwin/133901 <pre> /usr/share/doc/rebase/README </pre> marco atzeri 2012-05-23T19:12:59 http://permalink.gmane.org/gmane.os.cygwin/133900 <pre> http://cygwin.wikia.com/wiki/Rebaseall </pre> Bill Ross 2012-05-23T18:47:01 http://permalink.gmane.org/gmane.os.cygwin/133899 <pre>EM - what does "rebase" mean? I tried doing a man rebase but didn't get a man page. On Wed, May 23, 2012 at 1:43 PM, Bill Ross &lt;photoriot&lt; at &gt;yahoo.com&gt; wrote: </pre> Larry W. Virden 2012-05-23T18:26:28 http://permalink.gmane.org/gmane.os.cygwin/133898 <pre> Big fat sigh. This all worked fine while debugging. Just that the snapshot is built with optimization and my debugging version is not. Ok, back to the drawing board. Corinna </pre> Corinna Vinschen 2012-05-23T17:54:03 http://permalink.gmane.org/gmane.os.cygwin/133897 <pre>often associated with a need to rebase ... EM Solved, thanks! Bill </pre> Bill Ross 2012-05-23T17:43:51 http://permalink.gmane.org/gmane.os.cygwin/133896 <pre> I tried installing this snapshot and found most things hung. Specifically, I ran ash in a Windows cmd window, then tried /bin/echo foo I tried mintty too but bash hangs before I get a prompt. "echo foo" worked fine, though. </pre> David Rothenberger 2012-05-23T17:42:19 http://permalink.gmane.org/gmane.os.cygwin/133895 <pre>The message: fork: Resource temporarily unavailable is often associated with a need to rebase ... EM </pre> Eliot Moss 2012-05-23T17:24:37 http://permalink.gmane.org/gmane.os.cygwin/133894 <pre> Ok, for the time being I checked in my workaround. Please test the today's developer snapshot. THanks, Corinna </pre> Corinna Vinschen 2012-05-23T17:18:34 http://permalink.gmane.org/gmane.os.cygwin/133893 <pre>on Windows 7 there are a lot of related to cygwin ssh to another bash and ssh still manager.   I have 64-bit Win7 with cygwin, and after a while this sort of thing runs out of resources (errno 11) until I reboot (and then starts up after a few ok runs, as just now):   $ find . -name "*.java" | while read i ; do 375832787 [main] -bash 6020 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741819, errno 11 -bash: fork: retry: Resource temporarily unavailable -bash: fork: Resource temporarily unavailable   And I think I have noticed lots of bash processes hanging around, though not in this instance.   $ uname -a CYGWIN_NT-6.1-WOW64 mybox 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin   Bill </pre> Bill Ross 2012-05-23T16:26:50 http://permalink.gmane.org/gmane.os.cygwin/133892 <pre> Half of the solution is now checked in to CVS. The other half is a bad hack to workaround a shortcoming in newlib's stdio functions. I'd rather have a solution in newlib. see my request on the newlib ML: http://cygwin.com/ml/newlib/2012/msg00188.html Corinna </pre> Corinna Vinschen 2012-05-23T16:06:25 http://permalink.gmane.org/gmane.os.cygwin/133891 <pre> That would be most helpful. I don't grok this crash. It's one of the "this should never possibly happen" kind... Corinna </pre> Corinna Vinschen 2012-05-23T16:02:35 http://permalink.gmane.org/gmane.os.cygwin/133890 <pre> After the longjmp, emacs has finished processing the C-g and goes back into its idle loop, in which it repeatedly calls select. gdb doesn't normally show the threads created by select. If it did, it would always create voluminous output. Can you infer anything from the fact that it shows this one? Yes, that's correct. (I'm using the 20120516 snapshot.) Based on the emacs code, I think that's right. But maybe I need to download the source for the snapshot I'm using (or build cygwin1.dll myself) so that I can step through the first call to select after the longjmp and see exactly where the crash is happening. Ken </pre> Ken Brown 2012-05-23T15:56:32 http://permalink.gmane.org/gmane.os.cygwin/133889 <pre> Looking into your strace I'm wondering if you really mean hanging in the sense of "hanging indefinitely until killed", or if you mean it hangs for about half a second. Since that's what the strace shows. For some of the information about a process under /proc, the requesting process has to open a pipe and then, by using a special signal, informs that process that it requests information which in turn is send over the pipe back to the requester. The timeout for each of the read operations on the pipe is restricted to 500ms to avoid indefinite hangs. Unfortunately I can't reproduce this effect, neither on XP nor on W7. Hmm, puzzeling. I'm wondering though, if this may be a result of using message type pipes. Nothing else comes to mind which has changed in this piece of code lately. For testing you could set the environment variable CYGWIN to "pipe_byte" and try again. Corinna </pre> Corinna Vinschen 2012-05-23T15:53:27 http://permalink.gmane.org/gmane.os.cygwin/133888 <pre> I don't know what this has to do with the longjmp, but the thread which gets crated right after pressing Ctrl-G is due to a select or poll call. The descriptor is a pipe, fifo, or pty. The problem with stackdumps is that the addresses only make sense for a single version of the Cygwin DLL. If that's a self-built version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print? If it's 1.7.15, please install the cygwin-debug package and call the same addr2line. I assume the address corresponds to select.cc, line 625, but I'm quite busy with the pthread_cancel stuff, so I didn't look deeper into this problem. ^^^^^^^ Yes, that's exactly the created thread. Do you happen to know what kind of descriptor has been given to select at this point? Is that a pty master side perhaps? Corinna </pre> Corinna Vinschen 2012-05-23T14:15:38 http://permalink.gmane.org/gmane.os.cygwin/133887 <pre> I use cygwin all the time under Windows 7 64-bit and that does not happen to me. Thus it would seem to be particular to your setup, or maybe to the specific version (I've not updated for a few weeks) ... Regards -- Eliot Moss </pre> Eliot Moss 2012-05-23T13:36:32 http://permalink.gmane.org/gmane.os.cygwin/133886 <pre>We are trying to make use of cygwin in several ways on Windows 7 64-bit desktops. One of the first things we have noticed is that there are a lot of processes sitting on the desktop that appear to be related to cygwin that we didn't see previously on 32 bit XP. For instance, if we open a bash console, perform an ssh to another machine, do some work, then close the window, the bash and ssh still seem to be listed when we look at the windows 7 task manager. So, not wanting to duplicate the fine efforts of those on this list from the past few years. I googed for cygwin issues windows 7 64 bit, but the 301,000 results were a bit overwhelming to contemplate reading through to find unique issues that need to be addressed, and of course may or may not reflect the state of the current distribution. So before we start doing weeks of reading of threads, etc. I thought I would ask whether someone has gathered this information together. Thank you </pre> Larry W. Virden 2012-05-23T13:24:37 http://permalink.gmane.org/gmane.os.cygwin/133885 <pre> I've gotten some more information from gdb. The crash occurs after a call to _longjmp, and gdb shows a new thread created right at that point. This doesn't happen when I run emacs under X instead of in mintty. Here's an excerpt from the gdb session, with the strange thread marked: $ gdb -p 6492 [...] Attaching to process 6048 [New Thread 6048.0x668] [New Thread 6048.0x1a5c] [New Thread 6048.0x2630] [New Thread 6048.0x1d14] Reading symbols from /home/kbrown/src/emacs/test-nox/src/emacs.exe...done. [...] (gdb) b unwind_to_catch Breakpoint 3 at 0x52aca2: file eval.c, line 1234. (gdb) c Continuing. [Switching to Thread 6048.0x668] [...] Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12985830) at eval.c:1234 1234 catch-&gt;val = value; (gdb) n [...] 1272 _longjmp (catch-&gt;jmp, 1); (gdb) [New Thread 6048.0x1e04] &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Program received signal SIGSEGV, Segmentation fault. 0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll (gdb) thr</pre> Ken Brown 2012-05-23T12:00:38 http://permalink.gmane.org/gmane.os.cygwin/133884 <pre> opened a bug on sourceware bugzilla. I noticed that objdump documentation is more complete: I i The symbol is an indirect reference to another symbol (I), a function to be evaluated during reloc processing (i) or a normal symbol (a space). Thanks Marco </pre> marco atzeri 2012-05-23T09:45:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.cygwin