[freetds] 0.61 tsql core dump, locale = "C C C C C C"
Lowden, James K
LowdenJK at bernstein.com
Thu Jun 5 14:45:25 EDT 2003
> 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...
> 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.
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.
More information about the FreeTDS