W3C home > Mailing lists > Public > www-amaya@w3.org > January to March 2000

Bug report for release 2.4 on linux

From: Uwe F Mayer <mayer@tux.org>
Date: Mon, 7 Feb 2000 07:43:18 -0500 (EST)
To: www-amaya@w3.org
Message-ID: <Pine.LNX.4.10.10002070740420.1282-100002@gwyn.tux.org>
Various bugs of Amaya binary release 2.4 for Linux libc6.


When trying to load a page not on the local computer, I get an error:

>  The requested URL could not be retrieved
>  While trying to retrieve the URL:http://www.w3c.org/
>  The following error was encountered:
>  Connection Failed
>  The system returned:
>  (51) www.w3c.org
>  This means that:
>  The remote site or server may be down or non-existant.
>  Please try again soon.

Two things about this:
1. I'd like to know why Amaya doesn't find that location, even as
netscape does. This might not be a bug, but just incompetence on my
2. "non-existant" should be spelled "non-existent".


In the page Amaya/doc/amaya/Browsing.html the link to
"Configuring.html" should point to "Configure.html", because that's
what the file is actually called.


When displaying the page structure (Ctrl-v Ctrl-s) of
"http://www.tux.org/~mayer/linux/results2.1.html" the vertical lines
get messed up. Of course, as I cannot get Amaya to display pages from
the Internet, I have actually displayed a local copy with
"file:/...". I have attached two gif files to show the messed-up lines
(sorry for the size of this email, but that seemed to be the easiest
way). Deleting the entry in the table where the lines get messed up
makes no difference. In fact, taking the first entry, and repeating it
135 times works fine, but repeating it 136 times causes the error (this
is with caption and table heading deleted). My guess is, that the
length of the table causes some integer (?) overflow to occur.


When displaying any page, then displaying the page structure with
Ctrl-v Ctrl-s, then moving the mouse into the structure window,
hitting the page-down key once (or several times) and the up-arrow key
several times (but not just once), Amaya hangs. It ignores attempts to
close the window by the window manager, but reacts well to kill from
the shell. This behavior is repeatable. Here is an output of "top":

 11:58am  up  1:33,  4 users,  load average: 1.06, 0.60, 0.28
41 processes: 37 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 66.9% user, 33.0% system,  0.0% nice,  0.0% idle
Mem:   95944K av,  76252K used,  19692K free,  39872K shrd,   2444K buff
Swap:  40156K av,   4268K used,  35888K free                 42944K cached
  451 mayer     19   0  5552 5552  2884 R       0 64.4  5.7   0:22 amaya
  109 root      12   0 10300  10M  1688 S       0 34.1 10.7   2:52 X


System information:

Toshiba 4015CDT Laptop, 96MB RAM, Pentium II 266 MHz, running Linux.

This is a libc5 based system, however, the libc6 libraries are
installed also.

$ uname -a
Linux tosca 2.2.12 #1 Tue Nov 16 10:56:02 MET 1999 i686 unknown

$ X -probeonly
XFree86 Version / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: December 29 1998
[Rest of output cut]

Window manager: kde version 1.1.2

$  ldd /usr/local/Amaya/LINUX-ELF/bin/amaya 
        libXt.so.6 => /glibc2/X11R6/libXt.so.6 (0x40018000)
        libXp.so.6 => /glibc2/X11R6/libXp.so.6 (0x40061000)
        libSM.so.6 => /glibc2/X11R6/libSM.so.6 (0x40068000)
        libICE.so.6 => /glibc2/X11R6/libICE.so.6 (0x40072000)
        libXext.so.6 => /glibc2/X11R6/libXext.so.6 (0x40087000)
        libX11.so.6 => /glibc2/X11R6/libX11.so.6 (0x40092000)
        libdl.so.2 => /glibc2/libdl.so.2 (0x4012f000)
        libm.so.6 => /glibc2/libm.so.6 (0x40132000)
        libc.so.6 => /glibc2/libc.so.6 (0x4014f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The precise versions are:

	libdl.so.2 -> libdl-2.1.2.so
	libm.so.6 -> libm-2.1.2.so
	libc.so.6 -> libc-2.1.2.so
	ld-linux.so.2 -> ld-2.1.2.so


If desired, I am available for further testing.

Uwe F. Mayer

(IMAGE/GIF attachment: amaya1.gif)

(IMAGE/GIF attachment: amaya2.gif)

Received on Monday, 7 February 2000 07:57:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:30:30 UTC