Strange "Null Object Reference" errors

[angoid]

Hi folks,

This is kind of a follow-on from thread144-888205 but I'm not convinced it is necessarily tied up with DDE.

We're getting customers report strange "Null object reference" errors on a sporadic basis. It is always the same line that will fail (if it fails at all) and the failures are occurring enough to be highly annoying to the affected customers but not reliably, thus trying to single-step using the debugger is futile.

In most cases, the code that's crashing is code that cannot fail - such as testing a simple instance variable or something like that.

We had problems under PowerBuilder 8, now under 9.0.1 (build 7119, built 11-FEB-04 18:06:41), and I suspect they'll continue under 10.5 (build 4523).

Has anyone else experienced strange inconsistent "Null object reference" errors, and if so, what was the cause?

Thanks in advance!

If you don't know what eschatology is then don't worry; it's not the end of the world.

 

[bernds44]

HI

I encountered similar (?) problems with activex controles used in objects. with no used activex registered on a computer it fails fith error NULL OBJECT....

mybe it helps if you could post some code where the crash happends

 

[angoid]

Thanks bernds44,

It's a bit tricky to post code as it's spattered all over the place in little functions, etc. but we're not using ActiveX controls at all AFAIK.

However, I do think it could be tied up with calls to what we call the "Data Currency Server" which uses the ExecRemote() method.

Sometimes a like such as the following will fail:

if i_bfrommenu = true then

where i_bfrommenu is an instance variable that has been set to TRUE or FALSE earlier in the same script.

I read somewhere that where close(this) is used in a nested IF, the next statement should always be RETURN (and not the closing END IF(s)).

However, here is some sample code ..... the first IF statement (in bold red) causes the abort, when it happens:

OpenWithParm(w_letter_additional_param,i_strucLetters.Letter_Parameters)
i_Struct_Letter_Return=Message.PowerObjectParm
[b][COLOR=red]IF i_Struct_Letter_Return.is_returnvalue='S' THEN // Error[/color][/b]
	ROLLBACK USING itr_Transaction;
	IF (itr_Transaction.SQLCode <> 0) THEN
		gf_system_error_gen(i_iWin_id, itr_Transaction.SQLDBCode, FALSE, "ORA", itr_Transaction.SQLErrText)
	END IF
	Return -1
ELSE
	...

An object will always have been passed in the PowerObjectParm, so it's not that this is getting something that is null. When we had this before (tied up with the DDE errors - please see earlier thread), even testing for IsValid or IsNull on an "offending" object would give a "Null Object Reference" error!

If you don't know what eschatology is then don't worry; it's not the end of the world.

 

[mbalent]

I'd look into the value of Message.PowerObjectParm and verify that it is always being set correctly from the close of w_letter_additional_param.

Matt

"Nature forges everything on the anvil of time

 

[angoid]

Thanks mbalent .... that's what I'd normally do but I have even seen this failure on lines that check the object for validity / nullness (if there is such a word).

Investigating another one this morning shows it happening on the line marked in red:

//Setting the wlrn value to the data currency server
if g_busingdde then
	l_iRetVal = gf_set_currency('WLRN',String(i_lwlrn),Parent)
	iF l_iRetVal <=0 THEN gf_SetMicroHelp('Cannot set current WLRN: '+String(l_iRetVal))
end if

IF l_iRetVal = 1 THEN
	IF g_struct_sys_para_info.shortlist_production='Y' THEN
		[COLOR=red][b]IF i_bJustCancelled THEN[/b][/color]
			gf_SetMicroHelp("Updating Shortlist Index...")
			l_iRetVal=wf_cancel_shortlist()
			gf_SetMicroHelp("")
			IF l_iRetVal=-1 THEN
				CLOSE (parent)
			END IF
			gf_SetMicroHelp("Updating Application History...")
			l_iRetVal=wf_appl_history()
			gf_SetMicroHelp("")
			IF l_iRetVal=-1 THEN
				Close(Parent)
			END IF
		END IF
	END IF
END IF

The variable bJustCancelled is primed to FALSE in the Instance Variables declaration, and nowhere in the window (which is not inherited) is its value set to null. But even if it was null, the test (I think) would only fail rather than generate an error.

I think the function gf_set_currency() could be at the bottom of it; it uses functions such as ExecRemote() and GetRemote(), and we have had problems with that.

If you don't know what eschatology is then don't worry; it's not the end of the world.

 

[angoid]

OK, more investigation into this has clarified the fault a bit more, and it might be a fault in PowerBuilder itself. I knocked up a very simple window as follows (using 'Edit Source'):

forward
global type call341187 from window
end type
type cb_2 from commandbutton within call341187
end type
type cb_1 from commandbutton within call341187
end type
end forward

global type call341187 from window
integer width = 1115
integer height = 400
boolean titlebar = true
string title = "Untitled"
boolean controlmenu = true
boolean minbox = true
boolean maxbox = true
boolean resizable = true
long backcolor = 67108864
string icon = "AppIcon!"
boolean center = true
cb_2 cb_2
cb_1 cb_1
end type
global call341187 call341187

type variables
String is_appname = 'OHMS_DATA_CURRENCY'
String is_topic = 'DDE'

end variables

on call341187.create
this.cb_2=create cb_2
this.cb_1=create cb_1
this.Control[]={this.cb_2,&
this.cb_1}
end on

on call341187.destroy
destroy(this.cb_2)
destroy(this.cb_1)
end on

type cb_2 from commandbutton within call341187
integer x = 585
integer y = 96
integer width = 402
integer height = 92
integer taborder = 20
integer textsize = -8
integer weight = 700
fontcharset fontcharset = ansi!
fontpitch fontpitch = variable!
fontfamily fontfamily = swiss!
string facename = "MS Sans Serif"
string text = "cb_2"
end type

event clicked;close(parent)
end event

type cb_1 from commandbutton within call341187
integer x = 73
integer y = 96
integer width = 402
integer height = 92
integer taborder = 10
integer textsize = -8
integer weight = 700
fontcharset fontcharset = ansi!
fontpitch fontpitch = variable!
fontfamily fontfamily = swiss!
string facename = "MS Sans Serif"
string text = "cb_1"
end type

event clicked;Integer li_retval, li_count
String ls_x

li_retval = ExecRemote("supp10;UPRN:253645", is_appname, is_topic)

close(parent)
end event

All it is is a simple window with 2 buttons on it. If you click cb_1, it calls the data currency server and closes the window. cb_2 simply closes the window.

I modified the data currency program (called by ExecRemote) to incorporate a delay of 5 seconds. When I run this window and click cb_1, the window waits for the ExecRemote to finish (as expected) BUT both buttons are still clickable.

This means I can click cb_2 and close the window. Thus when the cb_1 code resumes, it finds that its script is no longer there - PB seems to faff about internally and then finally you get a strange Null Object Reference error.

If I replace the call to ExecRemote with a simple sleep(5), then neither button is clickable.

So could this be a problem with PB itself? Or could it be possible that the program called by ExecRemote should be modified / rewritten?

One other trick I tried was to set a database "lock" before calling ExecRemote, then POST the ExecRemote function. In the data currency program, clear that lock once the processing has been completed. In the caller script, wait for that lock to be cleared, sleeping for 1 second between tests.

Unfortunately, the code seems to know I'm trying to get round a problem and will not play the game - it simply locks up. I've tried instance variables, file locks, database locks .... nothing works. Nothing.

Anyone have any ideas?

If you don't know what eschatology is then don't worry; it's not the end of the world.