FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

This probably occurs on HP and Sparc's since they "bus error" on an 
unaligned access.  I believe the library is fine it's just the unittests 
that fail.  You could replace the the cast with 'memcpy(src_val, src, 
sizeof(float));' and it'd probably work.

Brian

On Fri, 8 Mar 2002, Mark Strong wrote:

> More on this.
> 
> a trace from gdb on the t0006 core
> ----------------------------------------------------------------------------
> Reading symbols from t0006...done.
> Reading symbols from
> /home/mstrong/freetds-0.53/src/tds/unittests/../.libs/libtds.sl.0...done.
> Reading symbols from /usr/lib/libc.2...done.
> Reading symbols from /usr/lib/libdld.2...done.
> Reading symbols from /usr/lib/libnss_dns.1...done.
> Reading symbols from /usr/lib/libnss_nis.1...done.
> Reading symbols from /usr/lib/libnsl.1...done.
> Reading symbols from /usr/lib/libxti.2...done.
> Reading symbols from /usr/lib/libnss_files.1...done.
> #0  main () at t0006.c:110
> 110                    src_val = *(float *)src;
> (gdb) bt
> #0  main () at t0006.c:110
> (gdb) quit
> ----------------------------------------------------------------------------
> --
> Also if I force it past test t0006 (the tests in the 'tds' dir), and let it
> do the
> tests in the 'dblib' dir it fails (cores) test t0012 only.  Here's the gdb
> trace on the core from t0012
> ----------------------------------------------------------------------------
> --
> Reading symbols from t0012...done.
> Reading symbols from
> /home/mstrong/freetds-0.53/src/dblib/unittests/../.libs/libsybdb.sl.1...done
> .
> Reading symbols from /usr/lib/libc.2...done.
> Reading symbols from /usr/lib/libdld.2...done.
> Reading symbols from /usr/lib/libnss_dns.1...done.
> Reading symbols from /usr/lib/libnss_nis.1...done.
> Reading symbols from /usr/lib/libnsl.1...done.
> Reading symbols from /usr/lib/libxti.2...done.
> Reading symbols from /usr/lib/libnss_files.1...done.
> #0  0xcaae88dc in dbdatecrack (dbproc=0x4000c178, di=0x7f7e0c88,
> dt=0x40014a35) at dblib.c:1668
> 1668            secs_from_epoch = ((dt->dtdays - 25567)*24*60*60) +
> (dt->dttime/300);
> (gdb) bt
> #0  0xcaae88dc in dbdatecrack (dbproc=0x4000c178, di=0x7f7e0c88,
> dt=0x40014a35) at dblib.c:1668
> #1  0x00002e44 in main (argc=1073791352, argv=0x7f7e0c88) at t0012.c:85
> (gdb) quit
> ----------------------------------------------------------------------------
> ----
> 
> Does this happen on all "Big Endian" machines with tdsver 7.0? (or is it
> just the HP's)
> 
> 
> Regards
> Mark Strong
> 
> 
> -----Original Message-----
> From: bounce-freetds-135006 AT franklin.oit.unc.edu
> [mailto:bounce-freetds-135006 AT franklin.oit.unc.edu]On Behalf Of Mark
> Strong
> Sent: Thursday, 7 March 2002 11:23
> To: TDS Development Group
> Subject: [freetds] Core Dump on HPUX 11.00 --with-tdsver=7.0, 4.2 is OK
> 
> 
> Hey guys getting this under HPUX
> 
> gmake  check-TESTS
> gmake[4]: Entering directory `/home/mstrong/freetds/src/tds/unittests'
> t0001.c: Testing login, logout
> PASS: t0001
> t0002.c: Test basic submit query, results
> PASS: t0002
> t0003.c: Testing DB change -- 'use tempdb'
> PASS: t0003
> t0004.c: Test large (>512 bytes) queries
> PASS: t0004
> t0005.c: Test large (>512 bytes) replies
> PASS: t0005
> t0006.c: Test SYBREAL, SYBFLT8 values
> /bin/sh: 24147 Bus error(coredump)
> FAIL: t0006
> 
> Only with tds ver 7.0, 4.2 is OK
> 
> Tried 0.53 and Current, both the same. (works OK under Linux, testing to
> the same MS SQL 7.0 server with tds ver 7.0).
> 
> Anyone know how to fix this?
> 
> 
> Thanks
> 
> Mark Strong
> 
> ---
> You are currently subscribed to freetds as: [mstrong AT concentrix.com.au]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
> 
> 
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>