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: "Lowden, James K" <LowdenJK AT bernstein.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: Thu, 5 Jun 2003 14:45:25 -0400

> 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