[freetds] 0.61 tsql core dump, locale = "C C C C C C"

Discussion:

Cooperstock, Dan

2003-05-08 20:11:07 UTC

I've compiled 0.61, using these arguments to configure:

./configure --with-tdsver=8.0 --enable-msdblib

When I run tsql and try to connect to my MS SQL Server 2000, I get the
following output:

in main[1]/usr/local/etc/locales.conf
Found file.
Looking for section default.
Found section default.
Got a match.
insection!
option = date format
value = %b %d %Y %I:%M%p
insection!
option = language
value = us_english
insection!
option = char set
value = iso_1
Found section en_us.
s =
[2][3]
[3.1]
[3.2]
locale is "C C C C C C"
charset is "roman8"
[3.4]
[7]
[7]
[7]
[3.5]
[3.51]
[3.52]
[3.6]
[3.61]
[3.3]
[4]
Bus error (core dumped)

For starters, I'm not sure why tsql is being so verbose. Somebody else set
this up initially, so they may have tweaked some setting. I haven't touched
locales.conf at all. My entry for the SQL Server in freetds.conf is:

[sqldev]
host = sqldev.hepcoe.com
port = 1433
tds version = 8.0

I'm following the advice in the BUGS file that server names need to be lower
case.

Any ideas?

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

Lowden, James K

2003-05-08 20:40:21 UTC

Permalink

From: Cooperstock, Dan [mailto:dan.cooperstock at hepcoe.com]
Sent: May 8, 2003 4:11 PM
./configure --with-tdsver=8.0 --enable-msdblib
When I run tsql and try to connect to my MS SQL Server 2000, I get the
in main[1]/usr/local/etc/locales.conf
Found file.
Looking for section default.
Found section default.
Got a match.
insection!

Dan, is there any chance TDSDUMPCONFIG is set to stderr? There's no chance
this is tsql output you're looking at.

...

Bus error (core dumped)

It would be helpful if you could run tsql under gdb and show us the
backtrace after the bus error. Apparently you're using a 64-bit
architecture and stumbled on a 32-bit assumption. :-(

It could also be that once you turn off TDSDUMPCONFIG, the bus error will go
way. ISTR something along those lines.

Regards,

--jkl

The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

Cooperstock, Dan

2003-05-08 21:24:09 UTC

Permalink

I don't seem to have TDSDUMPCONFIG set in my environment. At least,
env | grep TDS
doesn't show anything. Is there some other way this functionality could be
turned on?

I am indeed on a 64-bit architecture.

I haven't used gdb for years, but I gave it a try. Here's what I got. First,
after running, it gave:

Program received signal SIGBUS, Bus error.
0x800003ffff6c2fc4 in __getpwuid_r_posix () from /lib/pa20_64/libc.2

Here's the backtrace:

#0 0x800003ffff6c2fc4 in __getpwuid_r_posix () from /lib/pa20_64/libc.2
#1 0x800003ffff7901e8 in tds_get_homedir () at threadsafe.c:235
#2 0x800003ffff788fa0 in tds_get_home_file (
file=0x800003ffff762a18 ".freetds.conf") at config.c:210
#3 0x800003ffff789128 in tds_read_conf_file
(connect_info=0x8000000100008810,
server=0x8000000100008450 "sqldev") at config.c:247
#4 0x800003ffff788c80 in tds_read_config_info (tds=0x0,
login=0x8000000100007b60, locale=0x8000000100007c00) at config.c:143
#5 0x4000000000004428 in main (argc=7, argv=0x800003ffff7f0760) at
tsql.c:448

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Thursday, May 08, 2003 4:40 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Dan, is there any chance TDSDUMPCONFIG is set to stderr? There's no chance
this is tsql output you're looking at.

...

Bus error (core dumped)

James K. Lowden

2003-05-09 00:44:16 UTC

Permalink

On Thu, 8 May 2003 17:24:09 -0400 , "Cooperstock, Dan"

Dan,

Well, as usual, it didn't help a lot, but we know more than we did before.
:-/

AFAIK, no, there's no other way to turn on that functionality. The
trouble starts hereabouts, in scr/tds/config.c:

