Mail Archives: cygwin-developers/2001/09/07/13:10:03
On Fri, Sep 07, 2001 at 12:19:43PM -0400, Christopher Faylor wrote:
> On Thu, Sep 06, 2001 at 09:05:35PM -0400, Christopher Faylor wrote:
> >On Thu, Sep 06, 2001 at 03:45:34PM -0400, Christopher Faylor wrote:
> >>On Thu, Sep 06, 2001 at 11:38:43AM -0400, Christopher Faylor wrote:
> >>>While attempting to cut down on the size of the 1.3.3 DLL, I uncovered a few
> >>>problems with cygheap. I couldn't track them down before I went to bed.
> >>>
> >>>The symptom is that applications die in cfree. The problem manifests quickly
> >>>in a process which execs a process which execs a process.
> >>>
> >>>I haven't seen the problem that Egor reported with free but it probably is not
> >>>related to the cygheap problem. It probably is somehow related to the new
> >>>code in sigproc which allocates the zombie array dynamically.
> >>
> >>The fix for this turned out to be very trivial. It was just the requirement
> >>for a null pointer check. Doh.
> >>
> >>I've checked the fix in.
> >>
> >>I'd again appreciate feedback on whether this fixes the problem or not. It
> >>seems to for me.
> >>
> >>This is not a fix for the rsync problem that was recently reported.
> >
> >Did this patch work? It seems to for me.
>
> The last we heard, another similar patch to this one didn't work for Corinna.
>
> I'd like to get confirmation that this one works ok.
Sorry, it doesn't work for me. I tried the plain version from
CVS and the same including the cygheap.cc patch which you've
send here. My testcase is a `make' in a Cygwin build tree.
This testcase crashes now on a regular basis in /bin/sh. I'm
getting the following backtrace in gdb with and without
your yesterday's patch in cygheap.cc:
#0 _free_r (reent_ptr=0x610ab020, mem=0xa015bc8)
at ../../../../../src/newlib/libc/stdlib/mallocr.c:2635
#1 0x61036072 in export_free (p=0xa015bc8)
at ../../../../src/winsup/cygwin/malloc.cc:163
#2 0x61035ef6 in free (p=0xa015bc8)
at ../../../../src/winsup/cygwin/malloc.cc:118
#3 0x61065125 in sigproc_fixup_after_fork ()
at ../../../../src/winsup/cygwin/sigproc.cc:1312
#4 0x6102df92 in fork_child (hParent=@0x22f924, first_dll=@0x22f928,
load_dlls=@0x22f92c) at ../../../../src/winsup/cygwin/fork.cc:282
#5 0x6102effb in fork () at ../../../../src/winsup/cygwin/fork.cc:661
#6 0x00406e84 in _size_of_stack_reserve__ ()
#7 0x004022b3 in _size_of_stack_reserve__ ()
[...]
#17 0x00407cb3 in _size_of_stack_reserve__ ()
#18 0x610046db in dll_crt0_1 () at ../../../../src/winsup/cygwin/dcrt0.cc:865
#19 0x6100495d in _dll_crt0 () at ../../../../src/winsup/cygwin/dcrt0.cc:936
#20 0x610049a9 in dll_crt0 (uptr=0x0)
at ../../../../src/winsup/cygwin/dcrt0.cc:948
#21 0x00410b2f in _size_of_stack_reserve__ ()
#22 0x0040103d in _size_of_stack_reserve__ ()
#23 0x77e992a6 in _cygheap_start ()
Once I had a crash in malloc_r instead of free_r but I couldn't
reproduce it now while I'm writing this mail.
The reason still seems to be a wrong zombie pointer in a forked
child. It's not related to a fork/vfork difference since it's
the same when I use bash as /bin/sh.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -