Community
Participate
Working Groups
We have an RCP application that crashes when run on Solaris 10 using GTK, with an error like the following: The program '' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 1023 error_code 2 request_code 12 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.) I cannot yet duplicate this on a snippet (still trying), but looking at the bug 110163, I tried commenting out the calls that install the look and feel, and then it worked a few times. The app sometimes crashes and sometimes does not, when using the debugger inside Eclipse. We use Eclipse 3.2RC3, but I also tried this using 3.2RC5, with the same result. Our app works fine on Windows. It also works fine on HP (with the recent bug fix for the bug 140843) using 3.2RC5. It had also worked fine on Solaris 9 using Motif. I tried using the DEBUG option by setting "Display.DEBUG = true", but didn't get any stack trace. Is there anything else I can do to debug this further? I have set the severity to critical as our product is getting closer towards the release and our organization has committed to using Eclipse 3.2. If there is anything I can do to debug this further, please let me know.
I wanted to add that we use SWT_AWT.
*** Bug 144945 has been marked as a duplicate of this bug. ***
*** Bug 144951 has been marked as a duplicate of this bug. ***
*** Bug 144952 has been marked as a duplicate of this bug. ***
The "Display.DEBUG = true" MUST be done before the Display is created. Are you sure you are doing this?
Did you try the work around in comment 65 in bug 140843 to stop GTK from exiting?
I think you meant comment #65 in bug 110163. I tried that out and that workaround works. The crash does not happen when I use that code. What would be the proper way to implement this in an application? I am thinking about whether it would be good to incorporate this in our product code, or if there is something else we should watch out for. Would this in some way be incorporated in the Eclipse code?
Additionally, when I set the look and feel to GTK, I get these warnings on the console: ../gtk-2.0-key/gtkrc:10: Binding specification is unsupported, ignoring ../gtk-2.0-key/gtkrc:18: Binding specification is unsupported, ignoring Can I somehow suppress these warnings?
>Would this in some way be incorporated in the Eclipse code? Not really. Eclipse or SWT should not be playing with the AWT event queue to work around a bug/feature in GTK. >Can I somehow suppress these warnings? You would need to ask someone from Sun.
>The "Display.DEBUG = true" MUST be done before the Display is created. >Are you sure you are doing this? What happened with this? I would like to mark this bug as a duplicate of bug 110163 but don't really want to without a stack trace.
(In reply to comment #9) > >Would this in some way be incorporated in the Eclipse code? > Not really. Eclipse or SWT should not be playing with the AWT event queue to > work around a bug/feature in GTK. > >Can I somehow suppress these warnings? > You would need to ask someone from Sun. Steve, Are you saying that any RCP based app using the AWT_SWT bridge on Solaris will be forced to do this manual override? That is not a very good solution. I would like to see an OOTB solution for this problem. Either SWT supports GTK or it doesnt. If it doesn't than SWT based solutions that use AWT_SWT are not really supported for Solaris. -Stu Pond
The real question is, where are the X errors coming from and how can they be stopped? I suspect strongly that the problem is in AWT but need and answer from my question in comment 10.
I did put the Display.DEBUG=true before the Display is created. I still did not get a stack trace... got the same error as I mentioned before.
Ok, we broke down and worked around the (suspected) AWT problem in bug 110163. Since RB says the work around also fixes him, this bug report is a duplicate. *** This bug has been marked as a duplicate of 110163 ***