TDSCONNECTINFO *
tds_read_config_info(TDSSOCKET * tds, TDSLOGIN * login, TDSLOCALE *
locale)
{
TDSCONNECTINFO *connect_info;
char *s;
char *path;
pid_t pid;
int opened = 0;

/* allocate a new structure with hard coded and build-time defaults */
connect_info = tds_alloc_connect(locale);
if (!connect_info)
return NULL;

s = getenv("TDSDUMPCONFIG");
if (s) {
if (*s) {
opened = tdsdump_open(s);
} else {
pid = getpid();
if (asprintf(&path, "/tmp/tdsconfig.log.%d", pid) >= 0) {
if (*path) {
opened = tdsdump_open(path);
}
free(path);
}
}
}

I'm sorry to blat all that in your inbox. As you can see, though, we call
getenv(3), and open whatever it returns, if it returns anything. Only by
that path do we arrive at tdsdump_open(). You can see from the bt that we
started there.

It seems very likely that, for whatever reason, getenv("TDSDUMPCONFIG") is
returning something ... most likely would of course be "stderr".

The bus error is something different, possibly stemming from our
misdetection of the semantics or signature of your getpwuid_r(3). Maybe
we should try to figure out what's up with getenv() first?

Regards,

--jkl

Post by Cooperstock, Dan
Program received signal SIGBUS, Bus error.
0x800003ffff6c2fc4 in __getpwuid_r_posix () from /lib/pa20_64/libc.2
#0 0x800003ffff6c2fc4 in __getpwuid_r_posix () from /lib/pa20_64/libc.2
#1 0x800003ffff7901e8 in tds_get_homedir () at threadsafe.c:235
#2 0x800003ffff788fa0 in tds_get_home_file (
file=0x800003ffff762a18 ".freetds.conf") at config.c:210
#3 0x800003ffff789128 in tds_read_conf_file
(connect_info=0x8000000100008810,
server=0x8000000100008450 "sqldev") at config.c:247
#4 0x800003ffff788c80 in tds_read_config_info (tds=0x0,
login=0x8000000100007b60, locale=0x8000000100007c00) at config.c:143
#5 0x4000000000004428 in main (argc=7, argv=0x800003ffff7f0760) at
tsql.c:448

ZIGLIO Frediano

2003-05-09 09:01:53 UTC

Permalink

Post by Cooperstock, Dan
I don't seem to have TDSDUMPCONFIG set in my environment. At least,
env | grep TDS
doesn't show anything. Is there some other way this
functionality could be
turned on?
I am indeed on a 64-bit architecture.
I haven't used gdb for years, but I gave it a try. Here's
what I got. First,
Program received signal SIGBUS, Bus error.
0x800003ffff6c2fc4 in __getpwuid_r_posix () from /lib/pa20_64/libc.2

Are you using HP/UX 11??
This seem a known problem of FreeTDS 0.61.
This is fixed in CVS.
It's caused but wrong detection of getpwuid_r.
I merged the patch in 0.61 branch.
Replacing acinclude.m4 (attacched), reconfiguring and rebuild should fix our problem

freddy77

PS: James, can you repack 0.61 version on web ?

Lowden, James K

2003-05-09 14:53:44 UTC

Permalink

From: ZIGLIO Frediano [mailto:Frediano.Ziglio at vodafoneomnitel.it]
Sent: May 9, 2003 5:02 AM
PS: James, can you repack 0.61 version on web ?

Sure. We should call it 0.61.1, though, don't you think?

I'll need to update README to reflect changes since 0.61. Is everything I
need in ChangeLog?

--jkl

The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

ZIGLIO Frediano

2003-05-09 16:02:34 UTC

Permalink

Post by Lowden, James K

Post by ZIGLIO Frediano
PS: James, can you repack 0.61 version on web ?

Sure. We should call it 0.61.1, though, don't you think?
I'll need to update README to reflect changes since 0.61. Is
everything I
need in ChangeLog?

Yes, it's all in ChangeLog

bye
freddy77

Cooperstock, Dan

2003-05-12 13:48:50 UTC

Permalink

Thanks. Now with the new acinclude.m4 file that Freddy posted, I have got
everything to work, up to "make install". When I do that, it does things
successfully for a while, then ends like this:

Making install in msvc6
No suffix list.
No suffix list.
No suffix list.
No suffix list.
No suffix list.
No suffix list.
/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.
*** Error exit code 126

Since I don't think freetds.conf should have execute permission, so I'm
stumped.

