Skip to Content.
Sympa Menu

freetds - Re: [freetds] Segmentation fault on dbinit()

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Paul Andrews" <andrewsp AT andronics.com>
  • To: <konrad AT jax01.payplus.com>, "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Segmentation fault on dbinit()
  • Date: Fri, 26 Oct 2007 12:35:23 +0100

Yes...I have updated my glibc.

I have glibc 2.6.1-18.3, he has glibc 2.4-31.1

Paul.

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Konrad J Hambrick
Sent: 26 October 2007 12:08
To: FreeTDS Development Group
Subject: Re: [freetds] Segmentation fault on dbinit()


Paul --

Is /lib/libc.so.6 on your machine different
than the version on your colleague's machine ?

HTH.

-- kjh


On 10/26/2007 05:56 AM, Paul Andrews wrote:

> For chuckles, I commented out the fopen section in locale.c.
>
> I was then able to get past dbinit()
>
> HOWEVER, on dblogin(), I get a segmentation fault on:
>
> DSTR
> tds_dstr_copy(DSTR * s, const char *src)
> {
> if (*s != (DSTR) &tds_str_empty)
> free(*s);
> if (!src[0])
> *s = (DSTR) &tds_str_empty;
> else
> *s = (DSTR) strdup(src); <-- This line cause SIGSEGV when setting
DB-Library
> return *s;
> }
>
> Frame Stack:
> #0 ??
> #1 strdup /lib/libc.so.6
> #2 tds_dstr_copy tdsstring.h:131
> #3 tds_set_library login.c:132
> #4 dblogin dblib.c:402
>
> How come the unittests passed and this code fails bearing in mind that
> the code runs unaltered on a colleague's machine?
>
> Paul.
>
> Paul Andrews wrote:
>> 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
>>>
>>>
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.13/1074 - Release Date: 16/10/2007
14:14


Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.13/1074 - Release Date: 16/10/2007
14:14






Archive powered by MHonArc 2.6.24.

Top of Page