lynx-dev
[Top][All Lists]
Advanced

[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: Tue, 31 Aug 1999 14:50:31 +0500 (SAMST)

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. Pressing ^Z in
"hanging" lynx produces segfault.

 When I downloaded that file to my pc with wget, I started experimenting
again. Now, if the lynx is frozen right after it started with the downloaded
file as main page,  ltracing it (after attaching ltrace to it and unfreezing
it) doesn't produce segfault. Being ltraced, the virtual image size of the 
lynx grows approx 12 kb/sec. Fortunately, this is plain endless loop, since 
the screen is flooded with ('ltrace -p PID', no '-e'):

malloc(7)                                         = 0x0828f778
strcpy(0x0828f778, "s-1252")                      = 0x0828f778
strlen(0x08157085, 0xbfdb4f44, 0x080e9654, 0xbfdb4f34, 0x08157085) = 6
malloc(7)                                         = 0x0828f788
strcpy(0x0828f788, "s-1252")                      = 0x0828f788
strlen(0x08157085, 0xbfdb4f0c, 0x080e9654, 0xbfdb4efc, 0x08157085) = 6
malloc(7)                                         = 0x0828f798
strcpy(0x0828f798, "s-1252")                      = 0x0828f798
strlen(0x08157085, 0xbfdb4ed4, 0x080e9654, 0xbfdb4ec4, 0x08157085) = 6
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.

>        Klaus
> 

 Best regards,
  -Vlad


reply via email to

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