FreeTDS Development Group

[Paul Andrews <andrewsp AT andronics.com>]

OK...I removed the rpm-installed FreeTDS, downloaded 0.64 and installed.

I ran 'make check' and all tests were *fine.*

I opened up my project and ran it...same result...segmentation fault on
dbinit()!

Frame Stack:

#0 ??
#1 ?? /lib/libc.so.6
#2 fopen64 /lib/libc.so.6
#3 tds_get_locale locale.c:66
#4 tds_alloc_context memc:539
#5 dblib_get_tds_ctx dblib.c:263
#6 dbinit dblib.c:375
#7 db_connect /projects/lpgsonic/src/db.c:25

My machine:
ldd:
linux-12:/projects/lpgsonic/debug/src # ldd lpgsonic
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7f95000)
libsybdb.so.5 => /usr/local/lib/libsybdb.so.5 (0xb7f49000)
libc.so.6 => /lib/libc.so.6 (0xb7e16000)
/lib/ld-linux.so.2 (0xb7fd8000)

Colleague:
/projects/lpgsonic/debug/src # ldd lpgsonic
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7f56000)
libsybdb.so.5 => /usr/local/lib/libsybdb.so.5 (0xb7f14000)
libc.so.6 => /lib/libc.so.6 (0xb7df4000)
/lib/ld-linux.so.2 (0xb7f9a000)

James K. Lowden wrote:
> Paul Andrews wrote:
>   
>>     I can confirm that
>>         1. dbinit is only called once.
>>         2. fopen causes a segmentation fault
>>     
>
> Hi Paul, 
>
> I'm starting to think this is an ABI problem.  
>
>   
>> I sent the entire project over to a colleague who successfully debugged
>> and ran the program on his 10.2 installation.
>>     
>
> Good.  That supports the notion that your code *and* FreeTDS are OK.  
>
>   
>>     I then decided to update to Suse 10.3 (complete format and new
>> installation).
>>
>>     Problem is still there.
>>     
> ...
>   
>>      I have glibc 2.6.1-18.3, he has glibc 2.4-31.1
>>     
> ...
>   
>> Platform: Suse 10.2 / 10.3 using rpm's from OpenSuse.org
>>     
>
> Did you build FreeTDS from source on the 10.3 box?  If you're using
> binaries compiled for another glibc, that could conceivably explain a
> fault in fopen(3). In that case, though, it's the shared objects you'd be
> interested in.  Try ldd(1) on both system to see what your program is
> using.  
>
> See also the gnu libc faq:
> http://www.gnu.org/software/libc/FAQ.html#s-1.17, 
>
> The standard remedy to broken binaries is to build good ones.  Then do
> "make check" and watch everything work.  ;-)
>
> (You might try having your friend compile your test program and running it
> on your machine.  But that could only prove a negative; if it worked, it
> wouldn't tell us much.)
>
> If you built from scratch on your machine and get a failure in the first
> unit test in fopen(3), I would be interested in seeing the backtrace.  I
> don't know what I could do about it, but it would be interesting!  
>
> HTH.  
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>