Standalone player crashes when there's many objects receiving texture

[neozero]

Unity, in a standalone player, randomly crashes when a new program starts sending texture with any name.
It doesn't matter if the object within Unity actually receives the texture (still happens with no matching shared name).
It doesn't happen every time, I must open and close the sending program a few times. Sometimes it happens in the first try, sometimes in the 3rd or 5th or later.

Sometimes, Unity just freezes, and you have to close it in the task manager.
Other times, it show a window blaming nvwgf2umx.dll or ntdll.dll.

After days trying everything I could, it seemed random every time I tried a new approach.
Then I noticed it didn't crash if I enabled the plugin console.
Then, it still crashed if I commented out the every printf call in the dll source, even with the console enabled.
I narrowed it down to the checkReceivers() function.
If at least this function has its printf calls and the console is enabled, Unity doesn't crash.

So I tried to add Sleep(10) to its beginning, compiled it, and that's it, no more crash, even with the console disabled!
I started from 1000ms, and 10ms is good. 1ms didn't help, still crashed.

Here's my code now:

extern "C" void EXPORT_API checkReceivers()
{
    if (sender == nullptr) return;


    int numSenders = sender->GetSenderCount();


    if (numSenders != lastSendersCount)
    {
        // FIX UNITY CRASH!
        Sleep(10);

        printf("Num Senders changed : %i\n", numSenders);

        UnitySenderUpdate(numSenders);

        int i, j;
        bool found;

        printf("Old Sender List :\n");

        etc...

I have no idea what's happening, but that ugly hack did it (and I'm freaking happy now!).
I though reporting this here could help you guys figure out better what's the problem.

I'm using Windows 7 SP1, a GTX 650 Ti with lasted Nvidia drivers, and Unity 4.5.2f1.

[leadedge]

Hi there and also to Ben,

thanks for this and your time and preseverence.

So let me get it clear. I am not sure what you mean by :

"If at least this function has its printf calls and the console is enabled, Unity doesn't crash."

Does this mean that if you enable the console it does not crash even if you don't use the sleep function? Or do you mean that the checkReceivers() function has to have the printf calls and the console open at the same time.

What happens if you comment out the printf calls in this function and leave out the console?

First it seems something to do with the console and "printf" and that is the easiest thing to eliminate. They should all be commented out. I can check the Spout code and make sure no printf calls are left over.

I wonder if it is a thread problem for some reason. Or it could be related to delays for locks for shared memory access.

The console is a bit of a hack but I use it all the time for debugging. Recently I have updated it with :

FILE* pCout; // should really be freed on exit 
AllocConsole();
freopen_s(&pCout, "CONOUT$", "w", stdout); // only printf is used

Cheers,

Lynn Jarvis

[neozero]

Hello! What I meant is that the console and the printf calls prevents Unity from crashing.

Here's what makes it crash:

• Console disabled, with or without commenting out printf calls
• Console enabled but with every printf calls commented out
• Console enabled but with printf calls only inside checkReceivers() commented out

Here's what makes it not crash:

• Console enabled with printf calls enabled
• Console enabled and printf calls only inside checkReceivers() are enabled
• Using Sleep(10) inside checkReceivers(), doesn't matter if the console or printf calls are enabled or disabled

I thought the printf calls being shown in the console could actually be using a little cpu time, and tried to just force some sleep instead, and it worked here.
Printf calls and no console didn't help.
Console and no printf calls didn't help.
Only inside checkReceivers() the printf calls prevented it to crash, and only if the console was enabled.

[leadedge]

OK I can see that this isolates it to that function as you explained before but I didn't quite understand it fully. Sorry for that.

It occurs to me that there is a limit to the number of senders you can have running at once, and that is 10 at the moment. If you exceed that, I think the sender just won't be registered but I am not sure.

Also there probably should be a check for zero senders. Not sure what would happen then.

The fact that it is OK with a delay is the big clue. I will look into what is happening with the memory mapping access which is my first thought, but without the whole thing set up and a repeatable bug to check it is hard to know. I can't do Unity. Maybe Ben might have some idea if he has the time.

Anyway I will keep this one in mind and let's hope the workaround get's you going.

[neozero]

Thanks for looking into it! What didn't you understand?
Just to let you know, this is happening even with only 1 sender.
The problem occurs when there is multiple receivers.

[leadedge]

OK - that means to me the that time taken for access to the memory maps might be a problem. Each receiver has to wait for the other before it can gain access to the sender list, and this includes the Unity program. If this is the problem, then using only 1 receiver wouldn't need any delay or at least it could be reduced. I will need to think about this a bit.

[benkuper]

Hi Lynn, Hi neozero
Sorry for not coming there before, i actually didn't see that there where issues on the github (i don't know why but i don't receive notifications when someone post an issue on my repositories..)
I've been very busy for now and i'm afraid i will still be for few more weeks, but i will get my hands on newer versions of this as soon as i get time for it.