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

[Klaus Weide]

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...

> Pressing ^Z in
> "hanging" lynx produces segfault.

No reason why it should.

> 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.

   Klaus