On Mon Apr 21 2014 at 6:38:02 PM, SRE <steve-babel@climber.org> wrote:
At 10:25 AM 4/21/2014, Robert Lipe wrote:
>you may very well be the last person actually using that format

Ahhhrrrrgh! Thanks for not killing it.

It's on life support.  NG formally discontinued it in 2012 after years of neglect. We never had a huge amount of traffic in it, but once they added support for GPX back in 2006, we saw our interest in tpo3 and 4 pretty much fall to zero.

 
>Try gzipping your file and see if the problem goes into remission.

Solved. Amazing! That's a workaround I can live with for now.
I feed xxx.tpo.gz into the GUI and it works just fine.

Bizarre.   This was actually tsteven4's discovery. We have two different formats that show this problem now, but only on Windows.  Other than some wacky altitudes, your example works swimmingly on Mac.
gpsbabel-macrelease robertlipe$ ./gpsbabel -i tpo3 -f ~/Downloads/HuddartPark.tpo 
37.444910N 122.284010W TRAIL1/TRAILHEAD NO PARKING 42916904.000000
37.443140N 122.286010W TRAIL2/TRAILHEAD AT END OF RAYMUNDO 42916904.000000
37.444582N 122.294242W 005/10-NOV-00 17:13 42916904.000000
37.446572N 122.297375W 006/10-NOV-00 17:23 42916904.000000
[ ... ] 
37.443590N 122.268840W RUNYMD/RUNNYMEDE AND CANADA 147.000000
37.449420N 122.278260W RAYMND/RAYMUNDO AT RUNNYMEDE 163.000000
37.448447N 122.285014W NOTE 1/Huddart

It appears to be a problem in the shared file-handling code that thinks the file is compressed when it's not.  The common thread is that reads are OK, but seeks blow up.
 
Now... how to debug? Handing GPSBabel uncompressed .tpo files 

I spent probably ten hours chasing it on a recent weekend when we got the first report of it.  Steven then discovered the gzip workaround.  

Staring at the diffs since 1.4.4, here's a gun that smells faintly of smoke:
static gbfile*
gzapi_open(gbfile* self, const char* mode)
{
  char openmode[32];

  self->gzapi = 1;

  /* under non-posix systems files MUST be opened in binary mode */

  strcpy(openmode, mode);
  if (strchr(mode, 'b') == NULL) {
    strncat(openmode, "b", sizeof(openmode) - strlen(openmode) - 1);
  }

In 1.4.4, this was  strncat(openmode, "b", sizeof(openmode));

While I'm still absorbing coffee, and don't see any way that strncat would be taken in the tpo case (the argument is a literal "rb") and I don't see any way that openmode[] wouldn't have space for that one byte, that is the only change I see in gbfile.cc that could explain a Windows-specific behaviour involving text vs. binary files.  Perhaps I lack imagination.

The search space is gbfile.* and zlib.  I pulled zlib 1.2.8 to replace our copy from 1.2.3, but Steven reports that using older zlib made no difference for him.  I really don't think it's in tpo.cc itself since we have two distinctly different formats showing the same problem.  I was thinking it was a file being opened as text instead of binary (windows is the only OS that thinks you want something OTHER than what's actually in the file unless you ask otherwise) but Steve mentioned it may be in the compression detection down in zlib.

Your experience is only the second report we've seen of this, but just based on the description, it's probable that other formats are affected on Windows.

We'd appreciate fresh eyeballs on it, but recognize your deadlock getting a development environment up.