Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hard Crash when trying to Set/Update data which is > 64 KB, error 0xC0000005 #517

Closed
DDR12 opened this issue Nov 22, 2019 · 6 comments
Closed

Hard Crash when trying to Set/Update data which is > 64 KB, error 0xC0000005 #517

DDR12 opened this issue Nov 22, 2019 · 6 comments
Assignees
@DellaBitta
Labels
api: database type: bug
Milestone
7.2.0

Comments

@DDR12
Copy link

DDR12 commented Nov 22, 2019 •
edited

Please fill in the following fields:

Unity editor version: 2019.1.1f1 and 2019.2.8f1
Firebase Unity SDK version: 6.6.0 and 6.7.0
Firebase plugins in use : Auth and Database.
Additional SDKs you are using : None.
Platform you are using the Unity editor on : Windows.
Platform you are targeting : Desktop
Scripting Runtime (Mono, and/or IL2CPP): Reproduced on Both

Please describe the issue here:

  1. Download the minimal reproducible sample from here: https://drive.google.com/open?id=1CeZprgFZz_dVhz2gLSytn6R-u2NWxNfG

  2. Import the FirebaseDatabase package for sdk version 6.6.0 or 6.7.0.

  3. Open the scene 'SampleScene' in _Scenes folder.

  4. Run in editor, in the input field input any number below 65500 and press upload, this will create a string of length whatever number you input and upload it, i.e creates a sample data of size x bytes.

  5. The upload should be success or an error if failed for some reason.

  6. Now edit the data size in the input field for any value above 65600 bytes and press upload, and experience a hard editor crash, guaranteed 100 % every time you try to push data > 65500 size.

  7. Open the dump files for the crash and you should see this error:
    0xC0000005
    The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

Thanks!

Please answer the following, if applicable:

Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? Didn't test.

What's the issue repro rate? 100 %
@DDR12 DDR12 added the new New issue. label Nov 22, 2019
@muflub
Copy link

muflub commented Nov 25, 2019 •
edited

Hi @DDR12,

Thanks for the bug report. From what I can tell it looks like you are exceeding the max websocket frame size supported by Firebase Database and causing the server to disconnecting the client at an unexpected time causing the client to hard crash.

Ive filed a bug internally to look into a proper fix for this but in the mean time you will need to add some logic to check for this case.

@DDR12
Copy link
Author

DDR12 commented Nov 25, 2019 •
edited

Hi, thanks for your response and time!
Its not a max issue with firebase databse, it is a problem with the unity SDK, to prove that,

  1. I uploaded data > 64 KB to the database from the firebase console and I was able to download it from the unity client.

  2. I've also been able to upload data through the REST API, I simply created 2 extension methods to upload data using the REST API and I can upload data at any size.

For anyone having same problem

   ```
    public static Task SetRawJsonValueAsync_REST(this DatabaseReference reference, string json)
    {
        return FirebaseDatabaseREST.Instance.SetValue(GetRESTLink(reference), json);
    }

    public static Task SetValueAsync_REST(this DatabaseReference reference, object value)
    {
        return SetRawJsonValueAsync_REST(reference, JsonConvert.SerializeObject(value));
    }

    private static string GetRESTLink(this DatabaseReference reference)
    {
        string databasePath = reference.Database.App.Options.DatabaseUrl.AbsoluteUri;
        return $"{databasePath}{GetFullPath(reference)}.json";
    }

    public static string GetFullPath(this DatabaseReference reference)
    {
        List<string> keys = new List<string>(4);
        while(reference != null)
        {
            keys.Add(reference.Key);
            reference = reference.Parent;
        }
        keys.Reverse();
        return string.Join("/", keys).TrimStart('/');
    }


Now instead of using the SDK's `DatabaseReference.SetValueAsync,` use `DatabaseReference.SetValueAsync_REST`, and uploaded data at any size without crashes.

In the 2 Extension Methods `SetValueAsync_REST` and `SetRawJsonValueAsync_REST`, I'm using a dedicated class to send HTTP requests, that I can't share because the project is private, but you can use unity's `UnityWebRequest `or plugins like `BESTHTTP`.

@muflub
Copy link

muflub commented Nov 25, 2019 •
edited

Looking more into it, seems to be related to the rate of data transfer rather than the size. Putting break points in debug code allows the set to complete. The team is still investigating.

@stewartmiles stewartmiles added type: bug and removed new New issue. labels Dec 2, 2019
@Adnimistrator
Copy link

@muflub Is there any progress on this issue?

@chkuang-g chkuang-g mentioned this issue May 30, 2020
Closed
@Adnimistrator
Copy link

It's been a year since this bug is present. @stewartmiles Do you still work on firebase? I can remember you could fix this kind of bugs in a hours when firebase was on its start. Why does it take such a long time now?

@DellaBitta DellaBitta self-assigned this Mar 26, 2021
@DellaBitta DellaBitta added this to the 7.2.0 milestone Mar 26, 2021
@DellaBitta
Copy link
Contributor

A fix for this issue will be in the next milesone release (7.2.0). I'm closing this issue for now, but please re-open it if the problem ensues.

@firebase firebase locked and limited conversation to collaborators Apr 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@DellaBitta DellaBitta

Labels
api: database type: bug
Projects
None yet
Milestone
7.2.0
Development

No branches or pull requests
6 participants
@muflub @stewartmiles @DDR12 @DellaBitta @Adnimistrator @chkuang-g