[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vlad Harchev
Subject: Re: lynx-dev Lynx 2.8.3.dev8: CPU problems connecting to a site
Date: Mon, 30 Aug 1999 17:54:49 +0500 (SAMST)

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

 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
 ) 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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]