NPE in the EDT

[ddyer0]

This was built a week ago.

[2026/04/08 23:44:42] log request from bridge.MasterForm (67.128.194.161)
data=[Java cpu=3.9% screen=1536x2048 diag=12.8 ppi=200 deviceDPI=200 scale =2.083333 platform =Ios 9.22 Codename1 os.name=Ios] (EDT 9 threads)last chance error catcher
error is : java.lang.NullPointerException
java.lang.NullPointerException
at com_codename1_ui_ComboBox.fireClicked:490
at com_codename1_ui_ComboBox.pointerReleased:562
at com_codename1_ui_LeadUtil.pointerReleased:171
at com_codename1_ui_Form.pointerReleased:3795
at bridge_MasterForm.pointerReleased:4139
at com_codename1_ui_Component.pointerReleased:5669
at bridge_MasterForm.pointerReleased:2485
at com_codename1_ui_Display.handleEvent:2322
at com_codename1_ui_Display.edtLoopImpl:1164
at com_codename1_ui_Display.mainEDTLoop:1054
at com_codename1_ui_RunnableWrapper.run:139
at com_codename1_impl_CodenameOneThread.run:179
at java_lang_Thread.runImpl:200

[shai-almog]

What's in MasterForm that can trigger this?

This is line 490.

It's been here since 2012 or before. This means the parent form of a ComboBox is null. Do you rmove components or manipulate the form as part of the pointer pressed event chain?

If so that can very much trigger these sorts of problems.

[ddyer0]

Nothing - masterform is just a wrapper I use for debugging sometimes.

public void pointerReleased(int x,int y)
{
	//G.print("\nreleased ",x," ",y);
	//G.print(G.getStackTrace());
	super.pointerReleased(x,y); 
}

And some logic to slightly move the point in some circumstances
public void pointerReleased(int xa[],int ya[])
{ if(xa!=null && xa.length>0)
{
//G.startLog("pointer released");
//G.print("mrelease ",xa[0]," ",ya[0]);
Point p = moveNearerMenu(xa[0],ya[0]);
if(p!=null)
{ xa[0]=p.getX(); ya[0]=p.getY();
//G.print("release moved ",xa[0]," ",ya[0]);
}
super.pointerReleased(xa,ya);
}
}
This is part of the splash screen, so simultaneously in another thread the real window is being built.

[shai-almog]

in another thread

That's probably the reason.Someone opens a combo box in one form and by the time the finger is released the combo box is no longer there. You shouldn't build components off the EDT. I will add a guard for this NPE but that's just hiding a bug in your code that will bite you in a different way.

[ddyer0]

This isn't run naked, it's an element several layers down in a form. If its parent is null, it's probably
in the process of being pulled down.

[shai-almog]

A form doesn't become null when it has a reference. This actually strengthens the case. It means that one of its parents or itself was removed from the form.

[ddyer0]

There's some kind of race between one process pulling down the window and some other process
feeding it events, right?

[shai-almog]

There's no such thing as "pulling down a window" in Codename One. There are no races since Codename One is single threaded.

[ddyer0]

I had a lot of NPE problems when using frame.remove until I made sure it escaped to edt on the way down. I'm
pretty sure the frame removal is synchronous with edt, but somehow this event is being received after the window
has been removed. At least that's the way it looks to me.

[shai-almog]

The fact that the window is no longer showing doesn't mean that events stop processing. Again, there's no such a thing as "frame removed" in Codename One. This can only happen in one way: one of the getParent() methods for ComboBox or one of its parents returns null. That means someone removed that component from the parent after the pointerPressed was invoked.