Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

iOS UnityReportWWWReceivedData crash

Discussion in 'iOS and tvOS' started by eczkchtl, Jul 7, 2015.

  1. GilesDMiddleton

    GilesDMiddleton

    Joined:
    Aug 12, 2015
    Posts:
    91
    i hope this is what you're looking for - I'm a bit rusty on how to report iOS/unity crashes. Been about a year since I've had to do this for my last app. Here's a zip file attached with the xccrashpoint files. I'll log a bug now.
     

    Attached Files:

  2. mehmetakgedik

    mehmetakgedik

    Joined:
    Nov 26, 2016
    Posts:
    1
    Does anyone has a solution?
     
  3. teejayF

    teejayF

    Joined:
    Oct 19, 2016
    Posts:
    2
    I'm seeing a pretty big uptick in crashes myself. All with this same stack trace as shown in this image. No code has changed in my system, no deploys. Randomly on the 9th/10th of May, a massive uptick in these crashes, across many games on multiple versions of Unity.

    Has there been a regression in Unity's back end API?
     
  4. teejayF

    teejayF

    Joined:
    Oct 19, 2016
    Posts:
    2
    @christophergoy The above post was directed at you. Was there a deploy on the 9th or 10th that changed Unity's back end?
     
  5. toni_jarvinen

    toni_jarvinen

    Joined:
    Apr 20, 2015
    Posts:
    5
    Same here, A large uptick on crashes related to the WWW::FeedUnityWebStream(bool).
    Started around 9th-11th of May to appear across our apps.
     
  6. oziriz

    oziriz

    Joined:
    Jul 4, 2012
    Posts:
    7
    Any news on this issue? Our app is also reporting some considerable crash numbers on this...
     
  7. christophergoy

    christophergoy

    Joined:
    Sep 16, 2015
    Posts:
    735
    Hey all,
    Sorry for the late response. If you post here, can you include the version of Unity that you are using and also please provide us with a repro project if possible. I also would like to ask that a bug be filed so we can track this issue internally. I have had a pull request ready to backport a fix for WWWConnection that might help you. I am attaching the diff to this post. Let me know if this helps mitigate the crashes. Apply the patch to WWWConnection.mm in the generated xcode project.
    Cheers,
    Chris
     

    Attached Files:

  8. GilesDMiddleton

    GilesDMiddleton

    Joined:
    Aug 12, 2015
    Posts:
    91
    Thanks Chris,

    I haven't changed my app since released - so I could send you that, the problem is that it only crashes in about 3% of startups.
    Given my project doesn't do any web/store access itself, i'm guessing it can be reproduced with a blank project with the same frequency.

    Maybe @oziriz @toni_jarvinen @teejayF @mehmetakgedik can try your fix / provide a better repro?
     
  9. GilesDMiddleton

    GilesDMiddleton

    Joined:
    Aug 12, 2015
    Posts:
    91
    Oh - I did report this issue with the stack trace as requested but it was closed 906309
     
  10. TheJimz

    TheJimz

    Joined:
    Jun 26, 2015
    Posts:
    50
  11. samizzo

    samizzo

    Joined:
    Sep 7, 2011
    Posts:
    487
    I'm on 5.4.3f1 and seeing this on the live build. I'm not even using the WWW class. Was this fixed in a 5.4.3 patch? I've attached the full crash with all threads.
     

    Attached Files:

  12. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I'm getting a crash in the www code as well (version 2017.1.0p3)
    it happens in the WaitOnCondition, specifically the [condition lock] line throws a exc_bad_access exception:

    static void WaitOnCondition(UnityWWWConnectionDelegate* delegate)
    {
    NSCondition *condition = delegate.condition;
    [condition lock];
    [condition wait];
    [condition unlock];
    }

    Unfortunately I don't have a reliable way to recreate it, it just happens sometimes while doing heavy www workloads. I tried adding a nil check for condition (it appears to be nil at the time of crash in the debugger) but it must be getting stomped on from something because it's not nil at assignment but becomes nil afterwards somehow.

    The stack looks like
    WaitOnCondition: 126
    UnitySendWWWConnection: 357
    DoRequest: assembly but line before appears to be UnitySendWWWConnection at WWWConnection.mm:320
    DoRequest: assembly but line before seems to be DoRequest at TransportiPhone.cpp:68
    DoRequest: assembly but line before seems to be DoRequest at TransportiPhone.cpp:133
    Task_DoRequest: assembly but line before seems to be DoRequest() at WebRequestProto.h:404
    Job_ExecuteUnityWebRequest: ~AutoLock at WebRequestProto.h:207
    ExecuteJobFunc
    Exec
    Steal
    ExecuteJobFromQueue
    ProcessJobs
    WorkLoop
    RunThreadWrapper
     
  13. charlesJRG

    charlesJRG

    Joined:
    Jul 18, 2016
    Posts:
    16
  14. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Try modifying SignalConnection() in WWWConnection.mm to not set condition to nil. It should be enough to clear it in cleanup.
     
  15. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    Something seems to depend on that getting set to nil there. If I remove that line in SignalConnection I don't seem to get any downloads.
     
  16. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Are you able to reproduce crash in a small project? If so, can you make a bug report for this?
     
  17. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I decided to create a second version that doesn't nil condition and replace a few of the calls and see if that would work. I ended up replacing it with the non clearing one in this functions:
    connection : line 185 (still crashed after this though)
    UnityShouldCancelWWW : line 412 (still crashed)
    abort : line 147 (haven't seen it crash yet so possibly this is the culprit or a combination of the three)
     
  18. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I haven't found a way to get it to happen reliably yet, if I do though I'll definitely submit one.
     
  19. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    Nevermind still happened, seemed to take longer to happen though. Will replace a few more and test more.
     
  20. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I added it to:
    - (void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error
    : line 247

    And so far hasn't happened again yet, but it did take awhile to happen before. I also determined that the use of it in
    connectionDidFinishLoading
    Is where it apparently needs it to be set to nil, which is the only place now that I don't have it not setting to nil.
     
  21. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    Well it broke even with everything except connectionDidFinishLoading not setting it to nil, I "think" it happens less often at least now, but it's hard to say for 100% since it's pretty random.
     
  22. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I managed to create a small project to reproduce it, I submitted it in case 944462.

    There's a button to press that basically starts 100 www texture downloads each frame, and it increments a counter to let you know how many successes/failures you got (mainly just to see that things are happening). If you let that run for a bit with the debugger attached it should fail, for me it usually fails around the 30k mark, sometimes much sooner.
     
  23. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Thanks, we will look into it.
     
  24. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Can you try removing the "nonatomic" flag from the condition property (in UnityWWWConnectionDelegate).
    I've been able to reproduce your issue, unfortunately, since it takes long to repro the case, it will take a while to be sure it is what causes this crash, but currently this is my highest suspect for the reason.
     
  25. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    That's looking like that fixes it for me, I'll let the test run for awhile to be sure but it's running considerably longer than it used to for me without failing.
     
  26. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    So did some more testing and I think that fixes the condition becoming nil crash, but I get I new issue around 80,000 www requests something else seems to break, all the requests start timing out and I get this message in Xcode:
    2017-08-25 22:42:24.633039-0700 ProductName[5275:3891047] 5275: CFNetwork internal error (0xc01a:/BuildRoot/Library/Caches/com.apple.xbs/Sources/CFNetwork/CFNetwork-811.5.4/Loading/URLConnectionClient.cpp:528)

    I tried switching to UnityWebRequest to see if that had similar behavior, and it's a little different but around 80,000-150,000 requests it stops working as well, although it doesn't time out it just stops returning data. No error in Xcode is shown with it.
     
  27. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    I've refined the test project some, and made it use a local file as the target of web request (so you're internet/network doesn't really matter). Also runs a bit faster, ~3000 requests per second on an iPhone 7 or iPad 10.5 pro, so you only have to wait about 30s to a minute for it to fail. Since this seems like a different issue I'll submit a new report with the changes to the test project.
     
  28. z000z

    z000z

    Joined:
    Dec 31, 2014
    Posts:
    96
    The updated project should be in case #945531
     
  29. monkimunDev2

    monkimunDev2

    Joined:
    Mar 27, 2017
    Posts:
    1
    Hi there, any news about this? We are having a lot of crashes in Unity 5.6.2p3, so please any information about this is good for us.

    christophergoy If you need any additional data or logs we can send you them via private message or other messaging program.
     
    Last edited: Aug 30, 2017
  30. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    See few above post. Setting condition property to be atomic seems to fix the issue. We'll ship the fix, but that is something you can easily fix in your project without having to upgrade.
     
  31. sandeepsmartest

    sandeepsmartest

    Joined:
    Nov 7, 2012
    Posts:
    138
    still we could see the issue coming even after changing
    nonatomic to atomic in WWWConnection.mm.
     
  32. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Try changing everything in there to atomic. I think we released updates with few more such changes.
     
  33. sandeepsmartest

    sandeepsmartest

    Joined:
    Nov 7, 2012
    Posts:
    138
    Changed all nonatomic to atomic but no luck. issue exists in the latest version of unity i.e., 2017.2.1.f1
     
  34. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Do you have a stack trace?
     
  35. sandeepsmartest

    sandeepsmartest

    Joined:
    Nov 7, 2012
    Posts:
    138
    This had happened when I press cancel button.I used Unity's asset bundle package to download asset bundles.Unity's version is 2017.2.1.f1.
     

    Attached Files:

  36. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,722
    Oh, this is a known bug, still being worked on. Yes, that is a specific issue with aborting asset bundle download, has nothing to do with other issues mentioned in this thread.
     
  37. CapitalGames

    CapitalGames

    Joined:
    Sep 10, 2014
    Posts:
    2
    FWIW: We ran into this same issue with both WWW & UnityWebRequests - though a lot less often on the latter.

    The way we resolved it was to hold off destroying the request object until the done property is true. In the case of UnityWebRequests, we call the abort function immediately then monitor for done in a coroutine/update tick etc.