Comment 1 Carolyn MacLeod 2012-05-29 16:10:51 EDT

Interesting. You must have a rogue program that is answering 0 for a call to DtDtsDataTypeToAttributeValue.

Markus, please confirm that your desktop is CDE.
(For curiosity only, you could put a breakpoint on NPE and see if you can tell which program is failing).

SSQ, please take a look at gtk Program.cde_getAttribute() and consider changing:
  if (attrValue == 0) return null;
to:
  if (attrValue == 0) return "";

I believe that the only hashCode field that could be null is Program.command on CDE. I think empty string is a better choice?

Comment 2 Silenio Quarti 2012-05-29 17:31:25 EDT

Markus, do you know which GTK version and desktop the tests are running on? Car, I suspect this is not a CDE related problem since the test are for Linux GTK (not Solaris, AIX or HPUX).

Comment 3 Carolyn MacLeod 2012-05-29 17:39:47 EDT

OK, but it is possible to have NPE on CDE if DtDtsDataTypeToAttributeValue returns 0, so we should protect against that. I didn't see another way to get null for name, command, or display fields except for that way. (but I could have missed something!  :)

Comment 4 Silenio Quarti 2012-05-29 17:41:31 EDT

The problem is probably in Program.gio_getProgram(). Program.name and Program.command may have not been initialized there.  I believe if Program.command is null, Program.gio_getProgram() should return null and if Program.name is null, we should initialized it "".

Comment 5 Carolyn MacLeod 2012-05-29 18:18:09 EDT

Ah, of course. When I looked at gio_getProgram() earlier, I was looking at where program.name and program.command were assigned... but of course it's where they are *not* assigned that makes the difference. <g>
So, yes, I agree that if name is null, that's ok and it should be ""; but if command is null then program should be null.

So for the CDE problem, we should rewrite cde_getProgram() a little bit, something like:
	String cmd = cde_getAction(mimeType);
	if (cmd == null) return null;
	Program program = new Program();
	program.display = display;
	program.name = mimeType;
	program.command = cmd;

Comment 6 Markus Keller 2012-05-30 07:59:34 EDT

Just to spell this out: I did not try to reproduce this problem on our GTK machine. I just saw it when I scanned the test failures for patterns.

I don't know more about the test machine. Java properties are available in the test results page (you have to look at the raw HTML due to bug 342441), but I don't think they contain enough information to help here.

The easiest way to find the problematic program is to modify the test and print out debugging information when the NPE occurs.

Comment 7 Carolyn MacLeod 2012-05-30 10:56:37 EDT

Thanks, Markus. Sorry - I thought you were seeing the failure on your machine. I couldn't reproduce the problem on my Linux GTK machine, so I suspect it won't fail on your machine either. Probably something strange about the test machine.
Good suggestion about adding debug output to the test, but first I think we'll just make the obvious fixes in our code. I was just asking which program was a problem because I was curious to know if you had installed some new program recently that was causing trouble.  :)

Comment 8 Grant Gayed 2012-05-30 15:58:08 EDT

Created attachment 216530 [details]
patch to apply post-Juno

Comment 9 Silenio Quarti 2012-06-06 11:36:43 EDT

This test only fails on the testing machine. We were not able to reproduce it locally. We believe it is a configuration problem on the test machine (some installed program without a name).  The patch above works around the configuration problem.

Comment 10 Grant Gayed 2012-07-19 11:33:09 EDT

Fixed > 20120719.  The change was applied earlier in the week to master and it fixed the failing test case, so it has now been applied to the streams for 3.8.1 and 4.2.1, patch: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=bbdbcbe71c1e8c0a2a76acdda4145804c98d3be5 .

Comment 11 Markus Keller 2012-09-05 12:15:59 EDT

Test passes in M20120829-1200.