I'm also guessing that it hasn't installed fully, because if I just run tsql
with no arguments, it's still being very verbose to stdout, including
reporting on the locale being "C C C C C C C".
In addition, I'm getting warning errors on config.c, which James Lowden
thinks probably indicate a 64-bit corruption that needs to be fixed, and may
be causing all of my problems:
cc: "config.c", line 842: warning 724: Assignment converts default int
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 851: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 854: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 855: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 856: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 864: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 866: warning 725: Assignment converts 32 bit integer to
pointer "field".
cc: "config.c", line 869: warning 725: Assignment converts 32 bit integer to
pointer "field".

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at vodafoneomnitel.it]
Sent: Friday, May 09, 2003 1:09 PM
To: Cooperstock, Dan
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Freddie, in your previous response about this you said you
were attaching an
m4 file that fixes this, but I didn't see it. Can you maybe
send it to me
directly, or let me know how to get it? I'm not up on CVS.
Or, I guess I can wait until you post it to www.freetds.org
if necessary.
Actually, which is the part that is a "known bug"? The
unexpected logging to
stderr? The bus error core dump? The display of "C C C C C"
as the locale?
Thanks.
Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/freetds/freetds/ac
include.m4?rev=1.15.2.2

freddy77

ZIGLIO Frediano

2003-05-12 14:07:04 UTC

Permalink

Post by Cooperstock, Dan
Thanks. Now with the new acinclude.m4 file that Freddy
posted, I have got
everything to work, up to "make install". When I do that, it
does things
Making install in msvc6
No suffix list.
No suffix list.
No suffix list.
No suffix list.
No suffix list.
No suffix list.
/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.
*** Error exit code 126
Since I don't think freetds.conf should have execute
permission, so I'm
stumped.

configure did not find install program.
Source is
...
$(INSTALL_DATA) $(srcdir)/freetds.conf $(ETC)/freetds.conf; \
...
So INSTALL_DATA seems empty

Post by Cooperstock, Dan
I'm also guessing that it hasn't installed fully, because if
I just run tsql
with no arguments, it's still being very verbose to stdout, including
reporting on the locale being "C C C C C C C".

Strange locale...

Post by Cooperstock, Dan
In addition, I'm getting warning errors on config.c, which
James Lowden
thinks probably indicate a 64-bit corruption that needs to be
fixed, and may
cc: "config.c", line 842: warning 724: Assignment converts default int
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 851: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 854: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 855: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 856: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 864: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 866: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 869: warning 725: Assignment converts 32
bit integer to
pointer "field".

No, probably are related to strtok_r headers not included.
Try doing a "man strtok_r" and see what header reports...

Post by Cooperstock, Dan
Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

bye
freddy77

ZIGLIO Frediano

2003-05-12 14:40:51 UTC

Permalink

Post by Cooperstock, Dan

default int

Post by Cooperstock, Dan
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 851: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 854: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 855: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 856: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 864: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 866: warning 725: Assignment converts 32
bit integer to
pointer "field".
cc: "config.c", line 869: warning 725: Assignment converts 32
bit integer to
pointer "field".

No, probably are related to strtok_r headers not included.
Try doing a "man strtok_r" and see what header reports...

Try enabling threadsafe option (see "configure --help" or userguide)

freddy77

Lowden, James K

2003-05-12 15:09:41 UTC

Permalink

From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: May 12, 2003 10:07 AM

Post by Cooperstock, Dan
In addition, I'm getting warning errors on config.c, which
James Lowden
thinks probably indicate a 64-bit corruption that needs to be
cc: "config.c", line 842: warning 724: Assignment converts

default int

Post by Cooperstock, Dan
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32
bit integer to pointer "field".

No, probably are related to strtok_r headers not included.
Try doing a "man strtok_r" and see what header reports...

Freddy, just to confirm: We expect no 64-bit warnings, right? It's my
understanding that FreeTDS should compile cleanly on any 64-bit platform.

I told Dan I suspect, as you do, that we're failing to detect one of his
header files, and that these warning are a consequence of trying to compile
against an invalid prototype.

My theory is that some misalignment causes a 0 or 1 to be deposited in the
dump filehandle, resulting in log output going to stdout/stderr.

Dan, it might help to post your config.log.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.

Frediano Ziglio

2003-05-12 19:11:51 UTC

Permalink

Post by Lowden, James K

From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: May 12, 2003 10:07 AM

default int

Post by Cooperstock, Dan
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32
bit integer to pointer "field".

No, probably are related to strtok_r headers not included.
Try doing a "man strtok_r" and see what header reports...

