>Thanks for the replys so far, but none has hit the mark -- apparently
>because I did not characterize the problem well enough (it is often the
>case that you don't know what you say until you hear someone else respond
>to it). My appologies. I will provide a few more important clues, but
>first, the original:
>
>------------
>Anybody seen this yet? Book searches on dxbook displayed on a non-Alpha
>machine will hang. The process remains in sleep state. No response to the
>"stop search" button in the dxbook GUI interface; in fact the application
>is frozen seemingly indefinitely. I have to kill the dxbook process.
>
>This problem is not present if the telnet login is from, and displayed to,
>another Alpha.
>
>The Alpha's are 3000/600's running OSF/1 v3.2. The Online documentation
>database is served from nfs-mounted CDrom filesystems for some of the
>database, local disk space for other parts. The hung search problem has
>been demonstrated so far on remote sessions from IBM RS6000's running AIX
>3.2.5 and Apple Macintoshes running MacX v1.2.
>
>------------
>
>More complete characterization of problem:
>
>1. dxbook hangs when requesting a search of an entire book for a character
> string:
>
> a. the search procedure opens a "Matching Entries" window but then hangs.
>
> b. forgrounding the other dxbook windows, then moving them back leaves
> stepped-on window features not refreshed.
>
> c. dxbook process remains in sleep state with only 0.1 to 0.5%, of CPU.
>
> d. process will remain in this state on the order of hours, presumably
> indefinitely if user's patience would allow.
>
>2. Requisites to reproduce the problem:
> a. the dxbook command is issued from a remote login to the Alpha from
> a machine of differing make. ie., the local X server platform
> displaying the windows is not a DEC
> - no problem if the display is on Alphas, DECstations, etc.
> - known problem platforms: IBM AIX 3.2.5, Apple Macintosh with MacX
>v1.2,
> and, according to responses from the list so far, SunOS and Solaris,
> and possibly SGI Irix.
>
>* b. the Alpha OSF/1 version is 3.2.
> - OSF/1 v2.0 does not give this problem
>
> c. the type of search is a search of an entire book.
> eg. title searches for the same string in the same book don't hang
>
> d. it appears the size of the book matters - problem happens on the
> larger books.
> eg. problem searching the Fortran User Manual but not the Fortran
> Installation guide.
>
>* Of special note: this looks to be a v3.2 problem -- it wasn't there at
> v2.0 before the upgrade to v3.2.
> !! is this a known v3.2 bug? !!
>
Many replies saying they have seen the same or similar. Only one answer,
from Dr. Tom Blinn, that says, essentially, submit it as a problem report
but don't expect a fix.
I include Dr. Blinn's response below, but first, many thanks to all who
responded:
Jim Neeland <neeland_at_madmax.hrl.hac.com>
Jean-Marc Berenguier <Jean-Marc.Berenguier_at_univ-compiegne.fr>
elbracht.andre_at_ch.swissbank.com (Elbracht Andre)
Ilja Hallberg <hallberg_at_elixir.e.kth.se>
ian_at_stams.strath.ac.uk (Ian Thurlbeck)
----------------
I can't say off-hand whether this is a known problem, but it might be; I'd
have to search the problem report database. It would be interesting to see
if it happens on OpenVMS as well as Digital UNIX as the "client" (where the
Bookreader is running).
A few comments:
> More complete characterization of problem:
>
> 1. dxbook hangs when requesting a search of an entire book for a character
> string:
>
> a. the search procedure opens a "Matching Entries" window but then hangs.
>
> b. forgrounding the other dxbook windows, then moving them back leaves
> stepped-on window features not refreshed.
>
> c. dxbook process remains in sleep state with only 0.1 to 0.5%, of CPU.
>
> d. process will remain in this state on the order of hours, presumably
> indefinitely if user's patience would allow.
Point "b" isn't surprising -- moving a window to the front happens in the
window manager, refreshing a window after an expose requires the application
to do some work, and once it's hung, it isn't going to refresh a window.
> 2. Requisites to reproduce the problem:
> a. the dxbook command is issued from a remote login to the Alpha from
> a machine of differing make. ie., the local X server platform
> displaying the windows is not a DEC
> - no problem if the display is on Alphas, DECstations, etc.
> - known problem platforms: IBM AIX 3.2.5, Apple Macintosh with
>MacX v1.2,
> and, according to responses from the list so far, SunOS and Solaris,
> and possibly SGI Irix.
>
> * b. the Alpha OSF/1 version is 3.2.
> - OSF/1 v2.0 does not give this problem
>
> c. the type of search is a search of an entire book.
> eg. title searches for the same string in the same book don't hang
>
> d. it appears the size of the book matters - problem happens on the
> larger books.
> eg. problem searching the Fortran User Manual but not the Fortran
> Installation guide.
>
> * Of special note: this looks to be a v3.2 problem -- it wasn't there at
> v2.0 before the upgrade to v3.2.
> !! is this a known v3.2 bug? !!
It could easily be a new problem introduced between V2.0 and V3.2. There
is a "new" bookreader in V3.0 (or V3.2, I forget which) that adds things
like the book search capability and printing capability, and it's possible
that it has bugs in some of the new features that didn't get caught, and if
it only happens when you display to a "foreign" system, it's quite a bit
more likely it wouldn't get caught -- few internal field test sites would be
running "foreign" equipment (they don't have it), we don't have a lot of it
in the engineering group, and most of our external field test sites wouldn't
necessarily try such a configuration unless someone explicitly asked them to
(and I doubt anyone would have asked them to).
I can try to search the problem report database, but if you want there to be
even a small chance this will get fixed (and it's not likely to get fixed,
as the next release based on the V3.0 code stream is almost completed, and
the Bookreader is slated to get replaced by some new technology in a future
release and the engineering group that produced it may already have gone
away as happens when products get retired), then you need to report it as a
problem through the "formal" channels (your Digital CSC contact) so that it
will be tracked. But I doubt it will get fixed unless its a bug in the X
Window System (rather than in the Bookreader).
Dr. Thomas P. Blinn, UNIX Software Group, Digital Equipment Corporation
110 Spit Brook Road, MS ZKO3-2/U20 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 881-0646
Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
-----------------------------------------------------------------------
Neil R. Smith, Research Associate neils_at_csrp.tamu.edu
Climate System Research Program (409) 862-4342
Dept. of Meteorology, Texas A&M Univ., USA (409) 862-4132 FAX
-----------------------------------------------------------------------
Received on Sat Jun 24 1995 - 01:27:40 NZST