Bug 78949 - LTC1391-Hung up solidly after the application frame is resized
LTC1391-Hung up solidly after the application frame is resized
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: sawfish (Show other bugs)
7.1
s390 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-03 16:12 EST by Need Real Name
Modified: 2007-04-18 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-16 11:48:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-12-03 16:12:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
Gecko/20011128 Netscape6/6.2.1

Description of problem:
Hung up solidly after the application frame is resized

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


How reproducible:
Always

Steps to Reproduce:
Hardware Environment:
z900(64bit)

Software Environment:
Redhat 7.1 for s390x (Under VM)


VM user info:
     memory: 256M
     dasd: 3390 * 2 volume
     network: OSA-E


Steps to Reproduce:
0. Install Redhat 7.1 for S/390(64bit) include Japanese package.
   Our Redhat Linux's image files are on ftp://hursley.linux.ibm.com
1. Connect to the 390x Linux from pc client through XDM.
   $X -query (390x linux)
2. Logon to the Redhat with GNOME/Sawfish
3. Open an terminal application like "kterm"or"Gnome Emulation Terminal".
4. Resize the application frame.
   Then, System hangs up solidly.


	

Actual Results:  System hungs up solidly



Expected Results:  It should work correctly without any error.



Additional info:

This problem occurs without Japanese packages.

I tried to reproduce the problem on a 
31-bit S/390 machine with Red Hat 7.2, using gnome/sawfish and connecting from 
my PC. The problem does not occur. I believe it might be specific to Red Hat's 
S/390 64-bit edition.
Comment 1 Mike A. Harris 2002-12-05 07:44:55 EST
The S/390 locks up?  Or the PC locks up?
Comment 2 Mike A. Harris 2002-12-05 07:46:29 EST
ftp://hursley.linux.ibm.com/ doesn't exist when I try to connect to it BTW
Comment 3 Need Real Name 2002-12-05 18:16:03 EST
Posted question to LTC1391
Comment 4 Need Real Name 2002-12-09 12:31:42 EST
I will try to get answer to what exactly locks up. Also, the site that the
originator noted above is an internal site and that is why you cannot access it.
If there is something about the image you need to know can you ask it here so
that the  submitter can answer it for you. Thanks very much.
Comment 5 Mike A. Harris 2002-12-09 15:14:47 EST
It is not clear at all to me from the initial bug report what system
is what above, and what problem is happening where.  I need a much
much greater amount of detail about both systems, and what exactly
is occuring, including what role each system is playing in the problem.

This bug is reported against Red Hat Linux 7.1/s390, and it sounds to
me like you're saying the z900 is locking up when resizing a window.
Since s390 does not contain video hardware, I would have to conclude
that this is not an XFree86 bug, but some kind of kernel bug or a
hardware problem.  Does the s390 have any proprietary OCO modules
loaded?
Comment 6 Need Real Name 2002-12-10 10:14:38 EST
Adding comment from our developer,Kosuke Yoshida
 I was on leave yesterday, sorry for my late response..

Recently, the ftp site which was specified in initial bug report was move to a 
restricted site. 
https://ftp3.linux.ibm.com/rh_terms.html The downloadable site is prepared for
IBM TestUser. OtherUser cannot access it.

Unfortunately, we cannot verify this problem on z64 environment any longer, 
because the lease term of our z64 environment has already expired . 
Anyway, you should create a Redhat 7.1 for s/390(64bit) environment, and try to 
reproduce this problem.

So, I' d like to describe a initial bugs report again.
- zSeries 64-bit system:
IBM M/T 2064 zSeries 900 with Redhat 7.1 for s/390(64bit)  

Steps to Reproduce:
0. Install Redhat 7.1 for S/390(64bit) include Japanese package.
   Our Redhat Linux's image files are on 
https://ftp3.linux.ibm.com/rh_terms.html/....
1. Connect to the RH7.1 for S/390(64bit)from pc client through XDM.
   $X -query (390x linux) from PC client
2. Logon to the Redhat with GNOME/Sawfish
3. Open an terminal application like "kterm"or"Gnome Emulation Terminal".
4. Resize the application frame(window).
   Then, X client hangs up solidly. <== This is a problem