Freddy, just to confirm: We expect no 64-bit warnings, right? It's my
understanding that FreeTDS should compile cleanly on any 64-bit platform.

Time ago I compiled on a alpha station without compile warnings...
However compiler complains about a conversion int -> char* (field) ...
The row was "field = strtok_r(...);" So compiler see strtok_r like a
function returning int (like undefined function).

I search in internet strtok_r for header (on HP/UX is in string.h and/or
in strings.h). So I connect to a HP/UX (happily I can use one machine)
and found that strtok_r declaration is surrounded by #ifdef _REENTRANT
... # endif so I suggest to enable thread-safe...

Post by Lowden, James K
I told Dan I suspect, as you do, that we're failing to detect one of his
header files, and that these warning are a consequence of trying to compile
against an invalid prototype.
My theory is that some misalignment causes a 0 or 1 to be deposited in the
dump filehandle, resulting in log output going to stdout/stderr.

Perhaps I missed something...

Post by Lowden, James K
Dan, it might help to post your config.log.

freddy77

Cooperstock, Dan

2003-05-14 13:13:38 UTC

Permalink

This email got stopped because it was too big with config.log attached, so
I'm re-posting it with the config.log file gzip'd to make it smaller. (I was
requested to post this file.)

-----Original Message-----
OK, replying to a few things.

"man strtok_r" shows:

SYNOPSIS
#include <string.h>
#include <strings.h>

I added --enable-threadsafe to my arguments to configure. The config.log is
attached. It says it found strtok_r.

These are the remaining warnings I get when I do the make:
cpp: "convert.c", line 2650: warning 2013: Unknown preprocessing directive.
(Interestingly, I don't see a preprocessor directive at that line number.)
libtool: link: warning: this platform does not like uninstalled shared
libraries
libtool: link: `tsql' will be relinked during installation
That occurs a few times.
cc: "login.c", line 90: warning 728: Argument #3 converts long* to
int*.
cc: "user.c", line 76: warning 728: Argument #3 converts long* to
int*.

When I do "make install", I still get the following error:

/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.
*** Error exit code 126

Running "tsql" still shows the strange locale value.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Monday, May 12, 2003 11:10 AM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: May 12, 2003 10:07 AM

default int

Post by Cooperstock, Dan
return type to pointer "field".
cc: "config.c", line 849: warning 725: Assignment converts 32
bit integer to pointer "field".

No, probably are related to strtok_r headers not included.
Try doing a "man strtok_r" and see what header reports...

Freddy, just to confirm: We expect no 64-bit warnings, right? It's my
understanding that FreeTDS should compile cleanly on any 64-bit platform.

I told Dan I suspect, as you do, that we're failing to detect one of his
header files, and that these warning are a consequence of trying to compile
against an invalid prototype.

My theory is that some misalignment causes a 0 or 1 to be deposited in the
dump filehandle, resulting in log output going to stdout/stderr.

Dan, it might help to post your config.log.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log.gz
Type: application/octet-stream
Size: 9673 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20030514/8653e092/attachment.obj

ZIGLIO Frediano

2003-05-14 14:22:07 UTC

Permalink

Hi Dan!

Post by Cooperstock, Dan
This email got stopped because it was too big with config.log
attached, so
I'm re-posting it with the config.log file gzip'd to make it
smaller. (I was
requested to post this file.)

Tnx

Post by Cooperstock, Dan
-----Original Message-----
OK, replying to a few things.
SYNOPSIS
#include <string.h>
#include <strings.h>
I added --enable-threadsafe to my arguments to configure. The
config.log is
attached. It says it found strtok_r.

Now --enable-threadsafe is enabled by default...

Post by Cooperstock, Dan
cpp: "convert.c", line 2650: warning 2013: Unknown
preprocessing directive.
(Interestingly, I don't see a preprocessor directive at that
line number.)

Very strange...

Post by Cooperstock, Dan
libtool: link: warning: this platform does not like uninstalled shared
libraries
libtool: link: `tsql' will be relinked during installation
That occurs a few times.
cc: "login.c", line 90: warning 728: Argument #3
converts long* to
int*.
cc: "user.c", line 76: warning 728: Argument #3
converts long* to
int*.

These are severe errors !!!
Using 64 bit compiler long is 64 bit while int is only 32...
There are some login.c file. What directory?

Post by Cooperstock, Dan
/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.
*** Error exit code 126

Strange. On my Linux machine "cat Makefile | grep INSTALL_DATA" command return:

INSTALL_DATA = ${INSTALL} -m 644
INSTALL_HEADER = $(INSTALL_DATA)
$(INSTALL_DATA) $(srcdir)/freetds.conf $(ETC)/freetds.conf; \
$(INSTALL_DATA) $(srcdir)/locales.conf $(ETC)/locales.conf; \

$ cat Makefile | grep ^INSTALL
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL}
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_SCRIPT = ${INSTALL}
INSTALL_HEADER = $(INSTALL_DATA)
INSTALL_STRIP_PROGRAM = ${SHELL} $(install_sh) -c -s

