Re: lynx-dev Lynx 2.8.3.dev8: CPU problems connecting to a site

[Vlad Harchev]

On Sun, 29 Aug 1999, Klaus Weide wrote:

> On Sun, 29 Aug 1999, Frederic L . W . Meunier wrote:
> > On Sun, Aug 29, 1999 at 11:22:40PM +0500, Vlad Harchev wrote:
> > > On Sun, 29 Aug 1999, Frederic L . W . Meunier wrote:
> > 
> > Yes, it's constantly increasing,  but only the load. The memory consumption
> > stop at 9.15% (I have 128mb of RAM+128mb of swap). When I start Lynx it
> > uses like ~1.5%.
> 
> If you waited long enough, it should eventually eat all your swap space.
> That might get fun...

 Yes, it's fun! Read more...

> (Use ulimit to prevent catastrophes like that.)
> 
> > >  The following may help: 
> > > attach to the process, make bt, 'detach', wait for some time (~30 secs), 
> > > and
>                                      ^^^^^^
> > > then attach and make bt. Do the traces differ? If not, then seems that 
> > > this is
> > > a bug in malloc.
> 
> That should have been 'q' (and then answer the prompt appropriately).
> It seems the process didn't run at all between detaching and attaching
> (the addresses were all the same).

 I checked - no 'q' necessary. After detaching, process is unfrozen.
          IMO THIS IS A BUG IN MALLOC!
 Look at the #1 and #2 items - these lines are indentical - this means that
 they are the same - so IMO malloc hangs!
 May be this should be reported to glibc developers?

 One more proof: if Frederic waited more than 1 second (IMO he did), the
second stack trace would have more than 100,000 entries - IMO stack should
have exhausted if no malloc hang was occured!

 And I noticed problems with mallocs from differenet vendors when size is
smaller than 8 - IMO we witness the same problem.

 This should be inspected more carefully...
 
> But I think we know what the problem is, so more tracing should not be
> necessary for _this_ problem.
> 
>    Klaus
> 
> 
> 

 Best regards,
  -Vlad