Re: [Sqlrelay-discussion] Weird connection problem
Brought to you by:
mused
Menu
▾
▴
Re: [Sqlrelay-discussion] Weird connection problem
|
From: David M. <dav...@fi...> - 2011-10-28 18:44:13
|
Oh, I see the problem. Man, I think this has been here a while. In the client API, there was an uninitialized variable. I fixed it and the fix is in CVS. For a quick fix, edit src/api/c++/src/connection/connectionctor.C and around line 41, add the following line: serverversion=NULL; Then rebuild and reinstall and it should fix the problem. David Muse dav...@fi... On 10/28/2011 02:34 PM, David Muse wrote: > Weird. I just tested it and it crashes for me too. I should be able > to figure it out pretty quickly. I'll let you know what I find. > > Dave > > On 10/26/2011 05:59 AM, Freako F. Freakolowsky wrote: >> If it helps anyone, here's the GDB backtrace >> >> root@devwww:~# gdb sqlrsh >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>... >> Reading symbols from /opt/sqlrelay/bin/sqlrsh...(no debugging symbols >> found)...done. >> (gdb) run localhost 9000 "" scott tiger >> Starting program: /opt/sqlrelay/bin/sqlrsh localhost 9000 "" scott tiger >> [Thread debugging using libthread_db enabled] >> SQLRShell - Version 0.22 >> Connected to: localhost:9000 as scott >> >> type help; for a help. >> >> 0> serverversion; >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff555ae2d in free () from /lib/libc.so.6 >> (gdb) backtrace >> #0 0x00007ffff555ae2d in free () from /lib/libc.so.6 >> #1 0x00007ffff79b287c in sqlrconnection::serverVersion() () from >> /opt/sqlrelay/lib/libsqlrclient-0.43.so.1 >> #2 0x0000000000403a41 in sqlrsh::serverversion(sqlrconnection*, >> environment*) () >> #3 0x0000000000403080 in sqlrsh::internalCommand(sqlrconnection*, >> sqlrcursor*, environment*, char const*) () >> #4 0x0000000000402a2f in sqlrsh::runCommand(sqlrconnection*, >> sqlrcursor*, environment*, char const*) () >> #5 0x000000000040413b in sqlrsh::interactWithUser(sqlrconnection*, >> sqlrcursor*, environment*) () >> #6 0x0000000000404739 in sqlrsh::execute(int, char const**) () >> #7 0x0000000000404a9c in main () >> (gdb) >> >> >> On 25. 10. 2011 16:09, Freako F. Freakolowsky wrote: >>> I just installed the latest sqlrelay version but i'm now facing a >>> strange issue when using it. >>> >>> I start the sqlr stack normaly trough the init script (ubuntu server). >>> >>> I can then connect through sqlrsh ... no problems yet. >>> running ping, dbversion, clientversion works normally. >>> >>> running serverversion segfaults. >>> >>> but the strangest thing is when running a query ...it freezes the >>> shell, however uppon inspecting the connection's debug file i see that >>> query gets executed >>> >>> any ideas on where to start looking for misconfiguration or bug ? >>> >>> DB is Oracle 11g >>> >>> pasting a part of connection's debug log >>> >>> 10/25/2011 16:05:23 CEST connection [28218] : new query >>> 10/25/2011 16:05:23 CEST connection [28218] : handling query... >>> 10/25/2011 16:05:23 CEST connection [28218] : getting query... >>> 10/25/2011 16:05:23 CEST connection [28218] : querylength: >>> 18 >>> 10/25/2011 16:05:23 CEST connection [28218] : query: >>> 10/25/2011 16:05:23 CEST connection [28218] : select 1 from dual >>> 10/25/2011 16:05:23 CEST connection [28218] : getting query >>> succeeded >>> 10/25/2011 16:05:23 CEST connection [28218] : getting input >>> binds... >>> 10/25/2011 16:05:23 CEST connection [28218] : done getting >>> input binds >>> 10/25/2011 16:05:23 CEST connection [28218] : getting output >>> binds... >>> 10/25/2011 16:05:23 CEST connection [28218] : done getting >>> output binds >>> 10/25/2011 16:05:23 CEST connection [28218] : getting send >>> column info... >>> 10/25/2011 16:05:23 CEST connection [28218] : send >>> column info >>> 10/25/2011 16:05:23 CEST connection [28218] : done getting >>> send column info... >>> 10/25/2011 16:05:23 CEST connection [28218] : processing >>> query... >>> 10/25/2011 16:05:23 CEST connection [28218] : >>> preparing/executing... >>> 10/25/2011 16:05:23 CEST connection [28218] : commit or >>> rollback check... >>> 10/25/2011 16:05:23 CEST connection [28218] : done with commit >>> or rollback check >>> 10/25/2011 16:05:23 CEST connection [28218] : processing query >>> succeeded >>> 10/25/2011 16:05:23 CEST connection [28218] : done processing >>> query >>> 10/25/2011 16:05:23 CEST connection [28218] : returning result >>> set header... >>> 10/25/2011 16:05:23 CEST connection [28218] : returning >>> row counts... >>> 10/25/2011 16:05:23 CEST connection [28218] : sending row >>> counts... >>> 10/25/2011 16:05:23 CEST connection [28218] : actual rows >>> unknown >>> 10/25/2011 16:05:23 CEST connection [28218] : affected >>> rows: 0 >>> 10/25/2011 16:05:23 CEST connection [28218] : done sending row >>> counts >>> 10/25/2011 16:05:23 CEST connection [28218] : done >>> returning row counts >>> 10/25/2011 16:05:23 CEST connection [28218] : column info >>> will be sent >>> 10/25/2011 16:05:23 CEST connection [28218] : returning >>> column counts... >>> 10/25/2011 16:05:23 CEST connection [28218] : done >>> returning column counts >>> 10/25/2011 16:05:23 CEST connection [28218] : sending column >>> type format... >>> 10/25/2011 16:05:23 CEST connection [28218] : id's >>> 10/25/2011 16:05:23 CEST connection [28218] : done sending >>> column type format >>> 10/25/2011 16:05:23 CEST connection [28218] : returning >>> column info... >>> 10/25/2011 16:05:23 CEST connection [28218] : 1:48:2 >>> (0,129) >>> 10/25/2011 16:05:23 CEST connection [28218] : done >>> returning column info >>> 10/25/2011 16:05:23 CEST connection [28218] : returning output >>> bind values >>> 0 >>> 10/25/2011 16:05:23 CEST connection [28218] : done returning >>> output bind values >>> 10/25/2011 16:05:23 CEST connection [28218] : done returning >>> result set header >>> 10/25/2011 16:05:23 CEST connection [28218] : handle query >>> succeeded >>> 10/25/2011 16:05:23 CEST connection [28218] : returning result >>> set data... >>> 10/25/2011 16:05:23 CEST connection [28218] : skipping 0 >>> rows... >>> 10/25/2011 16:05:23 CEST connection [28218] : done skipping >>> rows >>> 10/25/2011 16:05:23 CEST connection [28218] : fetching 100 >>> rows... >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> The demand for IT networking professionals continues to grow, and the >>> demand for specialized networking skills is growing even more rapidly. >>> Take a complimentary Learning@Cisco Self-Assessment and learn >>> about Cisco certifications, training, and career opportunities. >>> http://p.sf.net/sfu/cisco-dev2dev >>> >>> >>> _______________________________________________ >>> Sqlrelay-discussion mailing list >>> Sql...@li... >>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> ------------------------------------------------------------------------------ >> >> The demand for IT networking professionals continues to grow, and the >> demand for specialized networking skills is growing even more rapidly. >> Take a complimentary Learning@Cisco Self-Assessment and learn >> about Cisco certifications, training, and career opportunities. >> http://p.sf.net/sfu/cisco-dev2dev >> _______________________________________________ >> 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 > _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
