The Bug of the Day

[Ravi Pandya <ravi>]

Well, I've figured out the problem, and it was indeed a subtle interaction
between FluidVars and StrongPtrVars. FluidVar::fluidLValue() gives
back a reference to an SP2_Foo that is actually pointing at a block of
nulled memory in fluidSpace. Because SP2_Foo has a constructor that
takes SP2_Foo reference, that constructor is called as part of the
semantics for parameter passing. This constructor tries to call a
member function of the argument to assign the pointer value, and thus
finds its way into never-never land, since the argument object is all
zeros.

I tried changing this constructor to access the argument's member
variable directly instead of through a member function. It didn't work
because the existence of the constructor still prevented the fluid
from getting initialized with a vtable and stuff. It blew up on the
next line when it tried to assign into the variable. Zero city.

Someone who has a better grasp of the bizarre constructor calling
regime of cfront will have to figure out a solution to this one. I hit
my limit just figuring out what was going on. What I think we need is
some way of ensuring that an arbitrary block of memory in fluidSpace
is properly initialized and constructified into a C++ object. It has
to be simple enough that the FluidVar macros can generate it.

For some reason IntegerVars work OK in FluidVars, I guess because of
the different set of constructors they define.

	--ravi

P.S. If you're interested in looking at an isolated instance of the
problem, check out bugt.exe in "~ravi/image/cxx/febe". This was
generated by runnng bugt.cxx through cpp to produce bugxt.cxx, which I
touched up a bit to break up lines and remove line numbers, then
compiled and linked. This allowed me to follow execution through macro
expansions in a useful way.