freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib
- From: Frediano Ziglio <freddyz77 AT tin.it>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib
- Date: Wed, 16 Feb 2005 19:40:10 +0100
Il giorno mer, 16-02-2005 alle 13:02 +0000, Thompson, Bill D (London) ha
scritto:
> Hi Freddy,
>
> I had a couple of days off, so apologies for not getting back.
>
Don't mind.
> I've downloaded and started testing latest snapshot.
>
> > ODBC works correctly :) ctlib not :(
> > - cancel test fails. It gets all rows instead of stopping...
> > I don't understand why and enabling logging just core cause
> > tdsdump_log is not reentrant...
>
> I find the behaviour od the ctlib/unittest/cancel is erratic.
> sometimes test passes other times not. so...
>
> cancel.c: Check asynchronous called ct_cancel()
> ct_results() result_type CS_CMD_FAIL.
> More results?...
> - SIGALRM
> ct_fetch() unexpected return -1 on row 7164.
> do_fetch() returned: 1
> More results?...
> do_fetch retrieved 10000 rows
> do_fetch() returned: 0
> More results?...
> cancel.c: asynchronous cancel test: PASSED
> PASS: cancel
>
> OR...
>
> cancel.c: Check asynchronous called ct_cancel()
> ct_results() result_type CS_CMD_FAIL.
> More results?...
> do_fetch retrieved 10000 rows
> do_fetch() returned: 0
> More results?...
> All rows read, this may not occur.
> FAIL: cancel
>
It seems that it fetched all rows before SIGALRM !!! Very strange
however I must say that usually it stops at 4000 in my tests so perhaps
you are right and our library is too fast :). I don't know how accurate
can be the timer... I don't know if it's better to increase row count or
decrease timeout...
> So I think sometimes the program/database just too fast for the test
> sometimes.
>
> If you enable TDSDUMP it always pass (because program always much
> slower),
> but it produce 27Mb TDSDUMP file ! I don't get core dump.
>
Perhaps it fail in my environment cause I use to append debug info. If
you enable debug file is closed and opened many time so you can free
FILE* in a signal causing corruption... not that funny!!
> I'll look further at the problem and at the cursor free-ing issue.
> I also don't see this problem , but my old compiler probably doesn't
> notice the issue.
>
> Bill
>
I used a memory debugger to discover the issue (valgrind). It's not
portable however I would suggest ElectricFence under other environments.
The problem is that after tds_cursor_dealloc you don't know when libTDS
free TDSCURSOR structure so it's better to clear reference and do not
use memory anymore... I noted however that in ct_cmd_props you can read
cursor status after deallocation (ct_cursor test line 256)... is it
true?
freddy77
-
[freetds] [ freetds-Patches-1120675 ] new features in ctlib,
SourceForge.net, 02/11/2005
- <Possible follow-up(s)>
-
RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib,
Thompson, Bill D (London), 02/11/2005
- RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib, Frediano Ziglio, 02/11/2005
- RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib, ZIGLIO, Frediano, VF-IT, 02/14/2005
-
RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib,
Thompson, Bill D (London), 02/16/2005
-
RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib,
Frediano Ziglio, 02/16/2005
- RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib, Frediano Ziglio, 02/16/2005
-
RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib,
Frediano Ziglio, 02/16/2005
- [freetds] [ freetds-Patches-1120675 ] new features in ctlib, SourceForge.net, 02/17/2005
- RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib, Thompson, Bill D (London), 02/17/2005
- RE: [freetds] [ freetds-Patches-1120675 ] new features in ctlib, ZIGLIO, Frediano, VF-IT, 02/17/2005
Archive powered by MHonArc 2.6.24.