Issue-#108 BlackBox Start up warnings

[Josef Templ]

Ivan, you found a work-around for this particular test case but I would not call it a fix
because the same problem may now show up with another module instead of Converters.
As long as we don't understand the root cause of the behavior, this is not fixed.

For somebody able to reproduce the error behavior it should be possible to debug
as I outlined before. The only nontrivial thing is that you need to relink the exe
if you modify any of the linked modules. But this is also simple once
you know that you have to do it.

So I don't understand why we don't make any progress in tracing it down to the root.

- Josef

[Ivan Denisov]

Josef, I did big work by going down to the root however I agree with you. This is not a fix, but was a step for understanding the reasons.
I can say for sure, that Kernel.FatalError working well on Windows XP.
However successful import of HostMenus break message demonstration about fail Converters import.
It is firstly because StdLoader has global variable res.
And also I think, that here should be some timing issue, like it was in build engine with wine.

[Josef Templ]

Josef, I did big work by going down to the root however I agree with you. This is not a fix, but was a step for understanding the reasons.
I can say for sure, that Kernel.FatalError working well on Windows XP.
However successful import of HostMenus break message demonstration about fail Converters import.
It is firstly because StdLoader has global variable res.
And also I think, that here should be some timing issue, like it was in build engine with wine.

Is the behavior different if you insert Kernel.Sleep() before loading or inside Init.Init in your tests?

- Josef

[Ivan Denisov]

Is the behavior different if you insert Kernel.Sleep() before loading or inside Init.Init in your tests?

I am at home already and can not check today. I will try tomorrow if have enough time.

[DGDanforth]

Did you link a new .exe file?
Don't forget to link if you modify any of the linked modules.
Otherwise you would still be using the unmodified module in your test.

I also tested under XP and I always got the same behavior as under Vista and 10.

- Josef

Creating a new .exe file is not possible if one also includes an invalid Converters.ocf.
As I said, the loader complains about the finger print.

The fact that your XP version generates an error might rest on uninitialized global variables
as (I think) Ivan has suggested.

-Doug

[Josef Templ]

So, who can reproduce a bug and under which conditions?
Start with a clean master installation, nothing else.
No Converters linked into exe etc.

Which CPU is being used?
I have Intel only. No AMD.
I am asking this because there is a theoretical possibility that
there are cache consistency problems.

As far as I know, global variables are always initialized to zero.
Only local variables can be uninitialized.
Using global variables (e.g. StdLoader.res) does not lead to nondeterministic behavior,
i.e. if there is a bug there it would also show up in my tests.

- Josef

[DGDanforth]

Please note that

VAR cw: SET; <<<-used before set

Code: Select all

	PROCEDURE InitFpu;	(* COMPILER DEPENDENT *)
		(* could be eliminated, delayed for backward compatibility *)
		VAR cw: SET;	
	BEGIN
		FINIT;
		FSTCW;
		(* denorm, underflow, precision, zero div, overflow masked *)
		(* invalid trapped *)
		(* round to nearest, temp precision *)
		cw := cw - {0..5, 8..11} + {1, 2, 3, 4, 5, 8, 9};
		FLDCW
	END InitFpu;

[Josef Templ]

cw is set in FSTCW

[Robert]

I have Intel only. No AMD.

My test, which showed this problem, used a clean copy of version 450, XP service pack 3, and a twin core AMD chip - 2 years old.

[DGDanforth]

I have started clean again with BBMaster and created an .exe file using

Code: Select all

 DevLinker.Link BBTest.exe := Kernel$+ Files HostFiles StdLoader Math Log Strings Dates Meta Dialog Services Fonts Ports Stores HostPackedFiles Converters Sequencers Models Printers Views Controllers Properties Printing Mechanisms Containers Documents Windows StdCFrames Controls StdDialog StdApi StdCmds StdInterpreter HostRegistry HostFonts HostPorts OleData HostMechanisms HostWindows HostPrinters HostClipboard HostCFrames HostDialog HostCmds HostMenus TextModels TextRulers TextSetters TextViews TextControllers TextMappers StdLog TextCmds FormModels FormViews FormControllers StdFolds StdLinks StdMenuTool HostTextConv StdDebug Init OleStorage OleServer OleClient 1 Applogo.ico 2 Doclogo.ico 3 SFLogo.ico 4 CFLogo.ico 5 DtyLogo.ico 6 folderimg.ico 7 openimg.ico 8 leafimg.ico 1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur

 DevPacker.PackThis BBTest.exe := 
Code/Kernel.ocf

If I place a HALT into Kernel.Init at the following place it traps.

Code: Select all

		IF ~static THEN
HALT(99);
			InitModule(modList);
		IF ~inDll THEN Quit(1) END
		END;
		told := 0; shift := 0;
	END Init;

However if I place the halt after InitModule it does not halt but loads successfully.

Code: Select all

		IF ~static THEN
			InitModule(modList);
HALT(99);
			IF ~inDll THEN Quit(1) END
		END;
		told := 0; shift := 0;
	END Init;

This is over my head. I do not know what is going on.
-Doug