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

[Klaus Weide]

On Mon, 30 Aug 1999, Vlad Harchev wrote:

> On Mon, 30 Aug 1999, Klaus Weide wrote:
> > 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.

???

   (gdb) s
   Single stepping until exit from function XXXXXXX,
   which has no line number information.
   (gdb) 

>  Fredereic, here is another advice - run ltrace. In your case, issue the
> following:
> 
>  ltrace -p PID_OF_LYNX -e malloc -tt

Or omit the `-e malloc', it would just hide whether something _else_ is
involved.

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

It depends on (1) the available stack (see `ulimit -a', I guess), (2) the
size of the stack frame pushed for each call (should not be much here -
few local variables, few arguments), (3) the slowness of each invocation
including the malloc(7).
I'm just not convinced your ballpark figures are right, maybe they are.

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

If you suspect it is a problem with malloc, one should be able to
reproduce it without lynx.

Well give it a try - maybe Frederic is more interested in getting a
running lynx than in debugging malloc. :)

   Klaus