Skip to Content.
Sympa Menu

freetds - Re: [freetds] Freebcp coredump

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Freebcp coredump
  • Date: Tue, 9 Dec 2008 10:08:56 -0500

dmarrer AT bci.cl wrote:
>
> The problem is with the path of the format file. If you see params value
>
> in the gdb output, appears the following:
>
> formatfile = "/home/mysystem/fmt"
>
> interfacesfile = "ig.fmt\000\000\000\000\000\000\000\000"
>
> And the value of my format file parameter is /home/mysystem/fmt/
> emp_vig.fmt
>
> If run using the following parameters working properly:
>
> freebcp VW_GETDATA out res_eact.txt -f emp_vig.fmt -S$TDSQUERY -Uuser
> -Ppassword
>
> Do you know why this happens?

http://www.opengroup.org/onlinepubs/000095399/basedefs/stdio.h.html
http://www.delorie.com/gnu/docs/glibc/libc_652.html

I might.

BCPPARAMDATA in freebcp.h defines filenames as arrays of size
FILENAME_MAX+1. What is the value of FILENAME_MAX on HP/UX? Is is less
than the length of your filenames?

If so, we've tripped over a system limit, leading to my second question:
does HP/UX define strlcpy(3) in its standard C library? Because the fix
(assuming the above is correct) is one of two:

1. redefine formatfile et al. as char* instead of an array, and
dynamically allocate, or

2. use strlcpy to prevent overrunning the target buffer when copying the
names from argv.

Either one is technically correct, irrespective of GNU's warning.

In any case, you've provided a public service: even if this isn't the
problem, freebcp isn't checking its argument string lengths, and it
should. Thanks for pointing it out.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page