It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×6,033
×3,951

question asked: Feb 06 '13, 6:35 p.m.
question was seen: 4,608 times
last updated: Oct 16 '13, 9:55 p.m.

Related questions

RRC on RHEL 6.3 throws gdk error when rendering visual artifacts

0
Aaron Cohen (820●78●51) | asked Feb 06 '13, 6:35 p.m.
JAZZ DEVELOPER
edited Feb 06 '13, 6:36 p.m.
I have CLM (DM, RM. RTC, QM) on RHEL 6.3 (64bit) and the server crashes whenever I load a visual artifact in RM that uses the converter application.  I followed the steps on this technote (http://www-01.ibm.com/support/docview.wss?uid=swg21410023). Is there anything else I should have done?

I noticed the following in the tomcat logs:
(SWT:3438): GLib-GObject-WARNING **: cannot register existing type `SwtFixed'
(SWT:3438): GLib-GObject-WARNING **: cannot register existing type `SwtTextRenderer'
(SWT:3438): GLib-GObject-WARNING **: cannot register existing type `SwtPixbufRenderer'
(SWT:3438): GLib-GObject-WARNING **: cannot register existing type `SwtToggleRenderer'
java: xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
JVMDUMP039I Processing dump event "abort", detail "" at 2013/02/06 18:18:46 - please wait.
Gdk-ERROR **: The program 'SWT' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadIDChoice (invalid resource ID chosen for this connection)'.
  (Details: serial 244 error_code 14 request_code 1 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...

It is CLM 4.0.1 setup with tomcat and Derby. I am using the "Money that Matters" sample project. The startup script is based on http://www-01.ibm.com/support/docview.wss?uid=swg21425943

cat clmStart.sh 
#! /bin/bash
Xvfb :1 -screen 0 800x600x24&
export DISPLAY=localhost:1.0
cd /opt/IBM/JazzTeamServer/server/
DISPLAY=localhost:1.0 ./server.startup

The Xvfb package is xorg-x11-server-Xvfb-1.10.4-6.el6_2.3.x86_64

I also noticed the following in the Xvfb output:

SCREEN: 0 objects of 176 bytes = 0 total bytes 0 private allocs
DEVICE: 4 objects of 48 bytes = 192 total bytes 0 private allocs
CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 5 objects, 208 bytes, 0 allocs
4 DEVICEs still allocated at reset
DEVICE: 4 objects of 48 bytes = 192 total bytes 0 private allocs
CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 5 objects, 208 bytes, 0 allocs
1 SELECTIONs still allocated at reset
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 16 bytes, 0 allocs
1 PIXMAPs still allocated at reset
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 16 bytes, 0 allocs
expected keysym, got XF86TouchpadOn: line 120 of inet
expected keysym, got XF86TouchpadOff: line 121 of inet

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Shuhichi Saitoh (200●5●9) | answered Oct 16 '13, 9:41 p.m.
edited Oct 16 '13, 9:55 p.m.
Aaron,

Suppose this answer is too late for you, however I observed the very same problem in my environment, and I finally workaround the problem.
So I will share what I did with you and others.

I was using Tomcat, installing all applications (RRC/RTC/RQM and RSA DM) on it.
I'm not sure root cause of the problem, but what I did was that separate "converter" application JVM with the other JVM. (referring the jazz.net article https://jazz.net/library/article/1089)

- Create a directory (/opt/IBM/converter/server)
- Copy tomcat directory in the original JazzTeamServer to the above directory
- Delete .war files in the [copied tomcat]/webapps directory except converter.war
- Copy server.startup shell script from original JazzTeamServer to the /opt/IBM/converter/server.
- Modify the copied server.startup shell script, to locate JAZZ_HOME and JRE_HOME on original JazzTeamServer
- Modify the [copied tomcat]/conf/server.xml to avoid port conflict
- Modify the com.ibm.rdm.fronting.server.ConverterURL value in the /opt/IBM/JazzTeamServer/conf/rm/fronting.properties to locate the copied converter.
- Start both tomcat

Converter application on the copied tomcat works fine.

Hope this helps,

Shuichi Saito


Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.