Skip to Content.
Sympa Menu

freetds - Re: [freetds] Server dumps core while reading login packet

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Server dumps core while reading login packet
  • Date: Tue, 13 Apr 2004 21:41:11 -0400

On Tue, 13 Apr 2004, Steve Kirkendall <skirkendall AT dsl-only.net> wrote:
> I'm trying to write a simple SQL server so Windows users can run Crystal
> Reports on data in my company's Linux application.

Welcome, Steve.

> Last week I wrote the SQL interpreter,

You may appreciate that's not a sentence I read every day....

> and now I'm trying to use -ltdssrv to make it a server.

I wonder if SQLite would be any use?
http://www.hwaci.com/sw/sqlite/

I would be fun to see our server implementation bolted in front of
something moderately useful.

> They crash while trying to read strings for the login packet. My little
> SQL server dies while reading the client's host_name (the very first
> string), while the unittest program fails while reading the password,
> after successfully reading the host_name and user_name. In one instance
> I think unittest.c failed while reading user_name, but I'm not 100% sure
> about that. Both programs die while trying to free the old value of
> that string, when the old value is bogus.
>
> Is this a known problem? Or is it just me?

It's almost just you. The reason you're having trouble searching the
archives, and why there's no documentation, is that our server
implementation has seen very little use. As you surmise, all the work has
been on the client side.

Of course, this leaves the field wide open for any contribution you'd like
to make.

Brian wrote what's there, afaik. I probably runs only TDS 4.2. If you're
trying something else, that could result in a segfault. Still, the unit
test should oughta work.

> Oh, one other little problem: The tsql program seems to ignore the
> -pportnumber flag. I tried using -p1433 to make it use the same port
> as MS SQL Server, but it insists on using port 4000.

Look again at the man page. The port option is paired with the -H host
option. It doesn't affect the -S servername option. It could reject -p
-S, I suppose, but instead it just doesn't listen.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page