Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Cooperstock, Dan" <dan.cooperstock AT hepcoe.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"
  • Date: Fri, 6 Jun 2003 15:17:10 -0400

While compiling with gcc might help with debugging, I can't use it in the
long run. That's because the FreeTDS libraries eventually needs to be use by
our production applications, which are compiled with cc. I'm sure that's not
negotiable.

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, June 05, 2003 2:45 PM
To: FreeTDS Development Group
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

> From: Cooperstock, Dan [mailto:dan.cooperstock AT hepcoe.com]
> Sent: June 5, 2003 1:32 PM

> I'm sure it's the same for you, but this is getting very frustrating.

I'm sure it's worse for you than for me. I wish I knew more about your
environment, because then I could guide you better.

> Actually, I'm compiling with the HP-UX C compiler, cc. Is
> that a problem?

I think so. The gcc and gdb reference manuals talk about symbol formats. I
think atm your compiler is not emitting symbols that gdb understands, at
least not in a shared library.

> As you may recall, I can't configure the last nightly
> snapshot I downloaded.
> Its output ends with:
>
> finding the maximum length of command line arguments...
> ./ltconfig[790]:
> There is not enough memory available now.
> configure: error: libtool configure failed

:-(

This is coming from libtool, and I'm sorry to say I can't help you. In the
past, people with HP systems have had to patch the configure script. IIRC,
it had something to do with the shell's maximum command line size, but I
really don't know. For the record, and as you can see in the lt* files, we
use libtool 1.4a.

(You might also try the obvious: raising your process's memory limit with
ulimit(1).)

> In 0.61, there was no CFLAGS set in the master Makefile at all (in the
> freetds-0.61 directory). However, in the src subdirectory, I see:
> CFLAGS = -g
> When I force it to recompile some stuff, it definitely uses -g.

"-g" is the gcc convention. Your compiler may use different switches.

> When I do the gdb thing you suggested on
> /usr/local/lib/libtds.sl.2.0, it
> can't find the dumpfile symbol.

Right. That's consistent with the symbol format isssue: your compiler and
debugger have to agree on the format of the debugging symbols if they're to
be any use. You could change your compiler, your debugger, or convince the
compiler to emit the debugger's favorite symbol flavor, or maybe even
convince gdb to read your compiler's output (once you know what that is).

I realize we're debugging the debugger debugger debugger, far from what
we're after. Loading up the debugger to find out where the dumpfile handle
is being overwritten is a brute force tactic. A more entertaining technique
might be to sprinkle printf() throughout the code to try to narrow down
where it goes wrong, looking for bad 64-bit assumptions or casts.

> (N.B. you gave the file name as .so, whereas
> mine is .sl - is that relevant in any way?)

You OS (or compiler?) apparently uses a different naming convention from
mine. I wonder if gcc on your OS creates .so ("shared object") or .sl
("shared library"?) files.

HTH.

--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.





Archive powered by MHonArc 2.6.24.

Top of Page