koobas.hobune.stream
TryParse causing editor/game to freeze
So I'm having an issue with int32.tryparse(string). I'm parsing an xml file and grabbing a field that contains only numeric values. Int32.TryParse() causes the editor or game to freeze. There are no errors that get thrown and the editor isn't listed as unresponsive in the task manager, but it is completely frozen.
The function I'm using is this:
///Converts strings to ints.
private int StringtoInt(String input)
{
int value = 0;
if (Int32.TryParse(input, out value)) { return value; }
else
{
value = -1;
return value;
}
}
This is an example of an xml entry that I'm using. I'm parsing the eventRarity field and I've double checked that all the values are numeric. Just to be extra safe I add a "0" to the begining of any string i pass so that if it's empty it should parse to 0. However, I don't think that should matter because I'm using tryparse which should account for incorrect input.
<event>
<eventName>Trait Gained</eventName>
<eventHeading>A Dog has Developed a New Trait!</eventHeading>
<eventText>A dog had gained a new trait!</eventText>
<eventFunction>AddTrait</eventFunction>
<eventStrength>1</eventStrength>
<eventImage></eventImage>
<eventIcon>TraitGained</eventIcon>
<eventRarity>5</eventRarity>
</event>
So is there somthing that I'm missing? The freeze isn't tied to any particular event entry as far as I can tell. I've seen them all succeed. The crash seems to happen after a random number of times of succeesfully parsing entries. Thanks for any advice.
What makes you think that the problem is in this piece of code?
I wanted to ask the exact same question 9 hours ago (though i would have replaced "What" with "WTH" ^^). Ins$$anonymous$$d i decided to go to bed ^^.
TryParse is part of the $$anonymous$$ono core and certainly (under no circumstances) will never freeze or crash your application. Also since many people seem to confuse a Hang / Freeze with a Crash I just want to emphasise the difference here.
99% of Hangs / Freezes usually comes from an infinite loop somewhere in the user code. In rare cases it might be the result of a bad multithreading implementation which might cause a deadlock. Though in the end a deadlock can also be seen as infinite loop. Recursion without ter$$anonymous$$ation is rarely causes a Freeze. Infinite recursion usually leads to a StackOverflow or an OutOf$$anonymous$$emory exception.
TL;DR : TryParse is to 99.999% not the cause for a freeze so the problem is elsewhere. Since this is the only information we got from the question it can't be answered.
Because if I comment out the tryparse function and simply return a random number the issue disappears. That's actually the reason I put the tryparse in its own function. So that I could make sure the issue was with that and not some infinite loop.
What if you just make it return -1 ins$$anonymous$$d of a random number?
What if you take the number that is being parsed and replace the TryParse with that? That is, Debug.Log(input), copy the value that comes out, comment out the body of the method, and return that from this method.
Have you tried putting Debug.Log calls before and after the TryParse? You can put one before each return call to confirm or refute your belief that TryParse is the problem, here.
It's extremely unlikely that there is any way for TryParse to hang or even for it to take a very long time. If a string is too long (describes a number out of range), it should exit as soon as that is apparent. If a string is too short, same deal. If a string contains bad data, it will also barf.
A far more likely possibility is that one of the values being returned from that method is causing some containing loop to run forever or for long enough to make you think it's running forever.
I am not optimistic about this advice but, trying does not harm anybody. Can you just try this code instead of yours
int i=0;
private int StringtoInt(string input)
{
StartCoroutine(strToint(input));
return i;
}
IEnumerator strToint(string input)
{
int value = 0;
if (int.TryParse(input, out value)) { i = value; return null;}
else
{
value = -1;
i= value;
return null;
}
}
What makes you think that converting to a coroutine will make a difference?
Your code won't compile
You're using
ias soon as you start the coroutine so (if it really were a coroutine) it might not have finished settingiyet.
2 ) maybe , i did not controlled. 3 ) I don't think so 1 ) Just want to be sure that game does not freeze just because that parse process takes too long to complete on main thread.
But if that were the problem, your code wouldn't help, since you're not actually using a coroutine (you neither yield, nor wait for it to complete). And if there's a problem with the parseing then you're unlikely to have fixed it since you're not changing that part of it.
Unfortunately, trying can harm people. I would recommend that the OP disregard this answer and focusses on trying to analyse where the issue actually is.
