Ticket Created
over 5 years ago

WERETECH-7626

System error with makeWebRequest() if using an array in the request parameters

July 20, 2019 update.  Found out that I was passing an array into the Parameters dictionary as one of the fields.  Depending on the version of GCM, this can create very unpredictable results on a real device.  The the results of passing the array ranged from a IQ! crash, to no parameters being passed to the web service.  The fix was pretty simple, format the output of the array and pass the resulting string into the Parameters 

-------

In preparations for a planned update to my app and potential transition to a trial/paid app, I started to implement some usage statistics to get a better idea on which devices are most popular and a better idea on daily usage rates to determine which tier of service I will need once I make the switch to a paid version of the app.  After the update I got a report from a Edge 830 user who experienced an IQ! crash.  They sent me the CIQ_LOG.YML file and I was able to trace the crash back to the makeWebRequest().  Since I had not played with the ERA tool yet, I decided to use this opportunity to check it out.  I do have to say great job with the tool.  It is nice to be able to see the number of times and which devices experience the same crash.  Below is the ERA output for the crash

Error Name: System Error
Occurrences: 50
First Occurrence: 2019-07-15
Last Occurrence: 2019-07-18
Devices:
Edge® 1030
vívoactive® 3 Music
Edge® 530
Edge® 830
006-B3163-00
Device Firmware Versions: 3.50, 3.80, 4.20, 4.50, 7.50
App Version: 3.12
Languages: cht, deu, eng, fre, jpn, pol, spa
Backtrace:
Rez.MainLayout:43
auth.RadarInst:42
WUradarApp.onStart:28

WUradarApp line 28 is the link to run Auth.RadarInst.

Below is line 42 in Auth.RadarInst.

After doing some troubleshooting with the user, I know he is using an Iphone 6s.  Disabling the BT connection will allow the app to run, but since the stats upload and image request both use the Internet, it is not much help.  Un-installing the app and reinstalling did not make an difference, nor did un-pairing and repairing the phone.  I thought that may reset something that got corrupted in the BT link either with the edge or the Iphone.  based on the ERA, I am seeing this on 5 different device types but only a small number of times considering the number of downloads I have seen in the past few days.

It does not appear to be code related as there are other Edge 830 users not affected, but I don't know what phone they are using or if there is something going on with the phone side of the makeWebRequest.  Any suggestions are welcome.

sabeard
Parents
  • over 5 years ago

    Is your app getting a bit tight on memory?

    One thing to note with ERA/the Crash Log viewer, is that it seems you only see the logs for the current version. 

    So, it's hard to say when this started happening for you.  It could have been the last X versions, but you only are seeing there were 50 occurrences in the current version.

    In my case, I did see some crash logs that were a bit of a surprise to me (nothing in reviews or "contact developer") but again, only for the current version, and I knew a few things I fixed had been there since I first wrote the app. So, it many be something with your new code, or it may have been there for some time.

Comment
  • over 5 years ago

    Is your app getting a bit tight on memory?

    One thing to note with ERA/the Crash Log viewer, is that it seems you only see the logs for the current version. 

    So, it's hard to say when this started happening for you.  It could have been the last X versions, but you only are seeing there were 50 occurrences in the current version.

    In my case, I did see some crash logs that were a bit of a surprise to me (nothing in reviews or "contact developer") but again, only for the current version, and I knew a few things I fixed had been there since I first wrote the app. So, it many be something with your new code, or it may have been there for some time.

Children
  • over 5 years ago in reply to sabeard

    After two days of the new version of my app rolling out to users, I am slowly starting to see the blank logs go away.  I have also been able to confirm with the Edge 830 users that the new build no longer causes a crash.  So the lesson I learned is that make sure to not use any arrays or nulls in web request parameters.  Always use a string or a variant of a number when creating the web request parameters.

  • over 5 years ago in reply to jim_m_58

    Memory use does not seem to be an issue.  The code location is definitely something I just added.  I think I may have stumbled onto part of my problem last night.  I decided to look more closely at he parameters I was passing to makeWebResuest.  

    I was passing the array from monkeyversion unfiltered into makewebrequest. In the simulator this worked fine and the result was readable, so I did not think to much of it.  Once I released the version to the store, I started seeing two things.  The array came through with a bunch of extra characters, and I was seeing a large number of request with none of the parameters being passed to the web server.  I thought this was an issue with how I was passing the info into the function so I added checks to set a specific value if the parameters were blank.  I was still seeing almost 80% of my web server queries come in with blank parameters.  Last night I decided to fix my visual problem and turn the array into a formatted string.  I will need to wait until the new build gets broader deployment to see if this is a fix to my issues.

    If the overnight logs are any indication, I am seeing fewer indications of missing parameter on the web server.  So it could be that the passing an array in the parameters caused on of two issues depending on the phone/GCM version being used.  The app would crash, or the web request would go through but none of the parameters were passed similar to the null in a single parameter bug previously reported.  I will keep monitoring the ERA, and my log to see if things are improving.