broken CTRL-BREAK handling

Troy Noble troy.noble@channelpoint.com
Tue Jul 17 13:50:00 GMT 2001 

> 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 <Address 0x6 out of bounds>, 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 <repeats 20 times>}(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 <return> to continue, or q <return> 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@redhat.com ]
Sent: Tuesday, July 17, 2001 2:15 PM
To: cygwin@cygwin.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/

More information about the Cygwin mailing list