1

I'm trying to set up Firebase's new crash reporting via their docs and running into an error. When I build the project I get this error from the run script phase:

Pods/FirebaseCrash/upload-sym-util.bash:384: error: symbolFileMappings:upsert: Request contains an invalid argument.

After debugging a bit I found the VERBOSE flag and set that for more info as seen below (keys removed)

/Pods/FirebaseCrash/upload-sym-util.bash:376: note: another thing == Info: Trying 216.58.216.47... == Info: Connected to mobilecrashreporting.googleapis.com (216.58.216.47) port 443 (#0) == Info: TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 == Info: Server certificate: *.googleapis.com == Info: Server certificate: Google Internet Authority G2 == Info: Server certificate: GeoTrust Global CA => Send header, 413 bytes (0x19d) 0000: POST /v1/apps/1:000000000000:ios:0000000000000000/symbolFileMapp 0040: ings:upsert?key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HTTP/1.1 0082: Host: mobilecrashreporting.googleapis.com 00ad: User-Agent: curl/7.43.0 00c6: Accept: */* 00d3: Content-Type: application/json 00f3: X-Ios-Bundle-Identifier: com.jakecraige.Inventry 0125: Authorization: Bearer XXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0165: XXXXXXXXXXXXXXXXXXXXXXXXXXX-XXX 0186: Content-Length: 186 019b: => Send data, 186 bytes (0xba) 0000: {"upload_key":"1:000000000000:ios:0000000000000000-00000000-0000 0040: -0000-0000-000000000000","symbol_file_mapping":{"symbol_type":2, 0080: "app_version":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}} == Info: upload completely sent off: 186 out of 186 bytes <= Recv header, 26 bytes (0x1a) 0000: HTTP/1.1 400 Bad Request <= Recv header, 16 bytes (0x10) 0000: Vary: X-Origin <= Recv header, 15 bytes (0xf) 0000: Vary: Referer <= Recv header, 47 bytes (0x2f) 0000: Content-Type: application/json; charset=UTF-8 <= Recv header, 37 bytes (0x25) 0000: Date: Mon, 30 May 2016 21:47:10 GMT <= Recv header, 13 bytes (0xd) 0000: Server: ESF <= Recv header, 24 bytes (0x18) 0000: Cache-Control: private <= Recv header, 33 bytes (0x21) 0000: X-XSS-Protection: 1; mode=block <= Recv header, 29 bytes (0x1d) 0000: X-Frame-Options: SAMEORIGIN <= Recv header, 33 bytes (0x21) 0000: X-Content-Type-Options: nosniff <= Recv header, 30 bytes (0x1e) 0000: Alternate-Protocol: 443:quic <= Recv header, 69 bytes (0x45) 0000: Alt-Svc: quic=":443"; ma=2592000; v="34,33,32,31,30,29,28,27,26, 0040: 25" <= Recv header, 21 bytes (0x15) 0000: Accept-Ranges: none <= Recv header, 30 bytes (0x1e) 0000: Vary: Origin,Accept-Encoding <= Recv header, 28 bytes (0x1c) 0000: Transfer-Encoding: chunked <= Recv header, 2 bytes (0x2) 0000: <= Recv data, 138 bytes (0x8a) 0000: 7f 0004: {. "error": {. "code": 400,. "message": "Request contains 0044: an invalid argument.",. "status": "INVALID_ARGUMENT". }.}. 0085: 0 0088: == Info: Connection #0 to host mobilecrashreporting.googleapis.com left intact /Pods/FirebaseCrash/upload-sym-util.bash:385: note: symbolFileMappings:upsert: The metadata for the symbol file failed to update.

So it looks like the POST to mobilecrashreporting.googleapis.com/v1/apps/$GOOGLE_APP_ID/symbolFileMappings:upsert?key=$FIREBASE_API_KEY is failing.

Looking through all the params, they seem to match up with my config and nothing is empty, so I'm not really sure what to do next.

Has anyone else run into this? Idea on how to fix it?

Thanks!

Improve this question

1 Answer 1

Reset to default
1

In the build report, when running on verbose=3 ('-vvv'), did you see something like the following lines?

CrashTestApp (architecture x86_64) symbol dump follows (first 20 lines): MODULE mac x86_64 5FFC1B5C32CF33EEB4BFFA4189412AE30 CrashTestApp FILE 0 /Applications/Xcode.app/… ⋮ FILE 4 /Users/me/Source/CrashTestApp/… FUNC 1bf0 54 0 -[ViewController viewDidLoad] 1bf0 14 11 4 1c04 30 12 4 ⋮

(The numbers and file names will obviously be different.) The key is the magic pattern in the first line: it must start with MODULE followed by the machine type and architecture (single words) followed by a 33 digit hex string, then the name of the app. If the file upload does not follow that pattern, then the upsert step fails.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Hey Robert, this is what I'm seeing for that line MODULE mac x86_64 45FA3BDF3866336FACCE04D28744BAF30 Inventry
I'm actually seeing two different strings like that, MODULE mac x86_64 45FA3BDF3866336FACCE04D28744BAF30 Inventry and MODULE mac x86_64 45FA3BDF3866336FACCE04D28744BAF30 Inventry.FILE, perhaps that second one is the culprit? There's something weird going on with newlines there. A bit more context here: gist.github.com/jakecraige/79ac463e7da0e5605bdf502bdd0edf47
@robert-menke I have the same issue, and verified after running on verbose=3 that the MODULE mac stuff was fine. However, it revealed the arguments being passed up for upsert, and one of them, app_version is that's causing the failure. In my case I was doing a debug build, and my debug build version is 3.7-dev (i.e. not all numbers and dots). Changing this to 3.7 makes the upsert request complete successfully. I'd be interested to see if @jakecraige has a similar issue with the app version.
@RizwanSattar That was it! I had a build script that sets the build number to a git commit hash so when I removed that and set to a standard version number it worked.
Sorry about that. The backend team rejects any version that is not in Dewey decimal format (=~ m/^\d+(?:\.\d+)*$/). It's not a valid restriction as the version is only used for labeling, but they felt it was necessary to filter out corrupted uploads.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.