GPS code/module/library leaking memory before 'satellite lock' occurs

Thanks folks for your feedback and info.

@user6350 - Thank you so much for providing this awesome code-base! I'll definitely leverage what I can from that once I start working on the actual GPS project again. (Right now I'm kind of obsessed with understanding what is causing this leak.)

@Gordon - I'll help out however I can to track down this memory leak, as it might effect other modules and users as well.

I have limited time today, but I was able to log the direct serial output of the GPS before and after 'lock', so we can examine the data-stream.

Here's a sample from the data-stream, before GPS-lock

$GPRMC,235948.318,V,,,,,0.00,0.00,050180­,,,N*4A
$GPVTG,0.00,T,,M,0.00,N,0.00,K,N*32
$GPGGA,235949.318,,,,,0,0,,,M,,M,,*42
$GPGSA,A,1,,,,,,,,,,,,,,,*1E

Here's a sample from the data-stream, after GPS-lock (Note: the checksum bytes won't be accurate, as I've anonymized the location data.)

$GPGGA,044236.000,4807.0380,N,01131.000,­W,1,8,0.97,545.4,M,-46.9,M,,*65
$GPGSA,A,3,21,29,25,05,26,15,18,12,,,,,1­.35,0.97,0.94*06
$GPRMC,044237.000,A,4807.0380,N,01131.00­0,W,0.06,545.4,160614,,,A*76
$GPVTG,327.20,T,,M,0.06,N,0.11,K,A*3F

I manually executed some of the library definitions with pre-lock data. Note: I have a similar output generated with post-lock data, but since it executes as expected, i'm not sure it adds any value. I can post it if anyone thinks it will help.

var line = "$GPGGA,235952.319,,,,,0,0,,,M,,M,,*49"
="$GPGGA,235952.319,,,,,0,0,,,M,,M,,*49"­
var d = line.split(",")
=[
	  "$GPGGA",
	  "235952.319",
	  "",
	  "",
	  "",
	  "",
	  "0",
	  "0",
	  "",
	  "",
	  "M",
	  "",
	  "M",
	  "",
	  "*49"
	]
var dlat = d[2].indexOf(".");
=-1
var lat = (parseInt(d[2].substr(0,dlat-2),10)+pars­eFloat(d[2].substr(dlat-2))/60)*(d[3]=="­S"?-1:1);
=NaN

I'm wondering if there could be a leak caused by one of the string parsing functions used to calculate the latitude, longitude, fix, satellite, or altitude vars, when using a '-1' parameter and/or when the result is "NaN". Since these functions execute several times a second, even a small leak would become significant very quickly.

Alternatively, could this be some sort of buffer overflow with the Serial Port? I've verified that my module is running at 9600 baud, so I don'd see how this is possible.

I have the following tests planned for tomorrow:

1. I'll switch the code to using your library as a local function as you suggested.
   
2. I'll comment out sections of the code and try to create the smallest piece of code that still exhibits this problem.
   
3. I'll remove the GPS & Serial functions entirely, and make a function that uses the parsing functions (as defined in the library) to parse our pre-defined sample data taken from the pre-lock GPS capture. Then set this function to execute once a second, and monitor the memory usage.
   
   

I believe these steps should help us determine the root cause of the leak. Are there other test that I should try?

Are there other additional environment settings that I should capture in addition to process.memory() and trace() ?