This is really odd. I’ll investigate further. So what happened is when testing your testcase i found a bug in the Debug profile. However when I now compile everything as release I get your error.
I think I have it now. at least, it works here both debug and release. Can you try latest again?
Hmm. it didn’t here for us. Sure we’re still looking at the same testcase?
(above screenshot is from Carlo yesterday; I’ll also install latest in my Windows VM now and will retest…
I downloaded the latest hotfix (that comes with Water build) - and recompiled all the dependencies of the TensorFlow Island project, then recompiled the EUnit test project, and… everything seems work now!
Thank you very much.
P.S. Sometimes the hotfix comes with Water build, sometimes not. Is there any rule for Water build with hotfix?? Just curious
Cool, glad to hear!
Building with Water (which is its own git repository) comes with two downsides: (a) it takes longer and (b) because Windows file locking is stupid, it causes the next build to fail.
For that reason, our regular CI builds do not include Water, only those where we explicitly trigger a build to include it do (similar, regular Ci build
setup.exe's are compressed less (again, speed), and missing some other build artifacts as well, that we only request for the official weekly build.
That said: our setup has a hack, in that if you upgrade a Water-less build on top of an existing build with Water that has the same build number, it will not remove the old Water, and chanced are 99% (unless we changed the signature of some core compiler or EBuild API that Water uses), that the old Water will work seamlessly with the (slightly) newer compiler.
SO you can, say, install a build with Water form today, and than update to one w/o from tomorrow, as they are both .2612. But if you then update to one next week, it’ll delete Water .2612 (or .2613), because the new build will be .2614, and the binaries would not load successfully.
Weirdly - the TensorFlow test project now “randomly” has the following error:
error code 0xc00000fd = stack overflow
Sometimes it happens, sometimes it not - the same compiled executable (Island Windows, EUnit test project)…
Any thoughts? I cannot make a demo project to event replicate this. It appears randomly happening.
your project SO’s when run, or the compiler when compiling it? The former — I’d have no clue short of seeing the code; the latter would sound like a compiler bug.
It is when running the Island/Windows EUnit project (which used to run fine I didn’t modify anything since last year, only upgrading Elements). Not Linux.
It happens randomly (or at least I haven’t find the pattern yet). Simply launch the exe - sometimes it gives stack overflow error sometimes not.
Here is the test-project link Island-test.7z
I am using the latest Elements 2613 / Island/Windows/Visual Studio 2019.
Do you get any (usable) stack trace for the Stack Overflow? For all we know, it may well be “valid”, and a bug in the project pr the library you are using…
It seemed the stack traces to two test methods where const string is involved