FreeTDS Development Group

[sreynolds AT bradmark.com]

This problem turned out to be in the dlsym call in the driver manager before 
it even 
got into the tds driver. It is this bug from the HP web site

              - JAGae28531: Severity :7
            dlsym() hangs process

This is documented for instance in the most recent ld patch PHSS_28871. Since 
the 
dlsym call is hanging, I never could get TDSDUMP to go. No debugger is 
available 
on the system, so had to add print statements (lots of them).

BTW, I do have three other HPUX boxes where tds works great (two are 64 bit)! 

thanks
Steven

>On Tue, 04 Nov 2003, sreynolds AT bradmark.com wrote:
>> 
>> I have a problem that I am wondering if anyone on the tds list might be
>> able to help.
>> 
>> I have an application that connects and exports data using freetds. It
>> runs well on several platforms (WIN32, solaris, linux, Tru64, AIX), but
>> is having a problem on HPUX 11.11 when it connects to a Sybase 12.503
>> (64-bit) on another HPUX 11.11 box. At this one place, the application
>> does not connect, and instead spins consuming most of the CPU. 
>...
>> This time, the connection confirmation or failure message didn't print,
>> the application just spins (the hello message does print). The user
>> there set TDSDUMP, but did not get a log file. 
>
>Welcome to the list, Steven.  I would welcome you to the project, but
>judging from your client list, it's a little late for that.  ;-)
>
>You're quite possibly the first one to use 64-bit HPUX on both ends. 
>These are big endian machines, yes?  It sounds like you've been bitten by
>a nasty bug.  I'd like to help you, so you're the last one to be so
>bitten.  It won't be easy, though, because if it's as bad as you say, I'll
>be guessing about the network behavior of a system I don't know.  
>
>Let's do something simple to make sure there's really *no* log:
>
>$ export TDSDUMP=stderr 
>$ tsql -S [etc.]
>
>I think you'll see something, because we write to the log file before we
>try to connect.  I think the log went somewhere the user didn't expect, or
>to a directory he didn't have permission to write to.  
>
>If at all possible, I'd like to see a backtrace at the point the machine
>spins the CPU.  
>
>The log should tell us what the server sent that we're not interpreting
>correctly, and the bt will show what function we were in when that
>happened.  
>
>--jkl