Bug 76950 - xosview never displays
Summary: xosview never displays
Status: CLOSED DUPLICATE of bug 67117
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: xosview (Show other bugs)
(Show other bugs)
Version: 2.1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-30 00:23 UTC by Summer Maynard
Modified: 2013-12-15 23:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 18:50:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Summer Maynard 2002-10-30 00:23:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
xosview never displays.  I have tried xosview-1.7.3-5 that ships with AS 2.1, as
well as 3-10 that ships with 7.3.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1./usr/bin/X11/xosview
2.
3.
	

Actual Results:  PID is created, shows as running in a 'ps', but never actually
displays anything.

Expected Results:  Should have displayed.

Additional info:

Comment 1 Ngo Than 2002-11-08 01:00:27 UTC
strange, it works for me. How many CPUS does your machine have?

could you please try 1.8 from 8.0 and let me know if it works,

Comment 2 Summer Maynard 2002-11-08 01:50:21 UTC
That IS strange.  This is occurring on a fully updated AS2.1 box with only 1
CPU.  I have also reproduced it on another box with 1 CPU.  I looked at it
because I also have heard of at least three customers with the same issue. 
hmmmmm....

I have tried to install 1.8 that ships with 8.0, which sets off a chain of
dependencies.  Here's the output from 'rpm -Uvh --force xosview-1.8.0-8.i386.rpm':

error: failed dependencies:
        libstdc++.so.5   is needed by xosview-1.8.0-8
        libstdc++.so.5(GLIBCPP_3.2)   is needed by xosview-1.8.0-8

When I go to install the libstdc++ package from 8.0, it sets off a huge list of
things that are using the old one.

Is there something else I could try?

Comment 3 Ngo Than 2002-11-08 11:10:55 UTC
please try this one on porkchop, i have rebuild it in 7.2 build tree.
 /mnt/redhat/beehive/comps/dist/7.2-scratch/xosview/1.8.0-8/i386/xosview-1.8.0-8.i386.rpm

Comment 4 Summer Maynard 2002-11-15 19:11:23 UTC
That one works just fine!  Did you find the problem with the other one?

Comment 5 Ngo Than 2002-11-18 15:28:01 UTC
I asumme that it's perhaps caused from kernel. I have tested xosview-1.7.3-5 on
Red Hat 7.2 and it works fine. AS2.1 should actually have the same enviroment
(apart from kernel).

Does it work for you, if you install kernel from 7.2 and reboot it with this kernel?

It would be nice if i could have test account on this machine to reproduce this bug.

Comment 6 Nils Philippsen 2003-02-21 09:46:11 UTC
This problem still persists with kernel-2.4.9-e.12 (kernel-enterprise-2.4.9-e.12).

With an older kernel, I could solve this proble bz upgrading to xosview from RHL
7.3, but with all xosview versions it hangs at reading /proc/stat:

[root@ls3187 root] strace xosview
[...]
open("/proc/stat", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4011d000
read(4, "cpu  392205 54 193010 28209567\nc"..., 4096) = 4096

here it hangs, and it is clear why, because the contents of /proc/stat are more
than 4096 bytes. Because it is a proc file, a program needs to read this at
once, i.e. it should try to read 8192 not 4096 bytes. xosview waits for more
data to come, but it just won't ever happen.

Comment 7 Nils Philippsen 2003-02-21 12:09:49 UTC

*** This bug has been marked as a duplicate of 67117 ***

Comment 8 Red Hat Bugzilla 2006-02-21 18:50:03 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


Note You need to log in before you can comment on or make changes to this bug.