Red Hat Bugzilla – Bug 155853
garbage string from Combo.getText() causes NPE creating new run configuration
Last modified: 2007-11-30 17:11:04 EST
Description of problem: Error creating new "Java Application" run configuration. Version-Release number of selected component (if applicable): eclipse-platform-3.1.0_fc-0.M6.10 How reproducible: Always. Steps to Reproduce: 1. Create a simple Java Project with a Hello World example 2. Hit the run button 3. Double-click "Java Application" Actual results: Expected results: No error. New run configuration. Additional info: Double-clicking "Java Application" after the failure works. None of this does not happen with Sun's JVM.
Created attachment 113616 [details] log with failure information
I don't get this anymore with gcc*-4.0.0-1 and eclipse-platform-3.1.0_fc-0.M6.11. Closing.
This is still happening with "Eclipse Application" - same stack trace.
Archiving what I've got so far ... Combo.getText() in PerpectivesTab.updateConfigFromCombo() is returning a string with garbage at the end (Ω) when run with gij. This causes the NPE because it's not recognized as a string. Investigating this further it seems as though the string is getting corrupted somewhere. I made a stand-alone test for Combo.getText() and the string is not corrupt with both VMs. However, I did notice that OS.strlen() is getting called an extra time with gij. I'm not sure if this is related but I'll going to keep digging.
*** Bug 152314 has been marked as a duplicate of this bug. ***
The small app actually does have the corrupted string, just not all the time. When the string is corrupted I also see: (<unknown>:24571): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Created attachment 113812 [details] swt app to make a Combo box
Created attachment 113876 [details] patch to work around the NPE I think it might be a good idea to work around NPE temporarily until the cause of the corrupt string is found. Andrew, what do you think?
I think that's a good plan for the short term.
Ok, that patch will be in 3.1.0_fc-0.M6.13
Verified in 3.1.0_fc-0.M6.13. Ben, I'll leave it up to you to close this bug or leave it open as you see fit.
Hey Andrew, Billy pointed me to the actual cause of the problem (see the upstream bug listed below). I'm going put the proper fix into a new version so we shouldn't put 3.1.0_fc-0.M6.13 into FC4.
Ok, I removed my patch and added the upstream fix for 3.1.0_fc-0.M6.14. Andrew, can you verify this fix and close the bug if it works. Thanks, Ben
This works for me. Closing.