Error R6010 using LoadBalancing

CousCousiere
edited September 2013 in Native
Hi everyone,

I have a trouble and I haven't found any thread talking about it, that's why I ask you.

I have made a program using the LoadBalancing system provided by Photon. The system works fine, the rooms are created correctly, the send / receive system between the clients too, etc. Very good job guys ! But... I still have a trouble.

Sometimes (there is no specific way to reproduce it) I have a crash and the callstack talks about photon, but it must be something on my side.
Because I haven't the source, I cannot debug it. Can anyone from ExitGames take a loo at this callstack and try to help me ?



Thanks by advance !
Chris

Comments

  • Hi Chris.

    Are you accessing stuff from inside the ExitGames namespace from within different threads? If yes, then you will have to use locks, as our C++ client lib isn't threadsafe yet.

    Such multi threaded access can easily lead into memory management issues (one thread allocating or deallocating from/to the same memory pool as another one leads into racing conditions that result in corrupt tracking about the allocated memory and when one of those threads then later tries to deallocate that memory, then that deallocation in the relaese config can happen on the wrong memory address, which would end up in undefined behavior (an immediate and relatively easy to debug crash would be the best case, but with bad luck it could just accidentally deallocate another adress that has also been allocated by your application, but is totally unrelated to the source of the problem or to Photon), while the attempt to do so in the debug configuration triggers the assert, that you see, and that is there, to make sure, that it crashes immediately, so that its easier to debug the issue).

    Because of the nature of racing conditions they happen randomly and are hard to reproduce.
  • Hi Kaiserludi,

    I think that you are right : the LoadBalancing process ( NetworkLogic.service() ) is on a separated thread because I thought that it was threadsafe.
    I did that because, when a game level is loading, the main thread is stuck and there was some troubles with Photon because there was some lost packets and the initialization process of the game was corrupted.

    For now, I store the received Hashtable adress and use it later, so I will copy all the datas and try to see if it's better.

    Thanks a lot !
    Chris
  • Hi Chris.

    For copying the payload of the Hashtable you would have to access the Hashtable, which means "accessing stuff from inside the ExitGames namespace from within a different thread". So that won't necessarily fix the problem.
    However you should be save with accessing it from within that second thread, as long as you can guarantee, that the main thread won't access it until the other thread has finished accessing it.

    About level loading and Photon:
    In that situation it may also make sense to not call service(), but only serviceWithoutDispatching(). That way Photon still keeps the connection alive, but incoming data stays stored in Photons queues and doesn't get passed to your callbacks until your next call to service() or dispatchIncomingCommands().
  • That's right : it didn't fix the problem.
    It happenend just once or twice (far less than before) but it still happens, and honestly I prefer a problem that happens very often (you can reproduce it easily) than a problem that juste happens once or twice a day.

    I will try to put the photon update in the main thread (the only thread that accesses the Hashtables) and use serviceWithoutDispatching, it will correct the problem for now.

    Do you know if there is a plan on your side to make the photon update threadsafe ?

    Thanks for your answer anyway !
    Chris
  • Yes, its on the todo list.
    Hopefully it will happen until the end of the year.
  • Excellent, so I'll wait for it.
    Thanks
    Chris