convbin segfault in expath() at rtkcmn.c:2945 on MacOS 10.8.5

[cycloid]

When compiled for MacOS 10.8.5, convbin segfaults in routine expath() [rtkcmn.c:2945]

This bug first appeared after the rtklib_4.2.2_p10 commit.

mojo:pct-2014 jeff$ gdb ~/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin12.5.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/jeff/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin...done.
(gdb) run -ts "2014/01/01" -od -os -oi -ol -d rinex ubx/06-00031.ubx
Starting program: /Users/jeff/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin -ts "2014/01/01" -od -os -oi -ol -d rinex ubx/06-00031.ubx

Program received signal SIGSEGV, Segmentation fault.
0x00007fff88949557 in strstr () from /usr/lib/system/libsystem_c.dylib
(gdb) bt
#0  0x00007fff88949557 in strstr () from /usr/lib/system/libsystem_c.dylib
#1  0x0000000100012872 in expath (path=0x7fff5fbffbce "ubx/06-00031.ubx", paths=0x7fff5fbfe968, nmax=1) at ../../../src/rtkcmn.c:2945
#2  0x0000000100003654 in cmdopts (argc=10, argv=0x7fff5fbff9c0, opt=0x7fff5fbfeb40, ifile=0x7fff5fbfeb28, ofile=0x7fff5fbfeaf0,
    dir=0x7fff5fbfeae8, trace=0x7fff5fbfeb38) at ../convbin.c:441
#3  0x000000010000119e in main (argc=10, argv=0x7fff5fbff9c0) at ../convbin.c:467
(gdb) up
#1  0x0000000100012872 in expath (path=0x7fff5fbffbce "ubx/06-00031.ubx", paths=0x7fff5fbfe968, nmax=1) at ../../../src/rtkcmn.c:2945
2945                if ((p=strstr(p,q))) p+=strlen(q); else break;
(gdb) l
2940            sprintf(s2,"^%s$",file);
2941            for (p=s1;*p;p++) *p=(char)tolower((int)*p);
2942            for (p=s2;*p;p++) *p=(char)tolower((int)*p);
2943
2944            for (p=s1,q=strtok_r(s2,"*",&r);q;q=strtok_r(NULL,"*",&r)) {
2945                if ((p=strstr(p,q))) p+=strlen(q); else break;
2946            }
2947            if (p&&n<nmax) sprintf(paths[n++],"%s%s",dir,d->d_name);
2948        }
2949        closedir(dp);
(gdb) print s2
$1 = "^06-00031.ubx$", '\000' <repeats 690 times>...
(gdb) print p
$2 = 0x7fff5fbfd370 "^01-00028.ubx$"
(gdb) print s1
$3 = "^01-00028.ubx$", '\000' <repeats 43 times>, "`\221\205\377\177", '\000' <repeats 630 times>...
(gdb) print q
$4 = 0x5fbfcf70 <Address 0x5fbfcf70 out of bounds>
(gdb) print r
$5 = 0x0

[tomojitakasu]

The code itself might be fine. It seems just to use strtok_r() correctly. I have no experience to use strtok_r() on MacOSX. Please check the strtok_r() implementation on MacOSX.

[cycloid]

On MacOS X the strtok_r() function requires POSIX C language level of at least 199506.

In /usr/include/string.h:

/* Additional functionality provided by:
 * POSIX.1c-1995,
 * POSIX.1i-1995,
 * and the omnibus ISO/IEC 9945-1: 1996
 */

#if __DARWIN_C_LEVEL >= 199506L
__BEGIN_DECLS
char    *strtok_r(char *, const char *, char **);
__END_DECLS
#endif /* __DARWIN_C_LEVEL >= 199506L */

Changing line 106 of rtkcmn.c to:

#define _POSIX_C_SOURCE 199506

fixes this bug. I couldn't find any indications of whether the explicit POSIX language level required for rtkcmn.c was a minimum or maximum version constraint, so I can't say whether this breaks anything else. The file compiles cleanly on MacOS 10.8.5 and Debian 3.2.54.

[tomojitakasu]

Thanks. It is fixed in rtklib 2.4.3 b17.