Post by Cooperstock, Dan
Running "tsql" still shows the strange locale value.

It's strange but is what setlocale(LC_ALL,"") return...
I'm doing some more tests and fix for HP/UX and charset...

freddy77

Cooperstock, Dan

2003-05-14 15:10:14 UTC

Permalink

The login.c that gives the warning message is in src/server.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: Wednesday, May 14, 2003 10:22 AM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Post by Cooperstock, Dan
cc: "login.c", line 90: warning 728: Argument #3
converts long* to
int*.
cc: "user.c", line 76: warning 728: Argument #3
converts long* to
int*.

These are severe errors !!!
Using 64 bit compiler long is 64 bit while int is only 32...
There are some login.c file. What directory?

ZIGLIO Frediano

2003-05-14 16:13:31 UTC

Permalink

Post by Cooperstock, Dan
The login.c that gives the warning message is in src/server.
Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055
-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: Wednesday, May 14, 2003 10:22 AM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Post by Cooperstock, Dan
cc: "login.c", line 90: warning 728: Argument #3
converts long* to
int*.
cc: "user.c", line 76: warning 728: Argument #3
converts long* to
int*.

These are severe errors !!!
Using 64 bit compiler long is 64 bit while int is only 32...
There are some login.c file. What directory?

I expect this page http://devrsrc1.external.hp.com/STK/impacts/i338.html will help both.

What's sizeof(socklen_t) and sizeof(size_t) ??

freddy77

Cooperstock, Dan

2003-05-15 13:29:57 UTC

Permalink

Post by ZIGLIO Frediano
What's sizeof(socklen_t) and sizeof(size_t) ??

Both have size 8.
- Dan.

ZIGLIO Frediano

2003-05-15 14:56:09 UTC

Permalink

Post by Cooperstock, Dan

Post by ZIGLIO Frediano
What's sizeof(socklen_t) and sizeof(size_t) ??

Both have size 8.
- Dan.

The warning occur on accept call

Manual (http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90682&service=hpux&path=../B2355-90682/00/00/6&title=HP-UX%20Reference%20Volume%203%3A%20Sections%202%20and%204) say

int accept(int s, void *addr, int *addrlen);

_XOPEN_SOURCE_EXTENDED only (UNIX 98)

int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

Obsolescent _XOPEN_SOURCE_EXTENDED only (UNIX 95)

int accept(int s, struct sockaddr *addr, size_t *addrlen);

The conversion from long* to int* suggest that we should define _XOPEN_SOURCE_EXTENDED somewhere for HP/UX...

Add a "#define _XOPEN_SOURCE_EXTENDED" to config.h and try recompile. Warning should disappear...
However I don't understand... I a program call int* (32bit pointer) it call the same function of size_t*/socklen_t* (64bit pointer) version ?? It seem a header bug to me... Is HP/UX little endian or big endian ???

freddy77

Cooperstock, Dan

2003-05-15 18:31:50 UTC

Permalink

Just to be clear, both long * and int * are 8-byte pointers. However, int is
a 4-byte datatype, and long is 8-byte.

I've forgotten which is which of big-endian and little-endian. But I wrote a
small test program, and set an int to 1. The 1 showed up in the right-most
of the 4 bytes in the int.

After making the change of adding "#define _XOPEN_SOURCE_EXTENDED" to my
config.h, here's what happens in the compile:

cpp: "convert.c", line 2650: warning 2013: Unknown preprocessing directive.

On line 2650, I see "#!perl", which obviously is not valid. It's within a
section "#ifdef DONT_TRY_TO_COMPILE_THIS", but obviously my compiler still
complains. We're using the standard HP-UX C Compiler.

The other warning has gone away, but there's a new one, apparently on
linking tdspool:
ld: (Warning) Unsatisfied symbol "htons" in file
../server/.libs/libtdssrv.sl