Additional Information:
This problem occurs without Japanese packages.
this problem does not occur on SLES7 for s/390 31-bit and SLES7 for s/390 64bit.
This does not occurs on Redhat 7.1 for s/390 31-bit.
We confirmed that accessed RH7.1 z64 from some PC clients, and this problem 
occurred solidly.

==> It means this is a Redhat 7.1 for s/390(64bit) unique problem.

Comment 7 Mike A. Harris 2002-12-20 15:57:04 EST
In the initial bug report, you stated:

4. Resize the application frame.
   Then, System hangs up solidly.

Actual Results:  System hungs up solidly


But in your last comment, you state:
4. Resize the application frame(window).
   Then, X client hangs up solidly. <== This is a problem

These two pieces of information conflict with each other.  What is hanging,
the X client, or the entire system, and if the entire system, which system
is hanging, the s390, or the one running the X server?
I'm still confused.


Comment 8 Need Real Name 2003-01-23 10:15:30 EST
Here is a clarification of the above
------- Additional Comment #19 From kosuke@jp.ibm.com  2003-01-20 20:46 -------
I'm sorry to confusing you. As far as I remember, "X-client hangs up" is 
correct. 
Unfortunately, we cannot verify this on z64 environment any longer, 
because our lease term of z64 environment has already expired . 
So, if someone can re-test on Japanese z64 environnent instead of us,
I will agree with closing this problem.  Thank you. 

Comment 9 Mike A. Harris 2003-01-26 04:47:40 EST
Ok, closing bug as WONTFIX, as it isn't yet entirely clear what the
problem is exactly and reporter has indicated the hardware is no
longer available for further troubleshooting.

If the hardware is available again at some point, and the problem recurs,
please reopen the report and we can try to continue troubleshooting.

Thanks.
Comment 10 Need Real Name 2003-03-03 13:48:52 EST
Reopening 

     ------- Additional Comments From chinen@jp.ibm.com  2003-03-03 07:07 -------
Thanks to David, I was able to reproduce this bug.

The answer against RedHat's question in Comment #17 is `sawfish'.

