Thread: [Sqlrelay-discussion] Issue with Microsoft SQL/FreeTDS and SQLRelay
Brought to you by:
mused
From: Stephen b. <sql...@ca...> - 2012-04-19 22:32:15
|
David, List, We are trying to upgrade from an older installation of SQLRelay... SQLRelay 0.39.4 Rudiments 0.31 FreeTDS 0.63 to the latest version SQLRelay 0.45 Rudiments 0.36 FreeTDS 0.91 FreeTDS compiles and builds, can connect to the database (Microsoft SQL 2008) with no issues using their tsql utility. freetds.conf *[callemall] host = XXXX.XXXX.com port = 1433 tds version = 8.0 dump file = /tmp/freetds.log debug flags = 0xffff timeout = 45 connect timeout = 10 * _*freetds "tsql" tool...*_ *root@VM-MXTelecom:/usr/local/src/freetds-0.91/src/apps# ./tsql -S callemall -U XXXX -P XXXXX locale is "en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" 1> use callemall; 2> go 1> select count(*) from tbcdr; 2> go 2513548 (1 row affected) 1> select db_name(); 2> go callemall (1 row affected) 1> quit * I turn on SQL trace and IP sniffers and what happens is this... I start up requesting 5 connection to the database, SQLRelay starts, but after the startup script is done there are NO running sqlr-connection-freetds processes running. _*When I try to perform a Query ::*_ *SQLRShell - Version 0.22 Connected to: localhost:9000 as CEA-RW type help; for a help. 0> select count(*) from tbcdr; * It hangs indefinitely but the status changes to this... Open Server Connections: 5 Opened Server Connections: 5 Open Client Connections: 0 Opened Client Connections: 0 Open Server Cursors: 15 Opened Server Cursors: 20 Times New Cursor Used: 0 Times Cursor Reused: 0 Total Queries: 5 Total Errors: 0 Forked Listeners: *1 <-----* Scaler's view: Connections: 5 Sessions: *1 <----* Semaphores: +---------------------------------------------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | +---+---+---+---+---+---+---+---+---+---+-----+ | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | +---------------------------------------------+ When I started SQLRelay the sqlr-connection-freetds *did* connect to the Database, log in and perform some queries such as "select db_name()" and "use callemall" etc.. I was able to see these with my SQL Server Trace and my IP Sniffer My sqlrelay.conf file: *<?xml version="1.0"?> <!DOCTYPE instances SYSTEM "sqlrelay.dtd"> <instances> <instance id="CEA" port="9000" socket="/tmp/cea.socket" dbase="freetds" connections="5" maxconnections="10" maxqueuelength="0" growby="1" ttl="60" maxsessioncount="10" endofsession="commit" sessiontimeout="600" runasuser="nobody" runasgroup="nobody" cursors="3" authtier="listener" handoff="pass" maxquerysize="65536" maxstringbindvaluelength="4000" maxlobbindvaluelength="71680" idleclienttimeout="-1" maxlisteners="-1" listenertimeout="0" reloginatstart="no" timequeriessec="0" timequeriesusec="0" debug="none"> <users> <user user="XXXX" password="XXXX" /> </users> <connections> <connection connectionid="CEA" string="server=callemall;db=callemall;user=XXXX;password=XXXX;" metric="1" behindloadbalancer="no" /> </connections> </instance> </instances> * I compiled in debug mode and am able to step through connecting, creating the connection including the cursors, but when I reach sqlrconnection/main.cpp:82 int sqlrconnection_svr::main(int argc, const char **argv, sqlrconnection_svr *c) { #include <version.h> conn=c; // handle signals sigh=conn->handleSignals(sqlrconnection_svr::shutDown); // open the connection to the db bool result=false; if ((result=conn->initConnection(argc,argv))) { // wait for client connections *result=conn->listen(); <---- SIGSEGV* } // If sqlr-stop has been run, we may be here because the sqlr-listener // has been killed. In that case, we'll get a SIGINT soon, but we // want to ignore it and just let the shutdown proceed normally, // otherwise we could be halfway through cleanUp() below when we // get it, which will ultimately run cleanUp() again and result in // double-free's and a crash. If we happen to receive the SIGINT // before this point, then the shutdown will proceed that way. shutdowninprogress=1; // unsuccessful completion cleanUp(); // return successful or unsuccessful completion based on listenresult process::exit((result)?0:1); } I get the following error: *Program received signal SIGSEGV, Segmentation fault. 0xb7c0cca1 in memcpy () from /lib/i686/cmov/libc.so.6 * Any assistance would be appreciated, I have really been trying almost everything that I can think of, this is a completely clean Debian Virtual machine with the base packages then I added.. apt-get install gcc apt-get install g++ apt-get install make and then retrieved the packages.. cd /usr/local/src wget http://prdownloads.sourceforge.net/sqlrelay/sqlrelay-0.45.tar.gz wget http://prdownloads.sourceforge.net/rudiments/rudiments-0.36.tar.gz wget http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz Of course I have since added gdb and ddd to debug but I am at the end of my resources without some further input.. -- Respectfully, *Stephen Barclay* Partner, Telecom Engineer www.call-em-all.com Direct: 972.893.3119 |
From: David M. <dav...@fi...> - 2012-04-25 02:03:31
|
Hi Stephen, Sounds like a bug. I'll do some tests using your configuration, see what I get and let you know. Dave dav...@fi... On 04/19/2012 06:32 PM, Stephen barclay wrote: > David, List, > > We are trying to upgrade from an older installation of SQLRelay... > > SQLRelay 0.39.4 > Rudiments 0.31 > FreeTDS 0.63 > > to the latest version > > SQLRelay 0.45 > Rudiments 0.36 > FreeTDS 0.91 > > > FreeTDS compiles and builds, can connect to the database (Microsoft > SQL 2008) > with no issues using their tsql utility. > > freetds.conf > > *[callemall] > host = XXXX.XXXX.com > port = 1433 > tds version = 8.0 > dump file = /tmp/freetds.log > debug flags = 0xffff > timeout = 45 > connect timeout = 10 > > * > _*freetds "tsql" tool...*_ > > *root@VM-MXTelecom:/usr/local/src/freetds-0.91/src/apps# ./tsql -S > callemall -U XXXX -P XXXXX > locale is "en_US.UTF-8" > locale charset is "UTF-8" > using default charset "UTF-8" > 1> use callemall; > 2> go > 1> select count(*) from tbcdr; > 2> go > > 2513548 > (1 row affected) > 1> select db_name(); > 2> go > > callemall > (1 row affected) > 1> quit > > * > I turn on SQL trace and IP sniffers and what happens is this... I > start up requesting > 5 connection to the database, SQLRelay starts, but after the startup > script is done > there are NO running sqlr-connection-freetds processes running. > > > _*When I try to perform a Query ::*_ > > *SQLRShell - Version 0.22 > Connected to: localhost:9000 as CEA-RW > > type help; for a help. > > 0> select count(*) from tbcdr; > > * > It hangs indefinitely but the status changes to this... > > Open Server Connections: 5 > Opened Server Connections: 5 > > Open Client Connections: 0 > Opened Client Connections: 0 > > Open Server Cursors: 15 > Opened Server Cursors: 20 > > Times New Cursor Used: 0 > Times Cursor Reused: 0 > > Total Queries: 5 > Total Errors: 0 > > Forked Listeners: *1 <-----* > > Scaler's view: > Connections: 5 > Sessions: *1 <----* > > Semaphores: > +---------------------------------------------+ > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | > +---+---+---+---+---+---+---+---+---+---+-----+ > | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | > +---------------------------------------------+ > > When I started SQLRelay the sqlr-connection-freetds *did* connect to > the Database, > log in and perform some queries such as "select db_name()" and "use > callemall" etc.. > > I was able to see these with my SQL Server Trace and my IP Sniffer > > My sqlrelay.conf file: > > *<?xml version="1.0"?> > <!DOCTYPE instances SYSTEM "sqlrelay.dtd"> > <instances> > <instance id="CEA" > port="9000" > socket="/tmp/cea.socket" > dbase="freetds" > connections="5" > maxconnections="10" > maxqueuelength="0" > growby="1" > ttl="60" > maxsessioncount="10" > endofsession="commit" > sessiontimeout="600" > runasuser="nobody" > runasgroup="nobody" > cursors="3" > authtier="listener" > handoff="pass" > maxquerysize="65536" > maxstringbindvaluelength="4000" > maxlobbindvaluelength="71680" > idleclienttimeout="-1" > maxlisteners="-1" > listenertimeout="0" > reloginatstart="no" > timequeriessec="0" > timequeriesusec="0" > debug="none"> > <users> > <user > user="XXXX" > password="XXXX" > /> > </users> > <connections> > <connection > connectionid="CEA" > > string="server=callemall;db=callemall;user=XXXX;password=XXXX;" > metric="1" > behindloadbalancer="no" > /> > </connections> > </instance> > </instances> > * > I compiled in debug mode and am able to step through connecting, > creating the connection > including the cursors, but when I reach sqlrconnection/main.cpp:82 > > int sqlrconnection_svr::main(int argc, const char **argv, > sqlrconnection_svr *c) { > > #include <version.h> > > conn=c; > > // handle signals > sigh=conn->handleSignals(sqlrconnection_svr::shutDown); > > // open the connection to the db > bool result=false; > if ((result=conn->initConnection(argc,argv))) { > // wait for client connections > *result=conn->listen(); <---- SIGSEGV* > } > > // If sqlr-stop has been run, we may be here because the > sqlr-listener > // has been killed. In that case, we'll get a SIGINT soon, but we > // want to ignore it and just let the shutdown proceed normally, > // otherwise we could be halfway through cleanUp() below when we > // get it, which will ultimately run cleanUp() again and result in > // double-free's and a crash. If we happen to receive the SIGINT > // before this point, then the shutdown will proceed that way. > shutdowninprogress=1; > > // unsuccessful completion > cleanUp(); > > // return successful or unsuccessful completion based on > listenresult > process::exit((result)?0:1); > } > > > I get the following error: > > *Program received signal SIGSEGV, Segmentation fault. > 0xb7c0cca1 in memcpy () from /lib/i686/cmov/libc.so.6 > * > Any assistance would be appreciated, I have really been trying almost > everything that I can > think of, this is a completely clean Debian Virtual machine with the > base packages then I added.. > > apt-get install gcc > apt-get install g++ > apt-get install make > > and then retrieved the packages.. > > cd /usr/local/src > > wget http://prdownloads.sourceforge.net/sqlrelay/sqlrelay-0.45.tar.gz > wget http://prdownloads.sourceforge.net/rudiments/rudiments-0.36.tar.gz > wget http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz > > Of course I have since added gdb and ddd to debug but I am at the end > of my > resources without some further input.. > > > -- > > Respectfully, > > > *Stephen Barclay* > Partner, Telecom Engineer > www.call-em-all.com > Direct: 972.893.3119 > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com |
From: David M. <dav...@fi...> - 2012-04-25 02:20:01
|
Weird. Your configuration works fine for me. I had to change the server and db values in the connect string, but otherwise I left it the same. Any chance I could get onto your system and debug it there? Feel free to contact me directly. dav...@fi... Dave On 04/24/2012 10:00 PM, David Muse wrote: > Hi Stephen, > > Sounds like a bug. I'll do some tests using your configuration, see > what I get and let you know. > > Dave > dav...@fi... > > On 04/19/2012 06:32 PM, Stephen barclay wrote: >> David, List, >> >> We are trying to upgrade from an older installation of SQLRelay... >> >> SQLRelay 0.39.4 >> Rudiments 0.31 >> FreeTDS 0.63 >> >> to the latest version >> >> SQLRelay 0.45 >> Rudiments 0.36 >> FreeTDS 0.91 >> >> >> FreeTDS compiles and builds, can connect to the database (Microsoft >> SQL 2008) >> with no issues using their tsql utility. >> >> freetds.conf >> >> *[callemall] >> host = XXXX.XXXX.com >> port = 1433 >> tds version = 8.0 >> dump file = /tmp/freetds.log >> debug flags = 0xffff >> timeout = 45 >> connect timeout = 10 >> >> * >> _*freetds "tsql" tool...*_ >> >> *root@VM-MXTelecom:/usr/local/src/freetds-0.91/src/apps# ./tsql -S >> callemall -U XXXX -P XXXXX >> locale is "en_US.UTF-8" >> locale charset is "UTF-8" >> using default charset "UTF-8" >> 1> use callemall; >> 2> go >> 1> select count(*) from tbcdr; >> 2> go >> >> 2513548 >> (1 row affected) >> 1> select db_name(); >> 2> go >> >> callemall >> (1 row affected) >> 1> quit >> >> * >> I turn on SQL trace and IP sniffers and what happens is this... I >> start up requesting >> 5 connection to the database, SQLRelay starts, but after the startup >> script is done >> there are NO running sqlr-connection-freetds processes running. >> >> >> _*When I try to perform a Query ::*_ >> >> *SQLRShell - Version 0.22 >> Connected to: localhost:9000 as CEA-RW >> >> type help; for a help. >> >> 0> select count(*) from tbcdr; >> >> * >> It hangs indefinitely but the status changes to this... >> >> Open Server Connections: 5 >> Opened Server Connections: 5 >> >> Open Client Connections: 0 >> Opened Client Connections: 0 >> >> Open Server Cursors: 15 >> Opened Server Cursors: 20 >> >> Times New Cursor Used: 0 >> Times Cursor Reused: 0 >> >> Total Queries: 5 >> Total Errors: 0 >> >> Forked Listeners: *1 <-----* >> >> Scaler's view: >> Connections: 5 >> Sessions: *1 <----* >> >> Semaphores: >> +---------------------------------------------+ >> | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | >> +---+---+---+---+---+---+---+---+---+---+-----+ >> | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | >> +---------------------------------------------+ >> >> When I started SQLRelay the sqlr-connection-freetds *did* connect to >> the Database, >> log in and perform some queries such as "select db_name()" and "use >> callemall" etc.. >> >> I was able to see these with my SQL Server Trace and my IP Sniffer >> >> My sqlrelay.conf file: >> >> *<?xml version="1.0"?> >> <!DOCTYPE instances SYSTEM "sqlrelay.dtd"> >> <instances> >> <instance id="CEA" >> port="9000" >> socket="/tmp/cea.socket" >> dbase="freetds" >> connections="5" >> maxconnections="10" >> maxqueuelength="0" >> growby="1" >> ttl="60" >> maxsessioncount="10" >> endofsession="commit" >> sessiontimeout="600" >> runasuser="nobody" >> runasgroup="nobody" >> cursors="3" >> authtier="listener" >> handoff="pass" >> maxquerysize="65536" >> maxstringbindvaluelength="4000" >> maxlobbindvaluelength="71680" >> idleclienttimeout="-1" >> maxlisteners="-1" >> listenertimeout="0" >> reloginatstart="no" >> timequeriessec="0" >> timequeriesusec="0" >> debug="none"> >> <users> >> <user >> user="XXXX" >> password="XXXX" >> /> >> </users> >> <connections> >> <connection >> connectionid="CEA" >> >> string="server=callemall;db=callemall;user=XXXX;password=XXXX;" >> metric="1" >> behindloadbalancer="no" >> /> >> </connections> >> </instance> >> </instances> >> * >> I compiled in debug mode and am able to step through connecting, >> creating the connection >> including the cursors, but when I reach sqlrconnection/main.cpp:82 >> >> int sqlrconnection_svr::main(int argc, const char **argv, >> sqlrconnection_svr *c) { >> >> #include <version.h> >> >> conn=c; >> >> // handle signals >> sigh=conn->handleSignals(sqlrconnection_svr::shutDown); >> >> // open the connection to the db >> bool result=false; >> if ((result=conn->initConnection(argc,argv))) { >> // wait for client connections >> *result=conn->listen(); <---- SIGSEGV* >> } >> >> // If sqlr-stop has been run, we may be here because the >> sqlr-listener >> // has been killed. In that case, we'll get a SIGINT soon, >> but we >> // want to ignore it and just let the shutdown proceed normally, >> // otherwise we could be halfway through cleanUp() below when we >> // get it, which will ultimately run cleanUp() again and >> result in >> // double-free's and a crash. If we happen to receive the SIGINT >> // before this point, then the shutdown will proceed that way. >> shutdowninprogress=1; >> >> // unsuccessful completion >> cleanUp(); >> >> // return successful or unsuccessful completion based on >> listenresult >> process::exit((result)?0:1); >> } >> >> >> I get the following error: >> >> *Program received signal SIGSEGV, Segmentation fault. >> 0xb7c0cca1 in memcpy () from /lib/i686/cmov/libc.so.6 >> * >> Any assistance would be appreciated, I have really been trying almost >> everything that I can >> think of, this is a completely clean Debian Virtual machine with the >> base packages then I added.. >> >> apt-get install gcc >> apt-get install g++ >> apt-get install make >> >> and then retrieved the packages.. >> >> cd /usr/local/src >> >> wget http://prdownloads.sourceforge.net/sqlrelay/sqlrelay-0.45.tar.gz >> wget http://prdownloads.sourceforge.net/rudiments/rudiments-0.36.tar.gz >> wget http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz >> >> Of course I have since added gdb and ddd to debug but I am at the end >> of my >> resources without some further input.. >> >> >> -- >> >> Respectfully, >> >> >> *Stephen Barclay* >> Partner, Telecom Engineer >> www.call-em-all.com >> Direct: 972.893.3119 >> >> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com >> >> >> _______________________________________________ >> Sqlrelay-discussion mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com > |
From: David M. <dav...@fi...> - 2012-04-30 18:15:36
|
Thanks for tracking that down. I'll do some tests and see if I can come up with a solid fix. Dave dav...@fi... On 04/30/2012 01:03 PM, Stephen barclay wrote: > David, > > Sorry for the delay, I just got back from vacation.. > > I tracked the issue down to what appears to be a non terminated string... > > In listenercomm.cpp when the charstring::copy is called, the data > overflows and > corrupts the shared memory segment. > > > > > My temp fix to get things going was to set all of my ConnectionID's to > <= 4 bytes > > ie CEA, CEAS, TEST, PROD, WORK, DEMO and change the following value in > /src/common/defines.h > > #define MAXCONNECTIONIDLEN *4 *(originally 1024) > > > This fixed the issue and I am up and running.. > > Hopefully this might give you some insight into what the > issue might be.. > > > -- > > Respectfully, > > > *Stephen Barclay* > Partner, Telecom Engineer > www.call-em-all.com > Direct: 972.893.3119 > |
From: David M. <dav...@fi...> - 2012-05-01 14:01:56
|
Stephen, I discovered the root of the problem. In the rudiments library, in the src/charstring.cpp file, around line 842, there is a method "copy" like: char *charstring::copy(char *dest, const char *source, size_t size) { return (char *)rawbuffer::copy((void *)dest,(const void *)source,size); } which should be: char *charstring::copy(char *dest, const char *source, size_t size) { return strncpy(dest,source,size); } I had changed it to get around an issue on windows but the change is not equivalent, and actually somewhat foolish. strncpy will stop when it finds a NULL terminator, but rawbuffer::copy will copy "size" bytes even if the string isn't that long, which can cause a segfault. I'm surprised that I didn't run into it during my testing. I just made that change in the last release of rudiments, which is why it just popped up now. I'll make an updated release with a fix later today but that's a quick fix. Dave dav...@fi... On 04/30/2012 02:15 PM, David Muse wrote: > Thanks for tracking that down. I'll do some tests and see if I can > come up with a solid fix. > > Dave > dav...@fi... > > On 04/30/2012 01:03 PM, Stephen barclay wrote: >> David, >> >> Sorry for the delay, I just got back from vacation.. >> >> I tracked the issue down to what appears to be a non terminated >> string... >> >> In listenercomm.cpp when the charstring::copy is called, the data >> overflows and >> corrupts the shared memory segment. >> >> >> >> >> My temp fix to get things going was to set all of my ConnectionID's >> to <= 4 bytes >> >> ie CEA, CEAS, TEST, PROD, WORK, DEMO and change the following value >> in /src/common/defines.h >> >> #define MAXCONNECTIONIDLEN *4 *(originally 1024) >> >> >> This fixed the issue and I am up and running.. >> >> Hopefully this might give you some insight into what the >> issue might be.. >> >> >> -- >> >> Respectfully, >> >> >> *Stephen Barclay* >> Partner, Telecom Engineer >> www.call-em-all.com >> Direct: 972.893.3119 >> |