- Home /
Unity3d crashes in batchmode from a null string
Howdy all, I've got an interesting one for you.
I'm working on creating an continuous integration / automated deployment server for our game using Hudson to manage the automation. The way it works is that we have an ant script that hudson will run every hour or so, tell unity to update the project through the asset server, and then start a batchmode build.
However, I'm not even getting that far. It turns out that if I try to launch Unity batchmode (without even doing anything else) from within Hudson, it immediately dies with:
[echo] Building Unity project.
[echo] /Applications/Unity/Unity.app/Contents/MacOS/Unity -batchmode -quit -projectPath /workspace/hudson/jobs/DailyBuild/workspace/project/ -executeMethod BuildEditor.Build
[exec] terminate called after throwing an instance of 'std::logic_error'
[exec] what(): basic_string::_S_construct NULL not valid
Which, after a lot of researching I have come to find means that somebody tried to assign a null to a std::string, and which might have something to do with missing environment parameters that Unity assumes is there.
Every other attempt to isolate the problem by running Unity3d in batchmode succeeds, and calling the ant script directly from outside of hudson also succeeds.
I realize that what I have there might not be enough information straight up to diagnose the problem, so my first question is: what other information do I need to provide to help narrow things down? I'll start with the fact that I'm new to MacOSX, so I've already run afoul permissions problems and will probably do so again.
Thanks!
Details:
Unity Version: 3.30f4
Operating System: MacOSX 1.6.4
Hudson Version: 1.396
Tomcat: 7.0.8
Ant 1.7.1
Answer by EigenPuff · Apr 05, 2011 at 05:42 PM
I let our company IT Ninja bang on it for a bit and it turns out that it's an artifact of running Tomcat/Hudson under launchctl as a Daemon. If we launch the whole thing from a shell instead of as a service, then everything works well.
A theory that our IT Ninja is looking into is that it might be related having no terminal display context to use, but it hasn't been verified yet.