Looking into the issue of P.Cavallini with gpstrans, the resulting
backtrace with a debugging binary I provided for that is:
Program received signal SIGSEGV, Segmentation fault.
0xa7e07e74 in _IO_default_xsputn () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xa7e07e74 in _IO_default_xsputn () from
/lib/tls/i686/cmov/libc.so.6
#1 0xa7de2143 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#2 0xa7dfd9ab in vsprintf () from /lib/tls/i686/cmov/libc.so.6
#3 0xa7dea21e in sprintf () from /lib/tls/i686/cmov/libc.so.6
#4 0x0804eb7d in getGPSVersion (string=0xaf91cae4) at getgpsinfo.c:340
#5 0x0804f118 in getGPSInfo (refNum=0xa7ed33a0, type=3) at getgpsinfo.c:590
#6 0x0804a641 in main (argc=Cannot access memory at address 0x807b000) at
main.c:439
So AFAIK this seems a silly overflow while the program runs one of the
sprintf() calls in getGPSVersion(). As always, being defensive using
snprintf() with a 255 max size would be appropriate. I suspect anyway
that Paolo's gps has some unexpected response/verbosity and trashes
the buffer. A proper patch would be easy to write down.
IMHO gpstrans code needs major revisions, due to some naive approach
in C programming, anyway...
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
