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

[Vlad Harchev]

On Mon, 30 Aug 1999, Klaus Weide wrote:

> On Mon, 30 Aug 1999, Vlad Harchev wrote:
> 
> >  I checked - no 'q' necessary. After detaching, process is unfrozen.
> 
> Ok, it seems I was wrong about 'detach'.  The process should have
> continued running.
> 
> >           IMO THIS IS A BUG IN MALLOC!
> 
> Maybe it does not really 'hang', but is just very very slow at that point.
> malloc might have returned eventually.  Try to step with 's' (and make
> some coffee while waiting for malloc to return).

 Stepping without sources is possible only on instructions.

 Fredereic, here is another advice - run ltrace. In your case, issue the
following:

 ltrace -p PID_OF_LYNX -e malloc -tt

this will print the invokations of malloc's only, with timestamp
with micorseconds. If ltrace didn't display anything (ie no calls of malloc) - 
this is definitely a bug. 
 Otherwise the screen will fill up very quickly with something like

17:35:52.433600 malloc(42)                        = 0x08227a40
17:35:52.440754 malloc(48)                        = 0x08227a70
17:35:52.448285 malloc(26)                        = 0x08227458
17:35:52.455430 malloc(21)                        = 0x08218238
17:35:52.462900 malloc(26)                        = 0x08227aa8
17:35:52.470202 malloc(23)                        = 0x08227ac8


 Frederic, do you have that problem when opening that page as main page (ie
      lynx http://foobar.com
 ) or only when 'g'oing to it?
 Does waiting for say 1 minute solve the problem (ie slow malloc)?

>[...] 
> >  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!
> 
> I don't know where you get that number.

 I meant that if the malloc didn't hang, the recursive invokation of the
function will fill up entire available stack very fast - in a pair of
seconds. That's why that number.

> > 
> >  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...
> 
> If someone want do nail down this possible libc problem, lynx should not
> be necessary.  A much smaller test program that call malloc(7) repeatedly
> should be enough.  (Possibly also from a recursive function, if there is
> some interaction between stack and heap memory growth.)

 I afraid things are more complicated...
 
> 
>    Klaus
> 

 Best regards,
  -Vlad