I'm not really planning to use tdspool, but maybe this is an indication of
some other problem that we need to be concerned about.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: Thursday, May 15, 2003 10:56 AM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Post by Cooperstock, Dan

Post by ZIGLIO Frediano
What's sizeof(socklen_t) and sizeof(size_t) ??

Both have size 8.
- Dan.

The warning occur on accept call

Manual
(http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90682&service=hpux&path=
../B2355-90682/00/00/6&title=HP-UX%20Reference%20Volume%203%3A%20Sections%20
2%20and%204) say

int accept(int s, void *addr, int *addrlen);

_XOPEN_SOURCE_EXTENDED only (UNIX 98)

int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

Obsolescent _XOPEN_SOURCE_EXTENDED only (UNIX 95)

int accept(int s, struct sockaddr *addr, size_t *addrlen);

The conversion from long* to int* suggest that we should define
_XOPEN_SOURCE_EXTENDED somewhere for HP/UX...

Add a "#define _XOPEN_SOURCE_EXTENDED" to config.h and try recompile.
Warning should disappear...
However I don't understand... I a program call int* (32bit pointer) it call
the same function of size_t*/socklen_t* (64bit pointer) version ?? It seem a
header bug to me... Is HP/UX little endian or big endian ???

freddy77

Frediano Ziglio

2003-05-15 18:53:17 UTC

Permalink

Post by Cooperstock, Dan
Just to be clear, both long * and int * are 8-byte pointers. However, int is
a 4-byte datatype, and long is 8-byte.

You are right, I expressed myself badly...

Post by Cooperstock, Dan
I've forgotten which is which of big-endian and little-endian. But I wrote a
small test program, and set an int to 1. The 1 showed up in the right-most
of the 4 bytes in the int.
After making the change of adding "#define _XOPEN_SOURCE_EXTENDED" to my
cpp: "convert.c", line 2650: warning 2013: Unknown preprocessing directive.
On line 2650, I see "#!perl", which obviously is not valid. It's within a
section "#ifdef DONT_TRY_TO_COMPILE_THIS", but obviously my compiler still
complains. We're using the standard HP-UX C Compiler.

It's only a warning, ignore it. It's just a perl syntax (there is some
perl code nested to convert.c)

Post by Cooperstock, Dan
The other warning has gone away, but there's a new one, apparently on

Good!

Post by Cooperstock, Dan
ld: (Warning) Unsatisfied symbol "htons" in file
../server/.libs/libtdssrv.sl
I'm not really planning to use tdspool, but maybe this is an indication of
some other problem that we need to be concerned about.

You can use --disable-pool option to configure.

Post by Cooperstock, Dan
Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

Thank you very much for your patience and feedback.

freddy77

Frediano Ziglio

2003-05-15 19:15:58 UTC

Permalink

....

Post by Cooperstock, Dan
of the 4 bytes in the int.
After making the change of adding "#define _XOPEN_SOURCE_EXTENDED" to my

...

Post by Cooperstock, Dan
The other warning has gone away, but there's a new one, apparently on
ld: (Warning) Unsatisfied symbol "htons" in file
../server/.libs/libtdssrv.sl

I should have fixed both problem. Can you give it a try ? You can use
tomorrow snapshot.

freddy77

Cooperstock, Dan

2003-05-16 15:32:01 UTC

Permalink

I downloaded the nightly snapshot. When I do my configure, it ends as
follows:

finding the maximum length of command line arguments... ./ltconfig[790]:
There is not enough memory available now.
configure: error: libtool configure failed

Also, back on version 0.61, even after the relatively successful compile,
I'm still getting the following error at the end of "make install":

/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.

I know there was some discussion of this, but I never heard anything that
would clearly fix it.

BTW, I'm here the rest of today, then on vacation for 2 weeks. I'm back in
the office on June 2nd.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: Frediano Ziglio [mailto:freddyz77 at tin.it]
Sent: Thursday, May 15, 2003 3:17 PM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

....

Post by Cooperstock, Dan
of the 4 bytes in the int.
After making the change of adding "#define _XOPEN_SOURCE_EXTENDED" to my

...

Post by Cooperstock, Dan
The other warning has gone away, but there's a new one, apparently on
ld: (Warning) Unsatisfied symbol "htons" in file
../server/.libs/libtdssrv.sl

I should have fixed both problem. Can you give it a try ? You can use
tomorrow snapshot.

