Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <8F23E55D511AD5119A6800D0B76FDDE1CA2EF3@cpex3.channelpoint.com> From: Troy Noble To: "'cygwin AT cygwin DOT com'" Subject: RE: broken CTRL-BREAK handling Date: Tue, 17 Jul 2001 14:50:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id QAA21323 > Hmm. I'll have to investigate this next week. I can't easily retrieve > the B20 sources right now. I have the sources for b20.1 at my disposal too. I will go look as well. Just for grins. > I think I recall that back in B20.1 days, people routinely > provided details rather than make vague assertions, too. Hmm... I have done that. I know you get a lot of mail traffic, so I'll refresh your memory. Here's the things I've reported thusfar: 1. CTRL-C handling is broken with CYGWIN=notty in an emacs buffer. I submitted patches for this already, in 5 different forms, each of which fixed the problem in a different way. I never did hit on the right combination that you were looking for, and my patches were rejected. I gave up and patched my own copy from the sources, and it's been working nicely for me for 2 months now. All the other emacs users are still stuck though I suspect. 2. CTRL-BREAK handling is broken, which I just reported and mentioned a fix. I patched my own copy of the DLL with this as well, and it now behaves just like it did back in b20.1. The third, which I've not reported yet because I don't have enough details gathered yet is: 3. Access Violation. There appears to be a race condition in the cygwin heap initialization after a spawn. It's almost like the "cygheap_protect->acquire ();" isn't doing the right thing. But I've not nailed it down yet. Here's the backtrace: (gdb) p buckets $10 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x1a021ac4 "\005", 0x6
, 0x1a028bfc "$\211\002\032'\213\002\032i", 0x1a02825c "\204|\002\032O\201\002\032i", 0x1a0289ac "?\205\002\032$\211\002\032i", 0x1a02726c "ñd\002\032Dr\002\032i", 0x1a0212bc "\013", 0x0 }(gdb) p rvc $7 = (_cmalloc_entry *) 0x6 (gdb) bt #0 _cmalloc (size=6) at /work/build/src/winsup/cygwin/cygheap.cc:102 #1 0x61001c48 in cmalloc (x=HEAP_1_ARGV, n=24) at /work/build/src/winsup/cygwin/cygheap.cc:223 #2 0x61051f7b in spawn_guts (hToken=0x0, prog_arg=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum", argv=0xa013740, envp=0xa010008, mode=3) at /work/build/src/winsup/cygwin/spawn.cc:230 #3 0x61053bbe in _spawnve (hToken=0x0, mode=3, path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum", argv=0xa013740, envp=0xa010008) at /work/build/src/winsup/cygwin/spawn.cc:881 #4 0x61010ab1 in _execve ( path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum", argv=0xa013740, envp=0xa010008) at /work/build/src/winsup/cygwin/exec.cc:35 #5 0x61010b2e in execv ( path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum", argv=0xa013740) at /work/build/src/winsup/cygwin/exec.cc:62 #6 0x6107afb0 in execvp (file=0x1a023714 "md5sum", argv=0xa013740) at /work/build/src/newlib/libc/posix/execvp.c:81 #7 0x4056af in _size_of_heap_reserve__ () #8 0x4044eb in _size_of_heap_reserve__ () #9 0x404124 in _size_of_heap_reserve__ () #10 0x40151c in _size_of_heap_reserve__ () ---Type to continue, or q to quit--- #11 0x401862 in _size_of_heap_reserve__ () #12 0x401673 in _size_of_heap_reserve__ () #13 0x401432 in _size_of_heap_reserve__ () #14 0x40134c in _size_of_heap_reserve__ () #15 0x61003fb4 in dll_crt0_1 () at /work/build/src/winsup/cygwin/dcrt0.cc:862 #16 0x610042a5 in _dll_crt0 () at /work/build/src/winsup/cygwin/dcrt0.cc:928 #17 0x610042f1 in dll_crt0 (uptr=0x40f1d0) at /work/build/src/winsup/cygwin/dcrt0.cc:940 #18 0x40d28a in _size_of_heap_reserve__ () #19 0x401038 in _size_of_heap_reserve__ () #20 0x77f1b9ea in ?? () 98 cygheap_protect->acquire (); 99 if (buckets[b]) 100 { 101 rvc = (_cmalloc_entry *) buckets[b]; 102 buckets[b] = rvc->ptr; 103 rvc->b = b; 104 } 105 else 106 { 107 size = sz + sizeof (_cmalloc_entry); 108 rvc = (_cmalloc_entry *) _csbrk (size); 109 110 rvc->b = b; 111 rvc->prev = cygheap->chain; 112 cygheap->chain = rvc; 113 } 114 cygheap_protect->release (); It is particularly sensitive when running with cygwin and programs like winamp where frequent process switching is happening, or under heavy CPU load. It is somewhat hard to reproduce, because you have to load the machine down and then start/stop a whole bunch of cygwin processes (like a make on a big source code tree which churns through repeated invocations os make.exe, sh.exe, etc. at a fairly good clip). And you can't reproduce it when strace is running. The I/O is enough to slow things down to the point that it doesn't fail. Once I get more details, I'll report this one too ;-> If I was just one of the yay-sayers saying "it's broke" or "me too", I suppose I'd say I deserved that response. The fact is that I have taken the initiative to attempt to climb in and understand the code and pitch in by running debugger sessions, finding work arounds, submitting patches, etc. From reading the web site, I think I've tried to follow the recommended approach for getting things fixed... ask for help, when we tell you to go away, go try to fix it yourself, and send the patches to the list. At least my problems are getting fixed, but I'm having to do it all myself. It's just unfortunate nobody else has gotten to take advantage of any fixes I've submitted yet. Troy -----Original Message----- From: Christopher Faylor [mailto:cgf AT redhat DOT com] Sent: Tuesday, July 17, 2001 2:15 PM To: cygwin AT cygwin DOT com Subject: Re: broken CTRL-BREAK handling On Tue, Jul 17, 2001 at 02:06:21PM -0600, Troy Noble wrote: >b20.1 handled it differently. If I press the [X] or >CTRL-BREAK in a b20.1 window, JDK dutifully dumps the >stack trace. Hmm. I'll have to investigate this next week. I can't easily retrieve the B20 sources right now. >Just one of several things that worked in b20.1 that are >broken in cygwin 1.x. I think I recall that back in B20.1 days, people routinely provided details rather than make vague assertions, too. Ah, those were the days. Everything was so very much better. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/