Re: lynx-dev hanging malloc? (was: CPU problems connecting to a site)

[Vlad Harchev]

On Tue, 31 Aug 1999, Klaus Weide wrote:

> On Tue, 31 Aug 1999, Vlad Harchev wrote:
> 
> > On Tue, 31 Aug 1999, Klaus Weide wrote:
> > 
> > > On Tue, 31 Aug 1999, Vlad Harchev wrote:
> > > > On Mon, 30 Aug 1999, Frederic L . W . Meunier wrote:
> > > > > 23:19:56.201048 --- SIGSTOP (Stopped (signal)) ---
> > > > > 23:19:56.204604 --- SIGSEGV (Segmentation fault) ---
> > > > 
> > > >  I build dev8 with same config. I also have this problem. Lynx says 
> > > > 'HTTP/1.1 200 OK' and hangs.
> > > 
> > > With -trace -tlog you should get a better idea how far it got.
> > > 
> > > >  strace'ing this process produces the same results (SIGSTOP,SIGSEGV).
> > > >  lrtace'ing too (the same message as shown above).
> > > 
> > > I assume you had stopped the process with ^Z.  The 'SIGSTOP (Stopped
> > > (signal))' is then just a delayed effect of the ^Z.  You should
> > > attach to the process without stopping it first (from another window
> > > or console), or strace/ltrace it from the start.  Otherwise you are
> > > probably just debugging problems in the interrupt handler, not the
> > > original problem.
> > 
> >  I didn't press ^Z - seems this is a way [ls]trace work. 
> 
> Not for me, in a normal situation (not this "hanging" - I have not tried
> to reproduce it).  I have never seen strace (or ltrace) mention a signal
> like SIGSTOP when there wasn't any that had been sent.
> Maybe yours is broken, or doesn't fit the library or kernel version, or
> something changed in the way it is supposed to work, or...

 Do you know how [ls]trace work? I don't know. But IMO it's reasonable for
them to freeze process for a while to check what libraries are attached, etc
(these are my guesses).

> > Pressing ^Z in
> > "hanging" lynx produces segfault.
> 
> No reason why it should.

 Again, may be libc installs it (but why)? I have 2.2.5 kernel.

> > malloc(7)                                         = 0x0828f7a8
> > strcpy(0x0828f7a8, "s-1252")                      = 0x0828f7a8
> > strlen(0x08157085, 0xbfdb4e9c, 0x080e9654, 0xbfdb4e8c, 0x08157085) = 6
> > malloc(7)                                         = 0x0828f7b8
> > strcpy(0x0828f7b8, "s-1252")                      = 0x0828f7b8
> > strlen(0x08157085, 0xbfdb4e64, 0x080e9654, 0xbfdb4e54, 0x08157085) = 6
> > 
> >  Such trace lasts very long. One time it ended in ~1 minute in segfault 
> > within
> > malloc, other time - I stopped it after 5 minutes waiting.
> > 
> >  So, fortunately, there is no apparent bug in malloc, lynx must be fixed.
> 
> We already knew that lynx must be fixed.
> 
> You still haven't explained the weirdness under gdb, or disproven the
> bug you assumed earlier...  Not that you have to (it's hardly the right
> topic for lynx-dev), but I thought that's what you set out to do.
> We still don't know why the loop sometimes hangs indefinitely (or whether
> it does).  Or why sometimes there is a segfault and other times, after
> running for much longer, there isn't.

 What weirdness under gdb (or you call the bug "weirdness"?).  I don't feel 
the need to proof it - I saw it, I saw ltrace flooding my console with
'malloc(7)' for a minute - at least I'm convinced that this is a bug in 
lynx :) I set to study whether this is lynx or malloc bug - and so I have a
conclusion. As for other 'why', I don't feel the necessity to study in for
such non-standard situation (and I have no time too).
 As for segfaults - may be glibc ignores the SIGSEGV temporary while doing its
housekeeping, and attaching ltrace disturbs something, that's why SIGSEGVs..


>    Klaus
> 
> 
> 

 Best regards,
  -Vlad