freddy77

ZIGLIO Frediano

2003-05-16 15:38:19 UTC

Permalink

Post by Cooperstock, Dan
I downloaded the nightly snapshot. When I do my configure, it ends as
finding the maximum length of command line arguments...
There is not enough memory available now.
configure: error: libtool configure failed

Strange, we didn't touch ltconfig...

Post by Cooperstock, Dan
Also, back on version 0.61, even after the relatively
successful compile,
/usr/bin/sh ./mkinstalldirs
if test ! -f /freetds.conf; then \
./freetds.conf /freetds.conf; \
fi
sh[2]: ./freetds.conf: Execute permission denied.

On HP/UX 10.20 I have these 3 lines in main Makefile

INSTALL = ./install-sh -c
INSTALL_PROGRAM = ${INSTALL}
INSTALL_DATA = ${INSTALL} -m 644

It seem that your INSTALL is empty ...

Post by Cooperstock, Dan
I know there was some discussion of this, but I never heard
anything that
would clearly fix it.
BTW, I'm here the rest of today, then on vacation for 2
weeks. I'm back in
the office on June 2nd.

Have a nice holyday

bye
freddy77

Cooperstock, Dan

2003-05-16 16:43:32 UTC

Permalink

This is what I found about INSTALL in the master Makefile:

INSTALL = /opt/imake/bin/install -c
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)

It appears that somehow "install_sh" has been substituted for INSTALL. So, I
switched it back globally in the Makefile. Then it seems to go fine, except
for the following Warning, which we've already discussed:

ld: (Warning) Unsatisfied symbol "htons" in file /usr/local/lib/libtdssrv.sl

Then, if I run tsql with no arguments, I still get the same outputs as
before - very verbose, and with the weird locale. If I try to run it with
real arguments to connect to my SQL Server, it does connect, and I can do
stuff! Yay! However, I still don't understand why it's being so verbose with
messages, like this:

in main[1]/usr/local/etc/locales.conf
Found file.
Looking for section default.
Found section default.
Got a match.
insection!
option = date format
value = %b %d %Y %I:%M%p
insection!
...

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com 416-597-5055

-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at mail.vodafone.it]
Sent: Friday, May 16, 2003 11:38 AM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

Strange, we didn't touch ltconfig...

On HP/UX 10.20 I have these 3 lines in main Makefile

INSTALL = ./install-sh -c
INSTALL_PROGRAM = ${INSTALL}
INSTALL_DATA = ${INSTALL} -m 644

It seem that your INSTALL is empty ...

Have a nice holyday

bye
freddy77

Lowden, James K

2003-05-16 17:39:00 UTC

Permalink

From: Cooperstock, Dan [mailto:dan.cooperstock at hepcoe.com]
Sent: May 16, 2003 12:44 PM
Then, if I run tsql with no arguments, I still get the same outputs as
before - very verbose, and with the weird locale.

I think I know what's wrong, Dan, but not why. It's tow things:

1. We're still misdetecting some header file's function prototype.
2. Early on, a 1 (one) is written to the static variable
src/tds/util.c::dumpfile, tricking the logging functions into writing to
stdout.

What should happen if you start tsql without arguments:

$ tsql
locale is "C"
locale charset is "646"
Missing argument -S or -H
Usage: tsql [-S <server> | -H <hostname> -p <port>] ...

Perhaps a backtrace will help Frediano track down what's going on. Could
you try this:

gdb tsql
(gdb) b main
(gdb) r [arguments]
(gdb) watch dumpfile != 0
Watchpoint 5: dumpfile != 0
(gdb) c
Continuing.
locale is "C"
locale charset is "646"
Watchpoint 5: dumpfile != 0

Old value = 0
New value = 1
0x4807efc1 in tdsdump_open (filename=0x804f240 "dump")
at src/tds/util.c:195
195 } else if (NULL == (dumpfile = fopen(filename, "w"))) {
(gdb) bt
#0 0x4807efc1 in tdsdump_open (filename=0x804f240 "dump")
at src/tds/util.c:195
#1 0x4807f7b1 in tds_connect (tds=0x8050000, connect_info=0x8050100)
at src/tds/login.c:227
#2 0x804a31a in main (argc=7, argv=0xbfbfba20)
at src/apps/tsql.c:483

My guess is you won't get anywhere near that far, that "dumpfile" is being
corrupted early and often. The bt should expose the awry assignment.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.