On Aug 20, 1:46 pm, phil oakleaf <n...@oakleafsoftware.co.uk> wrote:
Goran wrote:
On Aug 20, 12:55 pm, phil oakleaf <n...@oakleafsoftware.co.uk> wrote:
here's a very simple example
room=NULL;
room->fillWithColour(tPort);
tPort is a class wrapper around CDC
I would expect this to crash. On my 64bit system there is no error
message, no crash. The only effect is that from then on no drawing
appears on the screen. It's as if this call with "this=NULL" does some
corruption but does not crash as I would expect.
On my 32bit machine this causes the expected "Unhandled exception at...."
Any ideas?
Phil
That's not saying much. If fillWithColor isn't virtual and doesn't use
any data members of the corresponding class (let's call it <T>), and
your tPort is fine, that will live. Where exactly do you get an
exception? I'd bet that for one reason or another, on a 64-bit system
doesn't pass through there, or at least pass with different program
state.
AFAIK from my own bugs, and on 64-bit windows as well, as soon as
<T>::fillWithColour() touches any data member of <T>, that will die
with an AV.
Provide a working example of something crashing under Win32/not
crashing under Win64, otherwise whatever you expect is based on bad
analysis (I bet on that for the moment :-) ).
Goran.
fillWithColour is a virtual method that does a lot with 'room'
my question is:
What should this run (with corruption) on 64bit but not on 32bit
I guess you meant "__Why__ should this run..."? It shouldn't, and I am
pretty sure that you aren't seeing what you think you are seeing.
virtual call on a NULL object __will__ fail. As an example, I just
tried this on my machine (64-bit OS):
class CPhilOakley : public CObject
{
public: virtual void Virtual() { std::cout << "Never here"; }
};
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(),
0))
return 1;
CPhilOakley* p = NULL;
if (!argc) p = new CPhilOakley; // Don't let optimizer optimize
stuff away.
p->Virtual(); // Obligatory crash here.
return 0;
}
This crashes with a clear AV when trying to load virtual table pointer
off of NULL "this".
If 64bit allows this but it crashes on 32bit then it appears pretty
risky to develop on 64bit and supply 32bit.
So far, your issue has __absolutely__ nothing with 64-bit windows. And
your argument is deeply flawed (I am reading it as follows: because
program __with bugs__ (e.g. bad pointers) doesn't crash under 64-bit,
64 bit is not worth using; I mean, seriously, WTF!?).
I can understand that you want to find bugs as quickly as possible,
but in doing so you are relying on __sheer luck__. It just so happens
that UD you invoked under 32-bit system __sometimes__ crashes. It is
not reliable __at all__ and bears no rational relevance.
Goran.