(RedHat's Question)
| What is hanging,
| the X client, or the entire system, and if the entire system, which system
| is hanging, the s390, or the one running the X server?

Properly speaking, sawfish is not hanging but it is killed and dumps a core file.
I'll be writing the way of reproducing in the next comment.

------- Additional Comment #24 From Mitsuru Chinen  2003-03-03 09:02 -------

Synopsis:
Sawfish is killed and dumps core with resizing a window on s/390x


Environment:
[s/390x machine]
 OS: Red Hat Linux release 7.1 (Seawolf) for S390x (Under VM)
 kernel : 2.4.9-37 #1 SMP Sat Apr 13 05:45:12 EDT 2002
 Concerned Packages :
   XFree86-xdm-4.0.3-22.71.1sx.s390x.rpm
   gnome-core-1.2.4-16.s390x.rpm
   sawfish-0.36-7.s390x.rpm
   (and dependencies)
 Terminal Emulatorers :
   xterm : XFree86-4.0.3-22.71.1sx.s390x.rpm
   kterm : kterm-6.2.0-20.s390x.rpm
   gnome-terminal : gnome-core-1.2.4-16.s390x.rpm

[i686 machine]
 OS: Red Hat Linux release 8.0 (Psyche) for i686
 kernel : 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002
 Concerned Packages:
   XFree86-4.0.3-22.71.1sx.s390x.rpm
   (and dependencies)


Constitution:
o s/390x machine is a application server. gnome, sawfish and all X clients
 are executed on this machine.
o i686 machine is a X Terminal. Users operate each X client on this machine.
o Users login RedHat 7.1 for s390x from i686 machine via xdm.


Steps to Reproduce:
0. On the s/390x machine, edit the setting file of xdm to accept XDMCP session.

# diff -u Xaccess.orig Xaccess
40c40
< # *                                    #any host can get a login window
---
> *                                      #any host can get a login window

# diff -u xdm-config.orig xdm-config
28c28
< DisplayManager.requestPort:    0
---
>! DisplayManager.requestPort:  0


1. On the s/390x machine, change the desktop environments into Gnome.
 $ switchdesk GNOME

2. On the s/390x machine, boot xdm up.
 $ su -
 # xdm

3. On the i686 machine, connect s/390x machine via XDMCP session.
 $ X -query (s/390x hostname)

4. On the i686 machine, login to the RedHat s/390x through xdm.

5. After sawfish boots, open an terminal emulator like "xterm",
  "kterm" or "gnome-terminal".

6. Resize the application frame of the terminal emulator.
  Then the terminal emulator hangs up and sawfish is killed with
  dumping a core file.                  <-- Problem!!!


Actual Results:
Sawfish is killed.
Although X clients are alive, they don't answer the user's
operation because window manager is dead.


Expected Results:
Sawfish should be alive even if a terminal emulator is resized.
Comment 11 Mike A. Harris 2003-03-03 14:30:37 EST
So this isn't really an X server bug, or XFree86 bug, but rather a
sawfish bug.

Reassigning to sawfish...
Comment 12 Havoc Pennington 2003-03-03 15:00:06 EST
s390 developers here have suggested that you give the output of lsmod, 
and that if it includes a binary-only module, you try to reproduce the 
problem without that module.
Comment 13 Need Real Name 2003-03-05 13:57:58 EST
Adding comments from LTC bug
------- Additional Comment #29 From Mitsuru Chinen  2003-03-03 23:02 -------

Hello Ken,
Could you please submit the following comments?

---8<------8<---

Excuse me, but I can't understand what `binary-only module' means.
I would appreciate it if you could give me more details.

The outputs of lsmod is:
  Module                  Size  Used by    Tainted: P
  autofs                 15556   1  (autoclean)
  qeth                  174456   1  (autoclean)
  qdio                   50232   1  (autoclean) [qeth]
  ipchains               53344   0

Thank you,


------- Additional Comment #30 From Mitsuru Chinen 2003-03-04 07:08 -------

Hi Ken,
Could you please also submit the following comments to RedHat?

---8<------8<---
The root cause lurks in GNU MP library which is used by sawfish.
The latest GNU MP library (gmp-4.1.2.tar.gz) doesn't have this problem.

  GMP Download Page > http://www.swox.com/gmp/#DOWNLOAD

The reason why sawfish was killed is on copying array.
Reading the gmp-3.1.1 source code, you can find a macro named `MPN_COPY' at
the mpn_divrem function (gmp-3.1.1/mpn/divrem.c line 56).

  MPN_COPY (qp, q2p, qn);

This macro copies `qn' elements from a array `q2p' to another array `qp'.

I checked the value of the `qp' when a window was resized and found the `qp'
value was NULL. When a value is put into NULL pointer, SIGILL is generated.
As you know, the program is killed when it catchs SIGILL.

To fix this bug, I would appreciate it if you could make a new GNU MP library
packages.
Thank you,
Comment 14 IBM Bug Proxy 2003-03-26 17:59:23 EST
Hi Ken,
Could you please also submit the following comments to RedHat?

---8<------8<---
The root cause lurks in GNU MP library which is used by sawfish.
The latest GNU MP library (gmp-4.1.2.tar.gz) doesn't have this problem.

  GMP Download Page > http://www.swox.com/gmp/#DOWNLOAD

The reason why sawfish was killed is on copying array.
Reading the gmp-3.1.1 source code, you can find a macro named `MPN_COPY' at
the mpn_divrem function (gmp-3.1.1/mpn/divrem.c line 56).

  MPN_COPY (qp, q2p, qn);

This macro copies `qn' elements from a array `q2p' to another array `qp'.

I checked the value of the `qp' when a window was resized and found the `qp'
value was NULL. When a value is put into NULL pointer, SIGILL is generated.
As you know, the program is killed when it catchs SIGILL.

To fix this bug, I would appreciate it if you could make a new GNU MP library
packages.
Thank you,
Comment 15 Florian La Roche 2003-05-16 11:48:18 EDT
gmp is updated for our next release for mainframe, so I am closing this
report.

Thanks a lot for your bug report,

Florian La Roche

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