Page 1 of 1
Works in VM but crashes in VMD
Posted: Wed May 18, 2022 10:00 am
by ColinP
I've just spent many hours trying to find out why my new GetStateInformation() code causes the VMD test client to crash on exiting.
I triple checked the code, used the debugger to trace everything, wrote diagnostic code and used sandboxing to test it and everything looks totally OK.
No exceptions occur and as far as I can tell my code and the sister SetStateInformation() code work exactly to spec.
Yet in VMD it crashes.
I've seen weird stuff happen in VMD before so I finally published the module and tested it in VM proper. And surprise, surprise it works perfectly.
Has anyone else had similar issues and figured out what's different in the VMD client compared with VM in regard to GetStateInformation()?
Re: Works in VM but crashes in VMD
Posted: Wed May 18, 2022 1:02 pm
by UrbanCyborg
That's a switch. Code generally works in the debugger and fails in real life.
Re: Works in VM but crashes in VMD
Posted: Wed May 18, 2022 5:02 pm
by ColinP
After hours and hours of testing I've managed to figure it out.
VMD is not crashing it's just going to sleep for a very very long time.
For reasons that defy logic the test client handles data transfer in SetStateInformation() and GetStateInformation() at an absolute snail's pace.
I eventually ended up with this test case...
Nothing at all in SetStateInformation()...
Code: Select all
@Override
public void SetStateInformation(byte[] stateInfo)
{
// add your own code here
}
...and just allocating 1 kB in GetStateInformation()...
Code: Select all
@Override
public byte[] GetStateInformation()
{
// add your own code here
return new byte[ 1 * 1024 ];
}
This runs fine.
I then changed it to allocating 1 MB...
Code: Select all
@Override
public byte[] GetStateInformation()
{
// add your own code here
return new byte[ 1024 * 1024 ];
}
and it goes to sleep for 55 seconds on exit.
Then on reloading it displays a blank window for another 55 seconds then wakes up.
As I'm trying to make sample data in the region of a couple of MB persist it looked like it was crashing.
My guess is that CA's code in VMD is doing something crazy like opening a file, seeking, reading one byte and closing the file over a million times.
But the code in VM is written properly so works fine.
It never occurred to me that this was what was going on as I had assumed that other developers including CA themselves would have encountered this problem already.
It's easy to reproduce by just changing a single line in a dummy new project.
Re: Works in VM but crashes in VMD
Posted: Wed May 18, 2022 5:13 pm
by seal58
VMD uses to fail time by time. Sometimes debugger window stays empty. Sometimes Debugger hangs up, when I go through the code step by step.
CA already knows about that issues. I sent them a projekt and it's log file for diagnostic.
Because of GUI issues I often had to test new modules in VM. Therefore I added several text fields in order to monitor internal values.
When your project issue is reproduceable, it might be a good idea to sent it and the VMD log file to CA support team.
On my view, many problems happen in VMD because debugger child process needs a rather big amount of run time. It is remarkable, that operation speed of a project in VMD is much less than in VM. That could be a reason of many issues. And it is getting worse, when many Log() statements are used.
Re: Works in VM but crashes in VMD
Posted: Wed May 18, 2022 5:40 pm
by ColinP
Hi Roland,
Yeah, VMD has a few quirks but I've learnt how to work around most of them.
I've emailed CA about this.
It happens when using VMD in "Run without Debugger" mode so there's no Log() calls or anything. You should be able to reproduce the problem just by replacing return null with return new byte[ 1024 * 1024 ] in GetStateInformation() in a brand new empty project.
Re: Works in VM but crashes in VMD
Posted: Thu May 19, 2022 6:44 am
by seal58
Hi Colin,
that's interesting. Thx for info.
Re: Works in VM but crashes in VMD
Posted: Thu Jun 02, 2022 5:52 pm
by ColinP
UPDATE:
CA have kindly been in touch to say that they've fixed this problem and the long delays will go away in the next update to VMD.
It was apparently caused by limitations in how Mac pipes work so the data passing between VMD and the shell was having to be broken up into tiny pieces. They've rewritten it to transfer large data via a temporary file so it'll be nice and snappy in future rather than looking like it's crashed.
