sqlrelay-discussion Mailing List for SQL Relay (Page 48)
Brought to you by:
mused
Menu
▾
▴
sqlrelay-discussion — Discussion of topics related to SQL Relay
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(20) |
Mar
(27) |
Apr
(17) |
May
(32) |
Jun
(45) |
Jul
(49) |
Aug
(68) |
Sep
(44) |
Oct
(29) |
Nov
(64) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(61) |
Feb
(22) |
Mar
(25) |
Apr
(31) |
May
(18) |
Jun
(28) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(17) |
Nov
(32) |
Dec
(4) |
| 2007 |
Jan
(20) |
Feb
(25) |
Mar
(5) |
Apr
(12) |
May
(11) |
Jun
(18) |
Jul
(16) |
Aug
(22) |
Sep
(37) |
Oct
(20) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(11) |
Feb
(33) |
Mar
(12) |
Apr
(18) |
May
(22) |
Jun
(31) |
Jul
(23) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(22) |
Dec
|
| 2009 |
Jan
(12) |
Feb
(8) |
Mar
(11) |
Apr
(20) |
May
(18) |
Jun
(7) |
Jul
(27) |
Aug
(2) |
Sep
(10) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(11) |
Feb
(18) |
Mar
(10) |
Apr
(28) |
May
(28) |
Jun
|
Jul
(27) |
Aug
(9) |
Sep
(21) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
| 2011 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(44) |
Jul
(9) |
Aug
(2) |
Sep
(12) |
Oct
(7) |
Nov
(11) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
(9) |
May
(12) |
Jun
|
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(10) |
| 2013 |
Jan
(21) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
| 2014 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rodrigo P. T. <te...@de...> - 2006-01-04 12:34:38
|
Hi David, At last I think we (our team) found a cause of the exception! I think there was a misunderstood from my part in that answer (about "long queries"). I understood "long queries" as "long result sets" - and not the lenght of the queries - when in fact the queries has about 397-580 characters. I don't know if it's big enough to be considered "long" but it's the cause of the problem. If we changes that long queries to small ones (selecting or updating only 3 fields instead of 34) the problem go away and everything works fine. Problematic query: SELECT phplib_id, username, domain, password, first_name, last_name, phone, email_address, datetime_created, datetime_modified, confirmation, flag, sendnotification, greeting, ha1, ha1b, perms, allow_find, timezone, rpid, empresa, codInscricao, numInscricao, endereco, bairro, cep, cidade, estado, pais, listaPublica, sigame, temSigame, status, macAddress FROM subscriber WHERE username='2740' Solution query: SELECT phplib_id, username, first_name FROM subscriber WHERE username='2740' So as you said perhaps it's easy to patch. We'll test with how many fields the query starts to generate an exception. best regards, Telles Rodrigo P. Telles wrote: > Hi David, > > Firstworks/4access wrote: > > >Is it possible to reliably reproduce the problem with a particular > >query, or is it kind of random? > > > No it doesn't, it happens in a random fashion. Could happens twice in > a week or > once in a month. > > >Offhand, it looks like java is trying to run (or return from) a native > >C++ function and has the wrong address for the function (or wrong return > >address) and it ends up jumping off into the weeds, possibly into a > >non-executable page of memory. This typically happens when a buffer > >overrun occurs and overwrites a jump address. > > >Does this happen with really long queries? With > > > No it doesn't. > It happens in a simple query using INSERT or SELECT! > > >Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >It's possible that there's some kind of bug where the SQL Relay client > >is copying too much data and overrunning it's buffer. If it's only long > >queries, that would make sense and should be easy to patch. > > >Let me know... > > > Let me know if I can do any thing to "collect" more informations about > that problem. > Thanks for your answer. > > Telles > > >David Muse > >dav...@fi... > > >On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > > >Hi Guys, > > >I've been experiencing some errors using JAVA with sqlrelay-0.35 API > and MySQL > >4.1.7 as a DB backend. > > >Some thimes when I'm doing a query the application failed with that > output > >exception: > >---------------------------------------------------------------------------------- > >An unexpected exception has been detected in native code outside the VM. > >Unexpected Signal : 11 occurred at PC=0x400C6C48 > >Function=(null)+0x400C6C48 > >Library=/lib/libc.so.6 > > >NOTE: We are unable to locate the function name symbol for the error > > just occurred. Please refer to release documentation for possible > > reason and solutions. > > > >Current Java thread: > > at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > > at it.devel.Dao.getBean(Dao.java:185) > > at > it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > > at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > > at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > > at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > > at it.devel.Bilhetagem.main(Bilhetagem.java:693) > > >Dynamic libraries: > >08048000-08056000 r-xp 00000000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >08056000-08059000 rwxp 0000d000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >40173000-4056f000 r-xp 00000000 08:06 134540 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >4056f000-4058b000 rwxp 003fb000 08:06 134540 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >405d5000-405dd000 r-xp 00000000 08:06 101710 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >405dd000-405de000 rwxp 00007000 08:06 101710 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >405de000-405e2000 rwxs 00000000 08:09 14628 > /tmp/hsperfdata_callstart/19866 > >405e3000-405ec000 r-xp 00000000 08:05 213015 > /lib/libnss_files-2.3.3.so > >405ec000-405ed000 rwxp 00009000 08:05 213015 > /lib/libnss_files-2.3.3.so > >405ed000-405fd000 r-xp 00000000 08:06 101717 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >405fd000-405ff000 rwxp 0000f000 08:06 101717 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >405ff000-4061f000 r-xp 00000000 08:06 101718 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >4061f000-40621000 rwxp 0001f000 08:06 101718 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >40621000-40635000 r-xp 00000000 08:06 101720 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >40635000-40638000 rwxp 00013000 08:06 101720 > >/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >40638000-41fdf000 r-xs 00000000 08:06 101803 > >/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >42029000-4203f000 r-xs 00000000 08:06 101742 > >/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >4203f000-4211c000 r-xs 00000000 08:06 101787 > >/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >4211c000-4212d000 r-xs 00000000 08:06 101743 > >/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >4212d000-42686000 r-xs 00000000 08:06 101788 > >/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >4472e000-4472f000 r-xs 00000000 08:06 117021 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >4c92a000-4c930000 r-xs 00000000 08:06 117025 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >4c930000-4c936000 r-xs 00000000 08:06 117026 > >/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >4c936000-4c939000 r-xp 00000000 08:06 377923 > >/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >4c939000-4c93a000 rwxp 00002000 08:06 377923 > >/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >4c93a000-4c950000 r-xp 00000000 08:06 265533 > >/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >4c950000-4c953000 rwxp 00015000 08:06 265533 > >/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >4c953000-4c998000 r-xp 00000000 08:06 377564 > >/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >4c9d5000-4caab000 r-xp 00000000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >4caab000-4cabc000 rwxp 000d6000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >4caec000-4cb8a000 r-xp 00000000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > > >Heap at VM Abort: > >Heap > > def new generation total 576K, used 236K [0x44730000, 0x447d0000, > 0x44c10000) > > eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > > from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > > to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > > tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, > 0x48730000) > > the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, > 0x44d70000) > > compacting perm gen total 4096K, used 1696K [0x48730000, > 0x48b30000, 0x4c730000) > > the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, > 0x48b30000) > > >Local Time = Fri Nov 11 15:34:29 2005 > >Elapsed Time = 771 > ># > ># The exception above was detected in native code outside the VM > ># > ># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >- > >-------------------------------------------------------------------------------------------------------- > > >At the moment is not so easy for me to update to 0.36.x. > >Does some one can help with that problem? > > >Thanks in advance. > >-- > >============================================ > >Rodrigo P. Telles <te...@de...> > >IT Manager > >Devel-IT - http://www.devel.it > >IVOZ # 1029 > >+55 14 3324-1200 > >Bestcom Group > >============================================ > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >Register for a JBoss Training Course. Free Certification Exam > >for All Training Attendees Through End of 2005. For more info visit: > >http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >_______________________________________________ > >Sqlrelay-discussion mailing list > >Sql...@li... > >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > |
|
From: David M. <dav...@fi...> - 2006-01-03 22:40:06
|
On Tue, 2006-01-03 at 16:36 -0500, Kelly Shum wrote: > Hello All, > > > > Is there a way to configure the listener so that there is no > authentication required? I know that there is the AuthTier setting > for listener, connection, listener and connection and database, but is > there a way to disable authentication to the sqlrelay port all > together? Thanks. > > > > Kelly Shum > > > > There was once a way to do that, and though I don't remember doing it, I appear to have removed that feature :) A quick hack to disable authentication though: edit src/util/authenticator.C and change the second-to-last line from: return false; to: return true; Then set authtier="listener" or authtier="connection" in the config file. David Muse dav...@fi... |
|
From: Biswa C. <Bis...@na...> - 2006-01-03 21:51:04
|
Hello All,
When calling an Oracle procedure that returns more than one ref cursor,
SQLRelay returns the same data for all the ref cursors.
Is this a limitation of SQLRelay that or am I not using it correctly ?
Appreciate any help.
Thanks.
Biswa
/************************************************************
* test_ref_cursor.prc - test oracle procedure
************************************************************/
CREATE OR REPLACE PROCEDURE test_ref_cursor(
p_out1 OUT SYS_REFCURSOR,
p_out2 OUT SYS_REFCURSOR,
) IS
BEGIN
OPEN p_out1 FOR SELECT TO_CHAR(SYSDATE,'DD-MON-YYYY') the_date
FROM DUAL;
OPEN p_out2 FOR SELECT TO_CHAR(SYSDATE,'HH24:MI:SS') the_time
FROM DUAL;
END test_ref_cursor;
/
/************************************************************
* test_ref_cursor.pl test perl script
************************************************************/
use SQLRelay::Connection;
use SQLRelay::Cursor;
$con=3DSQLRelay::Connection->new("localhost",9000,"","oracletest","oracle=
t
est",0,1);
$cur=3DSQLRelay::Cursor->new($con);
$cur->prepareQuery("begin test_ref_cursor(:1, :2); end;");
$cur->defineOutputBindCursor("1");
$cur->defineOutputBindCursor("2");
$cur->executeQuery();
# get first rs
my $bindcur1 =3D $cur->getOutputBindCursor('1');
$bindcur1->fetchFromBindCursor();
print $bindcur1->getField(0,0),"\n";
# get second rs
my $bindcur2 =3D $cur->getOutputBindCursor('2');
$bindcur2->fetchFromBindCursor();
print $bindcur2->getField(0,0),"\n";
=20
=20
=20
This correspondence is from Napster, Inc. or its affiliated entities
and is intended only for use by the recipient named herein. This
correspondence may contain privileged, proprietary and/or confidential
information, and is intended only to be seen and used by named =
addressee(s).
You are notified that any discussion, dissemination,distribution or =
copying
of this correspondence and any attachments, is strictly prohibited,=20
unless otherwise authorized or consented to in writing by the sender.=20
If you have received this correspondence in error, please notify the=20
sender immediately, and please permanently delete the original and any=20
copies of it and any attachment and destroy any related printouts =
without=20
reading or copying them.
|
|
From: Kelly S. <ks...@tw...> - 2006-01-03 21:36:20
|
Hello All, Is there a way to configure the listener so that there is no authentication required? I know that there is the AuthTier setting for listener, connection, listener and connection and database, but is there a way to disable authentication to the sqlrelay port all together? Thanks. Kelly Shum |
|
From: Maciej W. <mac...@co...> - 2006-01-03 20:03:26
|
David Muse wrote: > Oops, I just realized there was a question here while moving messages > around :) Sorry I didn't answer it earlier.... OK ;) I had to check some things about this problem and write what I would find, but... holidays, new year etc. and I didn't do that. Hope this week I'll manage to do some tests. > I think back then, SQL Relay didn't automatically recover when a > database connection went down. So, it might have been more useful then > than it is now. So using ping in my case is not a good idea - standard behaviour and just simple sendQuery is enough. Thanks. -- Maciej Wisniowski |
|
From: David M. <dav...@fi...> - 2006-01-03 19:35:37
|
When using multiple databases, SQL Relay assumes that the databases are
replicated copies of each other (or are nodes in a cluster) and
distributes client sessions over them to balance load.
I think you're looking for a query routing feature where the databases
aren't copies of each other, and SQL Relay can be configured to send
certain queries to 1 database and other queries to another.
SQL Relay doesn't currently support that feature, nor will it be
available in 0.37, but it will likely be available in 0.38.
In the mean time if you want to send one set of queries to one database
and another set to a second database, you'll have to set up 2 instances
of SQL Relay and your application will have to choose which instance to
run the query though.
David Muse
dav...@fi...
On Wed, 2005-12-14 at 20:13 +0100, Albert Vila wrote:
> Hi all,
>
> I've just downloaded and tried the sqlrelay application. It looks
> great, however, I have a problem trying to connect using more than one db.
>
> I have the following conf:
>
> <instances>
> <instance id="example" port="9000" socket="/tmp/example.socket"
> dbase="mysql" connections="3" maxconnections="15" maxqueuelength="5"
> growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
> runasuser="nobody" runasgroup="nobody" cursors="5" authtier="listener"
> handoff="pass" deniedips="" allowedips="" debug="listener_and_connection">
> <users>
> <user user="mysqltest" password="mysqltest"/>
> </users>
> <connections>
> <connection connectionid="db1"
> string="user=yyy;password=xxx;db=db1;host=myhost" metric="1"/>
> <connection connectionid="db2"
> string="user=yyy;password=xxx;db=db2;host=myhost" metric="1"/>
> </connections>
> </instance>
> </instances>
>
> And i'm using the dbi api this way:
>
> my
> $dbh=DBI->connect("DBI:SQLRelay:host=localhost;port=9000;socket=","mysqltest","mysqltest");
>
> The problem is how can I choose between one connection or another?
>
> For example, I have this two querys:
> select * from table_1 -> this query must run over the connectionid db1.
> select * from table_2 -> this query must run over the connectionid db2.
>
> I've not found the way to deal with this problem, because using
> DBI->connect method I cannot set the connectionid parameter. If I use
> the DBI->connect method, one query works fine and the other one not.
>
> Am I doing something wrong?
>
> Thanks in advance.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
|
|
From: Rodrigo P. T. <te...@de...> - 2006-01-03 19:23:58
|
Hi David, David Muse wrote: >Hey Telles, > >I recently discovered a bug that can cause a crash while fetching data >from a clob in a UTF8 database under certain circumstances. Does your >database use the UTF8 character set, and are you using clobs? No it doesn't! We are using ISO-8859-1 (latin1) without clobs! I'm doing some more tests about that problem and I'll send the results to the list. Thanks for your attention! Telles > >Dave >dav...@fi... > >On Thu, 2005-12-15 at 15:18 -0200, Rodrigo P. Telles wrote: > > David, > > Errata: > > The exception happens mainly in "SELECT" queries but happens too with > INSERT and > UPDATE queries, the big problem is the same queries that causes crashs > works > perfectly all (mostly) the time. Just happens if it's been running a > while! > PS: These SELECT queries frequently runs from 1 to 8 times > sequentially and > return only 1 result! > > regards, > Telles > > Rodrigo P. Telles wrote: > > >David, > > >David Muse wrote: > > >>>It appears to be crashing inside a call to row::addField(). Strangely > >>>enough though, there are no delete[]'s inside of that method. > >>> > >>>Random stuff like that generally means that a buffer overrun occurred > >>>somewhere earlier and either overwrote a pointer or a return address or > >>>something and then the app either jumped off into the weeds or > >>>dereferenced a pointer to some invalid page of memory. > >>> > >>>These kinds of bugs tend to be very difficult to track down. The only > >>>good way is to link in ElectricFence to libsqlrclient.so and let it run > >>>for a while. ElectricFence will cause a segfault in the exact > >>>instruction that overran the buffer and will help narrow down the > >>>problem, but it makes apps run slower and use more memory. > > > >Good! I'm glad to hear that, there is a way to track down the problem. > >I'm sorry but I'm not familiar with ElectricFence, I just heard about it! > >How can I do it? (link in ElectricFence to libsqlrclient.so) > >There is no problem about slower down the application and make it use > more > >memory right now, lets do it! > > > >>>It would help to know what query caused the problem, and whether or not > >>>that query always causes a crash, or if it just happens if it's been > >>>running a while. > > > >The exception happens mainly in INSERT queries but happens too with > SELECT and > >UPDATE queries, the big problem is the same queries that causes > crashs works > >perfectly all (mostly) the time. Just happens if it's been running a > while! > > >Thanks for your help! > > >Telles > > > >>>Dave > >>>dav...@fi... > >>> > >>>On Mon, 2005-12-12 at 19:23 -0200, Rodrigo P. Telles wrote: > >>> > >>>Hi David, > >>> > >>>Last week that error happend twice and I could see a new > information in log files: > >>> > >>>free(): invalid pointer 0x4c8017a8! > >>> > >>>just seconds before the exception. > >>> > >>>Follow a new variation of the exception, now in the sqlrelay shared > library: > >>> > >>>An unexpected exception has been detected in native code outside > the VM. > >>>Unexpected Signal : 11 occurred at PC=0x4C94D171 > >>>Function=_ZN3row8addFieldEiPKcm+0x37 > >>>Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1 > >>> > >>>Current Java thread: > >>> at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method) > >>> at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183) > >>> at it.devel.Dao.consulta(Dao.java:59) > >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118) > >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95) > >>> at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233) > >>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158) > >>> at it.devel.Bilhetagem.main(Bilhetagem.java:738) > >>> > >>>Dynamic libraries: > >>>08048000-08056000 r-xp 00000000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >>>08056000-08059000 rwxp 0000d000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>40018000-40026000 r-xp 00000000 08:05 213024 > /lib/libpthread-0.10.so > >>>40026000-40028000 rwxp 0000d000 08:05 213024 > /lib/libpthread-0.10.so > >>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>40173000-4056f000 r-xp 00000000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405dd000-405de000 rwxp 00007000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405de000-405e2000 rwxs 00000000 08:09 14631 > /tmp/hsperfdata_callstart/3923 > >>>405e3000-405ec000 r-xp 00000000 08:05 213015 > /lib/libnss_files-2.3.3.so > >>>405ec000-405ed000 rwxp 00009000 08:05 213015 > /lib/libnss_files-2.3.3.so > >>>405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>40621000-40635000 r-xp 00000000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40635000-40638000 rwxp 00013000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>42029000-4203f000 r-xs 00000000 08:06 101742 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>4212d000-42686000 r-xs 00000000 08:06 101788 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > >>>ction.so > >>>4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > >>>ction.so > >>>4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > >>>.so.1.0.0 > >>>4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > >>>.so.1.0.0 > >>>4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 > /usr/lib/libssl.so.0.9.7 > >>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 > /usr/lib/libssl.so.0.9.7 > >>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > >>>r.so > >>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > >>>r.so > >>> > >>>Heap at VM Abort: > >>>Heap > >>>def new generation total 576K, used 315K [0x44730000, 0x447d0000, > 0x44c10000) > >>> eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000) > >>> from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000) > >>> to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000) > >>>tenured generation total 1408K, used 162K [0x44c10000, > 0x44d70000, 0x48730000) > >>> the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, > 0x44d70000) > >>>compacting perm gen total 4096K, used 1766K [0x48730000, > 0x48b30000, 0x4c730000) > >>> the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, > 0x48b30000) > >>> > >>>Local Time = Mon Dec 12 16:37:48 2005 > >>>Elapsed Time = 81 > >>># > >>># The exception above was detected in native code outside the VM > >>># > >>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>> > >>> > >>>Thanks for any help! > >>> > >>>Telles > >>> > >>>Rodrigo P. Telles wrote: > >>> > >>> > >>>>Hi David, > >>> > >>>>Firstworks/4access wrote: > >>> > >>> > >>>>>>Is it possible to reliably reproduce the problem with a particular > >>>>>>query, or is it kind of random? > >>> > >>> > >>>>No it doesn't, it happens in a random fashion. Could happens twice > in a week or > >>>>once in a month. > >>> > >>> > >>> > >>>>>>Offhand, it looks like java is trying to run (or return from) a > native > >>>>>>C++ function and has the wrong address for the function (or > wrong return > >>>>>>address) and it ends up jumping off into the weeds, possibly into a > >>>>>>non-executable page of memory. This typically happens when a buffer > >>>>>>overrun occurs and overwrites a jump address. > >>>>>> > >>>>>>Does this happen with really long queries? With > >>> > >>> > >>>>No it doesn't. > >>>>It happens in a simple query using INSERT or SELECT! > >>> > >>> > >>> > >>>>>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >>>>>>It's possible that there's some kind of bug where the SQL Relay > client > >>>>>>is copying too much data and overrunning it's buffer. If it's > only long > >>>>>>queries, that would make sense and should be easy to patch. > >>>>>> > >>>>>>Let me know... > >>> > >>> > >>>>Let me know if I can do any thing to "collect" more informations > about that problem. > >>>>Thanks for your answer. > >>> > >>>>Telles > >>> > >>> > >>> > >>>>>>David Muse > >>>>>>dav...@fi... > >>>>>> > >>>>>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > >>>>>> > >>>>>>Hi Guys, > >>>>>> > >>>>>>I've been experiencing some errors using JAVA with sqlrelay-0.35 > API and MySQL > >>>>>>4.1.7 as a DB backend. > >>>>>> > >>>>>>Some thimes when I'm doing a query the application failed with > that output > >>>>>>exception: > >>>>>>---------------------------------------------------------------------------------- > >>>>>>An unexpected exception has been detected in native code outside > the VM. > >>>>>>Unexpected Signal : 11 occurred at PC=0x400C6C48 > >>>>>>Function=(null)+0x400C6C48 > >>>>>>Library=/lib/libc.so.6 > >>>>>> > >>>>>>NOTE: We are unable to locate the function name symbol for the error > >>>>>> just occurred. Please refer to release documentation for possible > >>>>>> reason and solutions. > >>>>>> > >>>>>> > >>>>>>Current Java thread: > >>>>>>at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > >>>>>>at it.devel.Dao.getBean(Dao.java:185) > >>>>>>at > it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > >>>>>>at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > >>>>>>at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > >>>>>>at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > >>>>>>at it.devel.Bilhetagem.main(Bilhetagem.java:693) > >>>>>> > >>>>>>Dynamic libraries: > >>>>>>08048000-08056000 r-xp 00000000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >>>>>>08056000-08059000 rwxp 0000d000 08:06 246208 > /usr/local/j2sdk1.4.2_06/bin/java > >>>>>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>>>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>>>>40018000-40026000 r-xp 00000000 08:05 213024 > /lib/libpthread-0.10.so > >>>>>>40026000-40028000 rwxp 0000d000 08:05 213024 > /lib/libpthread-0.10.so > >>>>>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>>>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>>>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>>>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>>>>40173000-4056f000 r-xp 00000000 08:06 134540 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>>>>4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>>>>405a2000-405b1000 r-xp 00000000 08:05 213009 > /lib/libnsl-2.3.3.so > >>>>>>405b1000-405b2000 rwxp 0000f000 08:05 213009 > /lib/libnsl-2.3.3.so > >>>>>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>>>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>>>>405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>>>>405dd000-405de000 rwxp 00007000 08:06 101710 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>>>>405de000-405e2000 rwxs 00000000 08:09 14628 > /tmp/hsperfdata_callstart/19866 > >>>>>>405e3000-405ec000 r-xp 00000000 08:05 213015 > /lib/libnss_files-2.3.3.so > >>>>>>405ec000-405ed000 rwxp 00009000 08:05 213015 > /lib/libnss_files-2.3.3.so > >>>>>>405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>>>>405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>>>>405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>>>>4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>>>>40621000-40635000 r-xp 00000000 08:06 101720 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>>>>40635000-40638000 rwxp 00013000 08:06 101720 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>>>>40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>>>>42029000-4203f000 r-xs 00000000 08:06 101742 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>>>>4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>>>>4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>>>>4212d000-42686000 r-xs 00000000 08:06 101788 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>>>>4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>>>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>>>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>>>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>>>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>>>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>>>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>>>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>>>>4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>>>>4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>>>>4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>>>>4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>>>>4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>>>>4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>>>>4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>>>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>>>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 > /usr/lib/libssl.so.0.9.7 > >>>>>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 > /usr/lib/libssl.so.0.9.7 > >>>>>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >>>>>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 > /usr/lib/libcrypto.so.0.9.7 > >>>>>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 > /lib/libcrypt-2.3.3.so > >>>>>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 > /lib/libcrypt-2.3.3.so > >>>>>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >>>>>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 > /usr/lib/libstdc++.so.5.0.5 > >>>>>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 > /usr/lib/libgcc_s.so.1 > >>>>>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 > /usr/lib/libgcc_s.so.1 > >>>>>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>>>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>>>> > >>>>>>Heap at VM Abort: > >>>>>>Heap > >>>>>>def new generation total 576K, used 236K [0x44730000, > 0x447d0000, 0x44c10000) > >>>>>>eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > >>>>> > >>>>>>from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > >>>>> > >>>>>>to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > >>>>>>tenured generation total 1408K, used 339K [0x44c10000, > 0x44d70000, 0x48730000) > >>>>>>the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, > 0x44d70000) > >>>>>>compacting perm gen total 4096K, used 1696K [0x48730000, > 0x48b30000, 0x4c730000) > >>>>>>the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, > 0x48b30000) > >>>>>> > >>>>>>Local Time = Fri Nov 11 15:34:29 2005 > >>>>>>Elapsed Time = 771 > >>>>>># > >>>>>># The exception above was detected in native code outside the VM > >>>>>># > >>>>>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>>>>>- > >>>>>>-------------------------------------------------------------------------------------------------------- > >>>>>> > >>>>>>At the moment is not so easy for me to update to 0.36.x. > >>>>>>Does some one can help with that problem? > >>>>>> > >>>>>>Thanks in advance. > >>>>>>-- > >>>>>>============================================ > >>>>>>Rodrigo P. Telles <te...@de...> > >>>>>>IT Manager > >>>>>>Devel-IT - http://www.devel.it > >>>>>>IVOZ # 1029 > >>>>>>+55 14 3324-1200 > >>>>>>Bestcom Group > >>>>>>============================================ > >>> > >>> > >>>>------------------------------------------------------- > >>>>SF.Net email is sponsored by: > >>>>Tame your development challenges with Apache's Geronimo App > Server. Download > >>>>it for free - -and be entered to win a 42" plasma tv or your very own > >>>>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > >>>>_______________________________________________ > >>>>Sqlrelay-discussion mailing list > >>>>Sql...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>>>------------------------------------------------------- > >>>>>>This SF.Net email is sponsored by the JBoss Inc. Get Certified > Today > >>>>>>Register for a JBoss Training Course. Free Certification Exam > >>>>>>for All Training Attendees Through End of 2005. For more info visit: > >>>>>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >>>>>>_______________________________________________ > >>>>>>Sqlrelay-discussion mailing list > >>>>>>Sql...@li... > >>>>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >------------------------------------------------------- > >This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > >for problems? Stop! Download the new AJAX search engine that makes > >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > >_______________________________________________ > >Sqlrelay-discussion mailing list > >Sql...@li... > >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > >>>------------------------------------------------------- > >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > >>>for problems? Stop! Download the new AJAX search engine that makes > >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > >>>_______________________________________________ > >>>Sqlrelay-discussion mailing list > >>>Sql...@li... > >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Sqlrelay-discussion mailing list Sql...@li... https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Sqlrelay-discussion mailing list >Sql...@li... >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion |
|
From: David M. <dav...@fi...> - 2006-01-03 19:14:54
|
On Fri, 2005-12-16 at 23:55 +0100, Maciej Wisniowski wrote: > Hi! > > Thanks for the answer. > > > I just ran some tests and I got the same behavior from python and java. > > What version of SQL Relay are you using? Maybe there's a bug in that > > version. > I can't check my configuration now but AFAIR it is 0.36 (I'll > check this in monday). > > > Give the test programs below a try and see if you don't get the same > > results as the log below shows. > I'll try this. The problem is that I'm not the database admin and so far > I was only able to check this behaviour once a day... > Next week I hope we'll have time to do some work with this java app > and create another oracle instance for testing only. > > > If SQL Relay lost contact with the database during the backup and no > > other queries had been run, then I'd expect the ping to return false, > > and then the next query to cause SQL Relay to reconnect, run the query > > and return rowcount of 1. > This is strange for me. I expect ping to reconnect and return > true in this situation. Now it seems that ping is not checking database > but rather listener's status...? What for is this ping then? > What logic is in that it returns 'false' even if it is possible to get > data from database? Oops, I just realized there was a question here while moving messages around :) Sorry I didn't answer it earlier.... ping tells you whether the connection between SQL Relay and the database is ok or not. I implemented it that way because someone requested it, but I don't remember who, it was a long time ago :) I think back then, SQL Relay didn't automatically recover when a database connection went down. So, it might have been more useful then than it is now. > > > > If you have 3 sqlr-connection daemons running, you'd see that behavior 3 > > times. After all 3 sqlr-connections have re-established their database > > conections, ping should start returning true. > I will play with this. > > > The behavior your java program exhibits is exactly what I'd expect. > > If the python program exhibits different behavior, then maybe there's a > > bug there. Although ping is implemented identically for both API's. > > They just wrap the C++ function. > > Does the python program maybe run against a different database, where > > another program may have run queries against the database since the > > backup? > I'm not sure. Something like that could happened. It's possible that some > queries were done, maybe from java... I did not know the rule of 3 > sqlr-connections ;) so maybe my interpretation was wrong and python > is working like java... I'll check this next week. > > |
|
From: David M. <dav...@fi...> - 2006-01-03 19:09:36
|
Hey Telles, I recently discovered a bug that can cause a crash while fetching data from a clob in a UTF8 database under certain circumstances. Does your database use the UTF8 character set, and are you using clobs? Dave dav...@fi... On Thu, 2005-12-15 at 15:18 -0200, Rodrigo P. Telles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David, > > Errata: > > The exception happens mainly in "SELECT" queries but happens too with INSERT and > UPDATE queries, the big problem is the same queries that causes crashs works > perfectly all (mostly) the time. Just happens if it's been running a while! > PS: These SELECT queries frequently runs from 1 to 8 times sequentially and > return only 1 result! > > regards, > Telles > > Rodrigo P. Telles wrote: > > David, > > > > David Muse wrote: > > > >>>It appears to be crashing inside a call to row::addField(). Strangely > >>>enough though, there are no delete[]'s inside of that method. > >>> > >>>Random stuff like that generally means that a buffer overrun occurred > >>>somewhere earlier and either overwrote a pointer or a return address or > >>>something and then the app either jumped off into the weeds or > >>>dereferenced a pointer to some invalid page of memory. > >>> > >>>These kinds of bugs tend to be very difficult to track down. The only > >>>good way is to link in ElectricFence to libsqlrclient.so and let it run > >>>for a while. ElectricFence will cause a segfault in the exact > >>>instruction that overran the buffer and will help narrow down the > >>>problem, but it makes apps run slower and use more memory. > > > > > > Good! I'm glad to hear that, there is a way to track down the problem. > > I'm sorry but I'm not familiar with ElectricFence, I just heard about it! > > How can I do it? (link in ElectricFence to libsqlrclient.so) > > There is no problem about slower down the application and make it use more > > memory right now, lets do it! > > > > > >>>It would help to know what query caused the problem, and whether or not > >>>that query always causes a crash, or if it just happens if it's been > >>>running a while. > > > > > > The exception happens mainly in INSERT queries but happens too with SELECT and > > UPDATE queries, the big problem is the same queries that causes crashs works > > perfectly all (mostly) the time. Just happens if it's been running a while! > > > > Thanks for your help! > > > > Telles > > > > > >>>Dave > >>>dav...@fi... > >>> > >>>On Mon, 2005-12-12 at 19:23 -0200, Rodrigo P. Telles wrote: > >>> > >>>Hi David, > >>> > >>>Last week that error happend twice and I could see a new information in log files: > >>> > >>>free(): invalid pointer 0x4c8017a8! > >>> > >>>just seconds before the exception. > >>> > >>>Follow a new variation of the exception, now in the sqlrelay shared library: > >>> > >>>An unexpected exception has been detected in native code outside the VM. > >>>Unexpected Signal : 11 occurred at PC=0x4C94D171 > >>>Function=_ZN3row8addFieldEiPKcm+0x37 > >>>Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1 > >>> > >>>Current Java thread: > >>> at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method) > >>> at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183) > >>> at it.devel.Dao.consulta(Dao.java:59) > >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118) > >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95) > >>> at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233) > >>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158) > >>> at it.devel.Bilhetagem.main(Bilhetagem.java:738) > >>> > >>>Dynamic libraries: > >>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>40173000-4056f000 r-xp 00000000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405dd000-405de000 rwxp 00007000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405de000-405e2000 rwxs 00000000 08:09 14631 /tmp/hsperfdata_callstart/3923 > >>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>40621000-40635000 r-xp 00000000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40635000-40638000 rwxp 00013000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>42029000-4203f000 r-xs 00000000 08:06 101742 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>4212d000-42686000 r-xs 00000000 08:06 101788 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > >>>ction.so > >>>4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > >>>ction.so > >>>4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > >>>.so.1.0.0 > >>>4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > >>>.so.1.0.0 > >>>4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > >>>r.so > >>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > >>>r.so > >>> > >>>Heap at VM Abort: > >>>Heap > >>> def new generation total 576K, used 315K [0x44730000, 0x447d0000, 0x44c10000) > >>> eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000) > >>> from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000) > >>> to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000) > >>> tenured generation total 1408K, used 162K [0x44c10000, 0x44d70000, 0x48730000) > >>> the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, 0x44d70000) > >>> compacting perm gen total 4096K, used 1766K [0x48730000, 0x48b30000, 0x4c730000) > >>> the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, 0x48b30000) > >>> > >>>Local Time = Mon Dec 12 16:37:48 2005 > >>>Elapsed Time = 81 > >>># > >>># The exception above was detected in native code outside the VM > >>># > >>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>> > >>> > >>>Thanks for any help! > >>> > >>>Telles > >>> > >>>Rodrigo P. Telles wrote: > >>> > >>> > >>>>Hi David, > >>> > >>>>Firstworks/4access wrote: > >>> > >>> > >>>>>>Is it possible to reliably reproduce the problem with a particular > >>>>>>query, or is it kind of random? > >>> > >>> > >>>>No it doesn't, it happens in a random fashion. Could happens twice in a week or > >>>>once in a month. > >>> > >>> > >>> > >>>>>>Offhand, it looks like java is trying to run (or return from) a native > >>>>>>C++ function and has the wrong address for the function (or wrong return > >>>>>>address) and it ends up jumping off into the weeds, possibly into a > >>>>>>non-executable page of memory. This typically happens when a buffer > >>>>>>overrun occurs and overwrites a jump address. > >>>>>> > >>>>>>Does this happen with really long queries? With > >>> > >>> > >>>>No it doesn't. > >>>>It happens in a simple query using INSERT or SELECT! > >>> > >>> > >>> > >>>>>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >>>>>>It's possible that there's some kind of bug where the SQL Relay client > >>>>>>is copying too much data and overrunning it's buffer. If it's only long > >>>>>>queries, that would make sense and should be easy to patch. > >>>>>> > >>>>>>Let me know... > >>> > >>> > >>>>Let me know if I can do any thing to "collect" more informations about that problem. > >>>>Thanks for your answer. > >>> > >>>>Telles > >>> > >>> > >>> > >>>>>>David Muse > >>>>>>dav...@fi... > >>>>>> > >>>>>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > >>>>>> > >>>>>>Hi Guys, > >>>>>> > >>>>>>I've been experiencing some errors using JAVA with sqlrelay-0.35 API and MySQL > >>>>>>4.1.7 as a DB backend. > >>>>>> > >>>>>>Some thimes when I'm doing a query the application failed with that output > >>>>>>exception: > >>>>>>---------------------------------------------------------------------------------- > >>>>>>An unexpected exception has been detected in native code outside the VM. > >>>>>>Unexpected Signal : 11 occurred at PC=0x400C6C48 > >>>>>>Function=(null)+0x400C6C48 > >>>>>>Library=/lib/libc.so.6 > >>>>>> > >>>>>>NOTE: We are unable to locate the function name symbol for the error > >>>>>> just occurred. Please refer to release documentation for possible > >>>>>> reason and solutions. > >>>>>> > >>>>>> > >>>>>>Current Java thread: > >>>>>>at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > >>>>>>at it.devel.Dao.getBean(Dao.java:185) > >>>>>>at it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > >>>>>>at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > >>>>>>at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > >>>>>>at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > >>>>>>at it.devel.Bilhetagem.main(Bilhetagem.java:693) > >>>>>> > >>>>>>Dynamic libraries: > >>>>>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>>>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>>>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>>>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>>>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >>>>>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >>>>>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>>>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>>>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>>>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>>>>40173000-4056f000 r-xp 00000000 08:06 134540 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>>>>4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>>>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>>>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>>>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>>>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>>>>405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>>>>405dd000-405de000 rwxp 00007000 08:06 101710 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>>>>405de000-405e2000 rwxs 00000000 08:09 14628 /tmp/hsperfdata_callstart/19866 > >>>>>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>>>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>>>>405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>>>>405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>>>>405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>>>>4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>>>>40621000-40635000 r-xp 00000000 08:06 101720 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>>>>40635000-40638000 rwxp 00013000 08:06 101720 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>>>>40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>>>>42029000-4203f000 r-xs 00000000 08:06 101742 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>>>>4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>>>>4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>>>>4212d000-42686000 r-xs 00000000 08:06 101788 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>>>>4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>>>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>>>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>>>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>>>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>>>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>>>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>>>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>>>>4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>>>>4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>>>>4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>>>>4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>>>>4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>>>>4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>>>>4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>>>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>>>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>>>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>>>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>>>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>>>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>>>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>>>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>>>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>>>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>>>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>>>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>>>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>>>> > >>>>>>Heap at VM Abort: > >>>>>>Heap > >>>>>>def new generation total 576K, used 236K [0x44730000, 0x447d0000, 0x44c10000) > >>>>>>eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > >>>>>>from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > >>>>>>to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > >>>>>>tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, 0x48730000) > >>>>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, 0x44d70000) > >>>>>>compacting perm gen total 4096K, used 1696K [0x48730000, 0x48b30000, 0x4c730000) > >>>>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, 0x48b30000) > >>>>>> > >>>>>>Local Time = Fri Nov 11 15:34:29 2005 > >>>>>>Elapsed Time = 771 > >>>>>># > >>>>>># The exception above was detected in native code outside the VM > >>>>>># > >>>>>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>>>>>- > >>>>>>-------------------------------------------------------------------------------------------------------- > >>>>>> > >>>>>>At the moment is not so easy for me to update to 0.36.x. > >>>>>>Does some one can help with that problem? > >>>>>> > >>>>>>Thanks in advance. > >>>>>>-- > >>>>>>============================================ > >>>>>>Rodrigo P. Telles <te...@de...> > >>>>>>IT Manager > >>>>>>Devel-IT - http://www.devel.it > >>>>>>IVOZ # 1029 > >>>>>>+55 14 3324-1200 > >>>>>>Bestcom Group > >>>>>>============================================ > >>> > >>> > >>>>------------------------------------------------------- > >>>>SF.Net email is sponsored by: > >>>>Tame your development challenges with Apache's Geronimo App Server. Download > >>>>it for free - -and be entered to win a 42" plasma tv or your very own > >>>>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > >>>>_______________________________________________ > >>>>Sqlrelay-discussion mailing list > >>>>Sql...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>>>------------------------------------------------------- > >>>>>>This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >>>>>>Register for a JBoss Training Course. Free Certification Exam > >>>>>>for All Training Attendees Through End of 2005. For more info visit: > >>>>>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >>>>>>_______________________________________________ > >>>>>>Sqlrelay-discussion mailing list > >>>>>>Sql...@li... > >>>>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > Sqlrelay-discussion mailing list > > Sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > > > > > > > >>>------------------------------------------------------- > >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > >>>for problems? Stop! Download the new AJAX search engine that makes > >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > >>>_______________________________________________ > >>>Sqlrelay-discussion mailing list > >>>Sql...@li... > >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > > - ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDoaV0iLK8unYgEMQRAhsSAJ0QHXmGdsgP/NOpWtAl2Bf4/XCALQCePYzP > WqwZFDrAIqn3vt4YT1STPwQ= > =zHtY > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: David M. <dav...@fi...> - 2005-12-19 05:40:37
|
Hello SQL Relay list, As I type this, I'm uploading sqlrelay-0.37pre4.tar.gz to http://www.firstworks.com/sqlrelay-0.37pre4.tar.gz I've fixed some bugs since the last pre-release. Most notably, the problem where freetds connections would spew errors about not being able to start a new transaction while results are pending should be resolved. The issue was that freetds doesn't currently support more than 1 cursor per-connection and any attempt to use more than 1 caused that error. I had kind-of half-fixed it in the last pre-release, but the current fix is more reliable and cleaner. Now, SQL Relay only uses one cursor when using freetds. Even so, since the SQL Relay client caches result sets, you can still do nested queries unless you first call setResultSetBufferSize() with a non-zero value. Give it a run, report any bugs. There are still a few more bits that need to be taken care of before the 0.37 release, but it doesn't look like it'll be too much work to get them taken care of. Take care, David Muse dav...@fi... PS. I know messages on the list have been piling up of late. I've just been a little busy. I'll try to get to the ones I haven't answered over the next few days. |
|
From: Maciej W. <mac...@co...> - 2005-12-16 22:53:14
|
Hi! Thanks for the answer. > I just ran some tests and I got the same behavior from python and java. > What version of SQL Relay are you using? Maybe there's a bug in that > version. I can't check my configuration now but AFAIR it is 0.36 (I'll check this in monday). > Give the test programs below a try and see if you don't get the same > results as the log below shows. I'll try this. The problem is that I'm not the database admin and so far I was only able to check this behaviour once a day... Next week I hope we'll have time to do some work with this java app and create another oracle instance for testing only. > If SQL Relay lost contact with the database during the backup and no > other queries had been run, then I'd expect the ping to return false, > and then the next query to cause SQL Relay to reconnect, run the query > and return rowcount of 1. This is strange for me. I expect ping to reconnect and return true in this situation. Now it seems that ping is not checking database but rather listener's status...? What for is this ping then? What logic is in that it returns 'false' even if it is possible to get data from database? > If you have 3 sqlr-connection daemons running, you'd see that behavior 3 > times. After all 3 sqlr-connections have re-established their database > conections, ping should start returning true. I will play with this. > The behavior your java program exhibits is exactly what I'd expect. > If the python program exhibits different behavior, then maybe there's a > bug there. Although ping is implemented identically for both API's. > They just wrap the C++ function. > Does the python program maybe run against a different database, where > another program may have run queries against the database since the > backup? I'm not sure. Something like that could happened. It's possible that some queries were done, maybe from java... I did not know the rule of 3 sqlr-connections ;) so maybe my interpretation was wrong and python is working like java... I'll check this next week. -- Maciej Wisniowski |
|
From: David M. <dav...@fi...> - 2005-12-16 16:43:21
|
Maciej,
I just ran some tests and I got the same behavior from python and java.
What version of SQL Relay are you using? Maybe there's a bug in that
version.
Give the test programs below a try and see if you don't get the same
results as the log below shows.
Dave
dav...@fi...
Java test program:
import com.firstworks.sqlrelay.SQLRConnection;
import com.firstworks.sqlrelay.SQLRCursor;
class test {
public static void main(String[] args) {
String host="localhost";
short port=8009;
String socket="";
String user="oracle8test";
String pwd="oracle8test";
//loop three times
for (int a=0; a<3; a++){
SQLRConnection conn = new SQLRConnection(host, port, socket, user,
pwd, 0, 1);
System.out.println("ping"+conn.ping()+". ");
if (conn.ping()){
System.out.println("OK");
}
else{
SQLRCursor cur=new SQLRCursor(conn);
cur.getNullsAsNulls();
String query = "select 1 from dual";
cur.sendQuery(query);
System.out.println("rowcount:"+cur.rowCount());
}
}
}
}
Python test program:
#!/usr/bin/env python
from SQLRelay import PySQLRClient
import sys
import string
host="localhost"
port=8009
socket=""
user="oracle8test"
pwd="oracle8test"
for i in range(0,3):
conn=PySQLRClient.sqlrconnection(host, port, socket, user, pwd, 0, 1)
print "ping", conn.ping(), ". "
if conn.ping():
print "OK"
else:
cur=PySQLRClient.sqlrcursor(conn)
cur.getNullsAsNone()
query="select 1 from dual"
cur.sendQuery(query)
print "rowcount:", cur.rowCount()
And here's a log of my test:
**** oracle and sqlrelay are running *****
[mused@localhost java]$ ps -efa | grep ora
root 2400 2386 0 Dec15 ? 00:00:01 hald-addon-storage
mused 15155 1 0 11:03 ? 00:00:00 sqlr-listener -id
oracle8test -config /usr/local/firstworks/etc/sqlrelay.conf
mused 15160 1 0 11:03 ? 00:00:06 sqlr-connection-oracle8
-id oracle8test -connectionid db
-config /usr/local/firstworks/etc/sqlrelay.conf
mused 15164 1 0 11:03 ? 00:00:07 sqlr-connection-oracle8
-id oracle8test -connectionid db
-config /usr/local/firstworks/etc/sqlrelay.conf
mused 15168 1 0 11:03 ? 00:00:06 sqlr-connection-oracle8
-id oracle8test -connectionid db
-config /usr/local/firstworks/etc/sqlrelay.conf
mused 15170 1 0 11:03 ? 00:00:00 sqlr-scaler -id
oracle8test -config /usr/local/firstworks/etc/sqlrelay.conf
oracle 16613 1 0 11:21 ? 00:00:00 ora_pmon_ora1
oracle 16615 1 0 11:21 ? 00:00:00 ora_mman_ora1
oracle 16617 1 0 11:21 ? 00:00:00 ora_dbw0_ora1
oracle 16619 1 0 11:21 ? 00:00:00 ora_lgwr_ora1
oracle 16621 1 0 11:21 ? 00:00:00 ora_ckpt_ora1
oracle 16623 1 0 11:21 ? 00:00:00 ora_smon_ora1
oracle 16625 1 0 11:21 ? 00:00:00 ora_reco_ora1
oracle 16627 1 0 11:21 ? 00:00:00 ora_cjq0_ora1
oracle 16629 1 0 11:21 ? 00:00:00 ora_d000_ora1
oracle 16631 1 0 11:21 ? 00:00:00 ora_s000_ora1
oracle 16656 1 0 11:21 ? 00:00:00 ora_qmnc_ora1
oracle 16666 1 0 11:21 ? 00:00:01 ora_mmon_ora1
oracle 16668 1 0 11:21 ? 00:00:00 ora_mmnl_ora1
oracle 16715 1 0 11:21 ?
00:00:00 /u01/app/oracle/product/10.1.0/bin/tnslsnr LISTENER -inherit
oracle 16817 1 0 11:23 ? 00:00:00 oracleora1 (LOCAL=NO)
oracle 16820 1 0 11:23 ? 00:00:00 oracleora1 (LOCAL=NO)
oracle 16823 1 0 11:23 ? 00:00:00 oracleora1 (LOCAL=NO)
oracle 17303 1 0 11:32 ? 00:00:00 ora_q000_ora1
mused 17511 32183 0 11:36 pts/3 00:00:00 grep ora
**** bounce the database ****
[mused@localhost java]$ sudo /etc/rc.d/init.d/oracle stop
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:36:40 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> ERROR:
ORA-12162: TNS:net service name is incorrectly specified
SQL> ORA-12162: TNS:net service name is incorrectly specified
SQL> Database "" shut down.
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:36:40 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> Connected.
SQL> Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Database "ora1" shut down.
LSNRCTL for Linux: Version 10.1.0.2.0 - Production on 16-DEC-2005
11:36:58
Copyright (c) 1991, 2004, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
The command completed successfully
[mused@localhost java]$ sudo /etc/rc.d/init.d/oracle start
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:37:08 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> ERROR:
ORA-12162: TNS:net service name is incorrectly specified
SQL> ORA-12162: TNS:net service name is incorrectly specified
SQL>
Database "" warm started.
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:37:08 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> Connected to an idle instance.
SQL> ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL> Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Database "ora1" warm started.
LSNRCTL for Linux: Version 10.1.0.2.0 - Production on 16-DEC-2005
11:37:43
Copyright (c) 1991, 2004, Oracle. All rights reserved.
Starting /u01/app/oracle/product/10.1.0/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 10.1.0.2.0 - Production
System parameter file
is /u01/app/oracle/product/10.1.0/network/admin/listener.ora
Log messages written
to /u01/app/oracle/product/10.1.0/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Listening on:
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 10.1.0.2.0 -
Production
Start Date 16-DEC-2005 11:37:44
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter
File /u01/app/oracle/product/10.1.0/network/admin/listener.ora
Listener Log
File /u01/app/oracle/product/10.1.0/network/log/listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this
service...
Service "ora1" has 1 instance(s).
Instance "ora1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
**** run the python test ****
[mused@localhost java]$ ./test.py
ping 0 .
rowcount: 1
ping 0 .
rowcount: 1
ping 0 .
rowcount: 1
**** run it again now that sqlrelay has reconnected ****
[mused@localhost java]$ ./test.py
ping 1 .
OK
ping 1 .
OK
ping 1 .
OK
**** bounce the database ****
[mused@localhost java]$ sudo /etc/rc.d/init.d/oracle stop
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:38:31 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> ERROR:
ORA-12162: TNS:net service name is incorrectly specified
SQL> ORA-12162: TNS:net service name is incorrectly specified
SQL> Database "" shut down.
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:38:31 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> Connected.
SQL> Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Database "ora1" shut down.
LSNRCTL for Linux: Version 10.1.0.2.0 - Production on 16-DEC-2005
11:38:45
Copyright (c) 1991, 2004, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
The command completed successfully
[mused@localhost java]$ sudo /etc/rc.d/init.d/oracle start
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:38:50 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> ERROR:
ORA-12162: TNS:net service name is incorrectly specified
SQL> ORA-12162: TNS:net service name is incorrectly specified
SQL>
Database "" warm started.
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Dec 16 11:38:50 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> Connected to an idle instance.
SQL> ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL> Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Database "ora1" warm started.
LSNRCTL for Linux: Version 10.1.0.2.0 - Production on 16-DEC-2005
11:39:06
Copyright (c) 1991, 2004, Oracle. All rights reserved.
Starting /u01/app/oracle/product/10.1.0/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 10.1.0.2.0 - Production
System parameter file
is /u01/app/oracle/product/10.1.0/network/admin/listener.ora
Log messages written
to /u01/app/oracle/product/10.1.0/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Listening on:
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 10.1.0.2.0 -
Production
Start Date 16-DEC-2005 11:39:06
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter
File /u01/app/oracle/product/10.1.0/network/admin/listener.ora
Listener Log
File /u01/app/oracle/product/10.1.0/network/log/listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this
service...
Service "ora1" has 1 instance(s).
Instance "ora1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
**** run the java test ****
[mused@localhost java]$ /usr/java/jdk1.5.0_04/bin/java
-classpath /usr/local/firstworks/java/sqlrelay.jar:./ test
pingfalse.
rowcount:1
pingfalse.
rowcount:1
pingfalse.
rowcount:1
**** run it again now that sqlrelay has reconnected ****
[mused@localhost java]$ /usr/java/jdk1.5.0_04/bin/java
-classpath /usr/local/firstworks/java/sqlrelay.jar:./ test
pingtrue.
OK
pingtrue.
OK
pingtrue.
OK
On Fri, 2005-12-16 at 10:22 -0500, David Muse wrote:
> Hey Maciej,
>
> If SQL Relay lost contact with the database during the backup and no
> other queries had been run, then I'd expect the ping to return false,
> and then the next query to cause SQL Relay to reconnect, run the query
> and return rowcount of 1.
>
> If you have 3 sqlr-connection daemons running, you'd see that behavior 3
> times. After all 3 sqlr-connections have re-established their database
> conections, ping should start returning true.
>
> The behavior your java program exhibits is exactly what I'd expect.
>
> If the python program exhibits different behavior, then maybe there's a
> bug there. Although ping is implemented identically for both API's.
> They just wrap the C++ function.
>
> Does the python program maybe run against a different database, where
> another program may have run queries against the database since the
> backup?
>
> Just to be sure, I'll see if I can simulate the same conditions here and
> let you know what I find out.
>
> Dave
> dav...@fi...
>
> [snip]
> > I understand it, but I think my problem is different. Or maybe I'm wrong?
> > My program runs as follows:
> >
> > import com.firstworks.sqlrelay.SQLRConnection;
> > import com.firstworks.sqlrelay.SQLRCursor;
> >
> > //loop three times
> > for (int a=0; a<=3; a++){
> > SQLRConnection conn = new SQLRConnection(host, port, socket, user, pwd, 0, 1);
> > System.out.println("ping"+conn.ping()+". ");
> >
> > if (conn.ping()){
> > System.out.println("OK");
> > }
> > else{
> > SQLRCursor cur=new SQLRCursor(conn);
> > cur.getNullsAsNulls();
> > String query = "select xxx from xyz";
> > cur.sendQuery(query);
> > System.out.println("rowcount:"+cur.rowCount());
> > }
> > }
> >
> >
> > Today morning (after database backup at night) I've started my program
> > and the result was:
> > ping false. rowcount:1
> > ping false. rowcount:1
> > ping false. rowcount:1
> >
> > Then I've started this program again and the result was:
> > ping true. OK
> > ping true. OK
> > ping true. OK
> >
> > It seems that SQLRelay is connected to database because sendQuery
> > returns some results but ping returns false (bug?).
> > When whole program is executed for the second time (but not in the
> > second loop run) everything starts to work correctly.
> > As far as I've checked this, in python there are no such problems, and
> > ping returns true even in the first run.
> >
> > ---
> > Maciej Wisniowski
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Sqlrelay-discussion mailing list
> > Sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
|
|
From: David M. <dav...@fi...> - 2005-12-16 15:17:28
|
Hey Maciej,
If SQL Relay lost contact with the database during the backup and no
other queries had been run, then I'd expect the ping to return false,
and then the next query to cause SQL Relay to reconnect, run the query
and return rowcount of 1.
If you have 3 sqlr-connection daemons running, you'd see that behavior 3
times. After all 3 sqlr-connections have re-established their database
conections, ping should start returning true.
The behavior your java program exhibits is exactly what I'd expect.
If the python program exhibits different behavior, then maybe there's a
bug there. Although ping is implemented identically for both API's.
They just wrap the C++ function.
Does the python program maybe run against a different database, where
another program may have run queries against the database since the
backup?
Just to be sure, I'll see if I can simulate the same conditions here and
let you know what I find out.
Dave
dav...@fi...
[snip]
> I understand it, but I think my problem is different. Or maybe I'm wrong?
> My program runs as follows:
>
> import com.firstworks.sqlrelay.SQLRConnection;
> import com.firstworks.sqlrelay.SQLRCursor;
>
> //loop three times
> for (int a=0; a<=3; a++){
> SQLRConnection conn = new SQLRConnection(host, port, socket, user, pwd, 0, 1);
> System.out.println("ping"+conn.ping()+". ");
>
> if (conn.ping()){
> System.out.println("OK");
> }
> else{
> SQLRCursor cur=new SQLRCursor(conn);
> cur.getNullsAsNulls();
> String query = "select xxx from xyz";
> cur.sendQuery(query);
> System.out.println("rowcount:"+cur.rowCount());
> }
> }
>
>
> Today morning (after database backup at night) I've started my program
> and the result was:
> ping false. rowcount:1
> ping false. rowcount:1
> ping false. rowcount:1
>
> Then I've started this program again and the result was:
> ping true. OK
> ping true. OK
> ping true. OK
>
> It seems that SQLRelay is connected to database because sendQuery
> returns some results but ping returns false (bug?).
> When whole program is executed for the second time (but not in the
> second loop run) everything starts to work correctly.
> As far as I've checked this, in python there are no such problems, and
> ping returns true even in the first run.
>
> ---
> Maciej Wisniowski
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
|
|
From: Rodrigo P. T. <te...@de...> - 2005-12-15 17:19:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David, Errata: The exception happens mainly in "SELECT" queries but happens too with INSERT and UPDATE queries, the big problem is the same queries that causes crashs works perfectly all (mostly) the time. Just happens if it's been running a while! PS: These SELECT queries frequently runs from 1 to 8 times sequentially and return only 1 result! regards, Telles Rodrigo P. Telles wrote: > David, > > David Muse wrote: > >>>It appears to be crashing inside a call to row::addField(). Strangely >>>enough though, there are no delete[]'s inside of that method. >>> >>>Random stuff like that generally means that a buffer overrun occurred >>>somewhere earlier and either overwrote a pointer or a return address or >>>something and then the app either jumped off into the weeds or >>>dereferenced a pointer to some invalid page of memory. >>> >>>These kinds of bugs tend to be very difficult to track down. The only >>>good way is to link in ElectricFence to libsqlrclient.so and let it run >>>for a while. ElectricFence will cause a segfault in the exact >>>instruction that overran the buffer and will help narrow down the >>>problem, but it makes apps run slower and use more memory. > > > Good! I'm glad to hear that, there is a way to track down the problem. > I'm sorry but I'm not familiar with ElectricFence, I just heard about it! > How can I do it? (link in ElectricFence to libsqlrclient.so) > There is no problem about slower down the application and make it use more > memory right now, lets do it! > > >>>It would help to know what query caused the problem, and whether or not >>>that query always causes a crash, or if it just happens if it's been >>>running a while. > > > The exception happens mainly in INSERT queries but happens too with SELECT and > UPDATE queries, the big problem is the same queries that causes crashs works > perfectly all (mostly) the time. Just happens if it's been running a while! > > Thanks for your help! > > Telles > > >>>Dave >>>dav...@fi... >>> >>>On Mon, 2005-12-12 at 19:23 -0200, Rodrigo P. Telles wrote: >>> >>>Hi David, >>> >>>Last week that error happend twice and I could see a new information in log files: >>> >>>free(): invalid pointer 0x4c8017a8! >>> >>>just seconds before the exception. >>> >>>Follow a new variation of the exception, now in the sqlrelay shared library: >>> >>>An unexpected exception has been detected in native code outside the VM. >>>Unexpected Signal : 11 occurred at PC=0x4C94D171 >>>Function=_ZN3row8addFieldEiPKcm+0x37 >>>Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1 >>> >>>Current Java thread: >>> at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method) >>> at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183) >>> at it.devel.Dao.consulta(Dao.java:59) >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118) >>> at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95) >>> at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233) >>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158) >>> at it.devel.Bilhetagem.main(Bilhetagem.java:738) >>> >>>Dynamic libraries: >>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so >>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so >>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so >>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so >>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so >>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so >>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so >>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so >>>40173000-4056f000 r-xp 00000000 08:06 134540 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>4056f000-4058b000 rwxp 003fb000 08:06 134540 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so >>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so >>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so >>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so >>>405d5000-405dd000 r-xp 00000000 08:06 101710 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>405dd000-405de000 rwxp 00007000 08:06 101710 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>405de000-405e2000 rwxs 00000000 08:09 14631 /tmp/hsperfdata_callstart/3923 >>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so >>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so >>>405ed000-405fd000 r-xp 00000000 08:06 101717 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>405fd000-405ff000 rwxp 0000f000 08:06 101717 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>405ff000-4061f000 r-xp 00000000 08:06 101718 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>4061f000-40621000 rwxp 0001f000 08:06 101718 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>40621000-40635000 r-xp 00000000 08:06 101720 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>40635000-40638000 rwxp 00013000 08:06 101720 >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>40638000-41fdf000 r-xs 00000000 08:06 101803 >>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar >>>42029000-4203f000 r-xs 00000000 08:06 101742 >>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar >>>4203f000-4211c000 r-xs 00000000 08:06 101787 >>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar >>>4211c000-4212d000 r-xs 00000000 08:06 101743 >>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar >>>4212d000-42686000 r-xs 00000000 08:06 101788 >>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar >>>4472e000-4472f000 r-xs 00000000 08:06 117021 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar >>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar >>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar >>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar >>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar >>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar >>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar >>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar >>>4c92a000-4c930000 r-xs 00000000 08:06 117025 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar >>>4c930000-4c936000 r-xs 00000000 08:06 117026 >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar >>>4c936000-4c939000 r-xp 00000000 08:06 377923 >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne >>>ction.so >>>4c939000-4c93a000 rwxp 00002000 08:06 377923 >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne >>>ction.so >>>4c93a000-4c950000 r-xp 00000000 08:06 265533 >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 >>>.so.1.0.0 >>>4c950000-4c953000 rwxp 00015000 08:06 265533 >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 >>>.so.1.0.0 >>>4c953000-4c998000 r-xp 00000000 08:06 377564 >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so >>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so >>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso >>>r.so >>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso >>>r.so >>> >>>Heap at VM Abort: >>>Heap >>> def new generation total 576K, used 315K [0x44730000, 0x447d0000, 0x44c10000) >>> eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000) >>> from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000) >>> to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000) >>> tenured generation total 1408K, used 162K [0x44c10000, 0x44d70000, 0x48730000) >>> the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, 0x44d70000) >>> compacting perm gen total 4096K, used 1766K [0x48730000, 0x48b30000, 0x4c730000) >>> the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, 0x48b30000) >>> >>>Local Time = Mon Dec 12 16:37:48 2005 >>>Elapsed Time = 81 >>># >>># The exception above was detected in native code outside the VM >>># >>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) >>> >>> >>>Thanks for any help! >>> >>>Telles >>> >>>Rodrigo P. Telles wrote: >>> >>> >>>>Hi David, >>> >>>>Firstworks/4access wrote: >>> >>> >>>>>>Is it possible to reliably reproduce the problem with a particular >>>>>>query, or is it kind of random? >>> >>> >>>>No it doesn't, it happens in a random fashion. Could happens twice in a week or >>>>once in a month. >>> >>> >>> >>>>>>Offhand, it looks like java is trying to run (or return from) a native >>>>>>C++ function and has the wrong address for the function (or wrong return >>>>>>address) and it ends up jumping off into the weeds, possibly into a >>>>>>non-executable page of memory. This typically happens when a buffer >>>>>>overrun occurs and overwrites a jump address. >>>>>> >>>>>>Does this happen with really long queries? With >>> >>> >>>>No it doesn't. >>>>It happens in a simple query using INSERT or SELECT! >>> >>> >>> >>>>>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. >>>>>>It's possible that there's some kind of bug where the SQL Relay client >>>>>>is copying too much data and overrunning it's buffer. If it's only long >>>>>>queries, that would make sense and should be easy to patch. >>>>>> >>>>>>Let me know... >>> >>> >>>>Let me know if I can do any thing to "collect" more informations about that problem. >>>>Thanks for your answer. >>> >>>>Telles >>> >>> >>> >>>>>>David Muse >>>>>>dav...@fi... >>>>>> >>>>>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: >>>>>> >>>>>>Hi Guys, >>>>>> >>>>>>I've been experiencing some errors using JAVA with sqlrelay-0.35 API and MySQL >>>>>>4.1.7 as a DB backend. >>>>>> >>>>>>Some thimes when I'm doing a query the application failed with that output >>>>>>exception: >>>>>>---------------------------------------------------------------------------------- >>>>>>An unexpected exception has been detected in native code outside the VM. >>>>>>Unexpected Signal : 11 occurred at PC=0x400C6C48 >>>>>>Function=(null)+0x400C6C48 >>>>>>Library=/lib/libc.so.6 >>>>>> >>>>>>NOTE: We are unable to locate the function name symbol for the error >>>>>> just occurred. Please refer to release documentation for possible >>>>>> reason and solutions. >>>>>> >>>>>> >>>>>>Current Java thread: >>>>>>at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) >>>>>>at it.devel.Dao.getBean(Dao.java:185) >>>>>>at it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) >>>>>>at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) >>>>>>at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) >>>>>>at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) >>>>>>at it.devel.Bilhetagem.main(Bilhetagem.java:693) >>>>>> >>>>>>Dynamic libraries: >>>>>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>>>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>>>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so >>>>>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so >>>>>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so >>>>>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so >>>>>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so >>>>>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so >>>>>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so >>>>>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so >>>>>>40173000-4056f000 r-xp 00000000 08:06 134540 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>>>>4056f000-4058b000 rwxp 003fb000 08:06 134540 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>>>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so >>>>>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so >>>>>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so >>>>>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so >>>>>>405d5000-405dd000 r-xp 00000000 08:06 101710 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>>>>405dd000-405de000 rwxp 00007000 08:06 101710 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>>>>405de000-405e2000 rwxs 00000000 08:09 14628 /tmp/hsperfdata_callstart/19866 >>>>>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so >>>>>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so >>>>>>405ed000-405fd000 r-xp 00000000 08:06 101717 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>>>>405fd000-405ff000 rwxp 0000f000 08:06 101717 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>>>>405ff000-4061f000 r-xp 00000000 08:06 101718 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>>>>4061f000-40621000 rwxp 0001f000 08:06 101718 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>>>>40621000-40635000 r-xp 00000000 08:06 101720 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>>>>40635000-40638000 rwxp 00013000 08:06 101720 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>>>>40638000-41fdf000 r-xs 00000000 08:06 101803 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar >>>>>>42029000-4203f000 r-xs 00000000 08:06 101742 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar >>>>>>4203f000-4211c000 r-xs 00000000 08:06 101787 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar >>>>>>4211c000-4212d000 r-xs 00000000 08:06 101743 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar >>>>>>4212d000-42686000 r-xs 00000000 08:06 101788 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar >>>>>>4472e000-4472f000 r-xs 00000000 08:06 117021 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar >>>>>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar >>>>>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar >>>>>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar >>>>>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar >>>>>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar >>>>>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar >>>>>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar >>>>>>4c92a000-4c930000 r-xs 00000000 08:06 117025 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar >>>>>>4c930000-4c936000 r-xs 00000000 08:06 117026 >>>>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar >>>>>>4c936000-4c939000 r-xp 00000000 08:06 377923 >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so >>>>>>4c939000-4c93a000 rwxp 00002000 08:06 377923 >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so >>>>>>4c93a000-4c950000 r-xp 00000000 08:06 265533 >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 >>>>>>4c950000-4c953000 rwxp 00015000 08:06 265533 >>>>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 >>>>>>4c953000-4c998000 r-xp 00000000 08:06 377564 >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>>>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 >>>>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>>>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>>>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>>>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>>>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>>>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so >>>>>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so >>>>>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>>>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>>>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>>>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>>>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>>>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 >>>>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>>>> >>>>>>Heap at VM Abort: >>>>>>Heap >>>>>>def new generation total 576K, used 236K [0x44730000, 0x447d0000, 0x44c10000) >>>>>>eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) >>>>>>from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) >>>>>>to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) >>>>>>tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, 0x48730000) >>>>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, 0x44d70000) >>>>>>compacting perm gen total 4096K, used 1696K [0x48730000, 0x48b30000, 0x4c730000) >>>>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, 0x48b30000) >>>>>> >>>>>>Local Time = Fri Nov 11 15:34:29 2005 >>>>>>Elapsed Time = 771 >>>>>># >>>>>># The exception above was detected in native code outside the VM >>>>>># >>>>>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) >>>>>>- >>>>>>-------------------------------------------------------------------------------------------------------- >>>>>> >>>>>>At the moment is not so easy for me to update to 0.36.x. >>>>>>Does some one can help with that problem? >>>>>> >>>>>>Thanks in advance. >>>>>>-- >>>>>>============================================ >>>>>>Rodrigo P. Telles <te...@de...> >>>>>>IT Manager >>>>>>Devel-IT - http://www.devel.it >>>>>>IVOZ # 1029 >>>>>>+55 14 3324-1200 >>>>>>Bestcom Group >>>>>>============================================ >>> >>> >>>>------------------------------------------------------- >>>>SF.Net email is sponsored by: >>>>Tame your development challenges with Apache's Geronimo App Server. Download >>>>it for free - -and be entered to win a 42" plasma tv or your very own >>>>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>>>_______________________________________________ >>>>Sqlrelay-discussion mailing list >>>>Sql...@li... >>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>> >>> >>> >>> >>> >>> >>> >>>>>>------------------------------------------------------- >>>>>>This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>>>>>Register for a JBoss Training Course. Free Certification Exam >>>>>>for All Training Attendees Through End of 2005. For more info visit: >>>>>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>>>>>_______________________________________________ >>>>>>Sqlrelay-discussion mailing list >>>>>>Sql...@li... >>>>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>> >>> >>> > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>>for problems? Stop! Download the new AJAX search engine that makes >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>_______________________________________________ >>>Sqlrelay-discussion mailing list >>>Sql...@li... >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > - ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Sqlrelay-discussion mailing list Sql...@li... https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoaV0iLK8unYgEMQRAhsSAJ0QHXmGdsgP/NOpWtAl2Bf4/XCALQCePYzP WqwZFDrAIqn3vt4YT1STPwQ= =zHtY -----END PGP SIGNATURE----- |
|
From: Rodrigo P. T. <te...@de...> - 2005-12-15 14:53:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David, David Muse wrote: > It appears to be crashing inside a call to row::addField(). Strangely > enough though, there are no delete[]'s inside of that method. > > Random stuff like that generally means that a buffer overrun occurred > somewhere earlier and either overwrote a pointer or a return address or > something and then the app either jumped off into the weeds or > dereferenced a pointer to some invalid page of memory. > > These kinds of bugs tend to be very difficult to track down. The only > good way is to link in ElectricFence to libsqlrclient.so and let it run > for a while. ElectricFence will cause a segfault in the exact > instruction that overran the buffer and will help narrow down the > problem, but it makes apps run slower and use more memory. Good! I'm glad to hear that, there is a way to track down the problem. I'm sorry but I'm not familiar with ElectricFence, I just heard about it! How can I do it? (link in ElectricFence to libsqlrclient.so) There is no problem about slower down the application and make it use more memory right now, lets do it! > > It would help to know what query caused the problem, and whether or not > that query always causes a crash, or if it just happens if it's been > running a while. The exception happens mainly in INSERT queries but happens too with SELECT and UPDATE queries, the big problem is the same queries that causes crashs works perfectly all (mostly) the time. Just happens if it's been running a while! Thanks for your help! Telles > > Dave > dav...@fi... > > On Mon, 2005-12-12 at 19:23 -0200, Rodrigo P. Telles wrote: > > Hi David, > > Last week that error happend twice and I could see a new information in log files: > > free(): invalid pointer 0x4c8017a8! > > just seconds before the exception. > > Follow a new variation of the exception, now in the sqlrelay shared library: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4C94D171 > Function=_ZN3row8addFieldEiPKcm+0x37 > Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1 > > Current Java thread: > at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method) > at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183) > at it.devel.Dao.consulta(Dao.java:59) > at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118) > at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95) > at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233) > at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158) > at it.devel.Bilhetagem.main(Bilhetagem.java:738) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > 08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > 40173000-4056f000 r-xp 00000000 08:06 134540 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > 4056f000-4058b000 rwxp 003fb000 08:06 134540 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > 405d5000-405dd000 r-xp 00000000 08:06 101710 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > 405dd000-405de000 rwxp 00007000 08:06 101710 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > 405de000-405e2000 rwxs 00000000 08:09 14631 /tmp/hsperfdata_callstart/3923 > 405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so > 405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so > 405ed000-405fd000 r-xp 00000000 08:06 101717 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > 405fd000-405ff000 rwxp 0000f000 08:06 101717 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > 405ff000-4061f000 r-xp 00000000 08:06 101718 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > 4061f000-40621000 rwxp 0001f000 08:06 101718 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > 40621000-40635000 r-xp 00000000 08:06 101720 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > 40635000-40638000 rwxp 00013000 08:06 101720 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > 40638000-41fdf000 r-xs 00000000 08:06 101803 > /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > 42029000-4203f000 r-xs 00000000 08:06 101742 > /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > 4203f000-4211c000 r-xs 00000000 08:06 101787 > /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > 4211c000-4212d000 r-xs 00000000 08:06 101743 > /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > 4212d000-42686000 r-xs 00000000 08:06 101788 > /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > 4472e000-4472f000 r-xs 00000000 08:06 117021 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > 4c7dc000-4c898000 r-xs 00000000 08:06 117684 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > 4c898000-4c8a6000 r-xs 00000000 08:06 117022 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > 4c92a000-4c930000 r-xs 00000000 08:06 117025 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > 4c930000-4c936000 r-xs 00000000 08:06 117026 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > 4c936000-4c939000 r-xp 00000000 08:06 377923 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > ction.so > 4c939000-4c93a000 rwxp 00002000 08:06 377923 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > ction.so > 4c93a000-4c950000 r-xp 00000000 08:06 265533 > /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > .so.1.0.0 > 4c950000-4c953000 rwxp 00015000 08:06 265533 > /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > .so.1.0.0 > 4c953000-4c998000 r-xp 00000000 08:06 377564 > /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > 4c998000-4c9a2000 rwxp 00044000 08:06 377564 > /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > 4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > 4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > 4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > r.so > 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > r.so > > Heap at VM Abort: > Heap > def new generation total 576K, used 315K [0x44730000, 0x447d0000, 0x44c10000) > eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000) > from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000) > to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000) > tenured generation total 1408K, used 162K [0x44c10000, 0x44d70000, 0x48730000) > the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, 0x44d70000) > compacting perm gen total 4096K, used 1766K [0x48730000, 0x48b30000, 0x4c730000) > the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, 0x48b30000) > > Local Time = Mon Dec 12 16:37:48 2005 > Elapsed Time = 81 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > > > Thanks for any help! > > Telles > > Rodrigo P. Telles wrote: > >>Hi David, > >>Firstworks/4access wrote: > > >>>>Is it possible to reliably reproduce the problem with a particular >>>>query, or is it kind of random? > > >>No it doesn't, it happens in a random fashion. Could happens twice in a week or >>once in a month. > > > >>>>Offhand, it looks like java is trying to run (or return from) a native >>>>C++ function and has the wrong address for the function (or wrong return >>>>address) and it ends up jumping off into the weeds, possibly into a >>>>non-executable page of memory. This typically happens when a buffer >>>>overrun occurs and overwrites a jump address. >>>> >>>>Does this happen with really long queries? With > > >>No it doesn't. >>It happens in a simple query using INSERT or SELECT! > > > >>>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. >>>>It's possible that there's some kind of bug where the SQL Relay client >>>>is copying too much data and overrunning it's buffer. If it's only long >>>>queries, that would make sense and should be easy to patch. >>>> >>>>Let me know... > > >>Let me know if I can do any thing to "collect" more informations about that problem. >>Thanks for your answer. > >>Telles > > > >>>>David Muse >>>>dav...@fi... >>>> >>>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: >>>> >>>>Hi Guys, >>>> >>>>I've been experiencing some errors using JAVA with sqlrelay-0.35 API and MySQL >>>>4.1.7 as a DB backend. >>>> >>>>Some thimes when I'm doing a query the application failed with that output >>>>exception: >>>>---------------------------------------------------------------------------------- >>>>An unexpected exception has been detected in native code outside the VM. >>>>Unexpected Signal : 11 occurred at PC=0x400C6C48 >>>>Function=(null)+0x400C6C48 >>>>Library=/lib/libc.so.6 >>>> >>>>NOTE: We are unable to locate the function name symbol for the error >>>> just occurred. Please refer to release documentation for possible >>>> reason and solutions. >>>> >>>> >>>>Current Java thread: >>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) >>>> at it.devel.Dao.getBean(Dao.java:185) >>>> at it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) >>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) >>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) >>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) >>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) >>>> >>>>Dynamic libraries: >>>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java >>>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so >>>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so >>>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so >>>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so >>>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so >>>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so >>>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so >>>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so >>>>40173000-4056f000 r-xp 00000000 08:06 134540 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>>4056f000-4058b000 rwxp 003fb000 08:06 134540 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so >>>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so >>>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so >>>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so >>>>405d5000-405dd000 r-xp 00000000 08:06 101710 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>>405dd000-405de000 rwxp 00007000 08:06 101710 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>>405de000-405e2000 rwxs 00000000 08:09 14628 /tmp/hsperfdata_callstart/19866 >>>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so >>>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so >>>>405ed000-405fd000 r-xp 00000000 08:06 101717 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>>405fd000-405ff000 rwxp 0000f000 08:06 101717 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>>405ff000-4061f000 r-xp 00000000 08:06 101718 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>>4061f000-40621000 rwxp 0001f000 08:06 101718 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>>40621000-40635000 r-xp 00000000 08:06 101720 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>>40635000-40638000 rwxp 00013000 08:06 101720 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>>40638000-41fdf000 r-xs 00000000 08:06 101803 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar >>>>42029000-4203f000 r-xs 00000000 08:06 101742 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar >>>>4203f000-4211c000 r-xs 00000000 08:06 101787 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar >>>>4211c000-4212d000 r-xs 00000000 08:06 101743 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar >>>>4212d000-42686000 r-xs 00000000 08:06 101788 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar >>>>4472e000-4472f000 r-xs 00000000 08:06 117021 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar >>>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar >>>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar >>>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar >>>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar >>>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar >>>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar >>>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar >>>>4c92a000-4c930000 r-xs 00000000 08:06 117025 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar >>>>4c930000-4c936000 r-xs 00000000 08:06 117026 >>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar >>>>4c936000-4c939000 r-xp 00000000 08:06 377923 >>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so >>>>4c939000-4c93a000 rwxp 00002000 08:06 377923 >>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so >>>>4c93a000-4c950000 r-xp 00000000 08:06 265533 >>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 >>>>4c950000-4c953000 rwxp 00015000 08:06 265533 >>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 >>>>4c953000-4c998000 r-xp 00000000 08:06 377564 >>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 >>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 >>>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 >>>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so >>>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so >>>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 >>>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 >>>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 >>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 >>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>> >>>>Heap at VM Abort: >>>>Heap >>>>def new generation total 576K, used 236K [0x44730000, 0x447d0000, 0x44c10000) >>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) >>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) >>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) >>>>tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, 0x48730000) >>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, 0x44d70000) >>>>compacting perm gen total 4096K, used 1696K [0x48730000, 0x48b30000, 0x4c730000) >>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, 0x48b30000) >>>> >>>>Local Time = Fri Nov 11 15:34:29 2005 >>>>Elapsed Time = 771 >>>># >>>># The exception above was detected in native code outside the VM >>>># >>>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) >>>>- >>>>-------------------------------------------------------------------------------------------------------- >>>> >>>>At the moment is not so easy for me to update to 0.36.x. >>>>Does some one can help with that problem? >>>> >>>>Thanks in advance. >>>>-- >>>>============================================ >>>>Rodrigo P. Telles <te...@de...> >>>>IT Manager >>>>Devel-IT - http://www.devel.it >>>>IVOZ # 1029 >>>>+55 14 3324-1200 >>>>Bestcom Group >>>>============================================ > > >>------------------------------------------------------- >>SF.Net email is sponsored by: >>Tame your development challenges with Apache's Geronimo App Server. Download >>it for free - -and be entered to win a 42" plasma tv or your very own >>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>_______________________________________________ >>Sqlrelay-discussion mailing list >>Sql...@li... >>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>>>Register for a JBoss Training Course. Free Certification Exam >>>>for All Training Attendees Through End of 2005. For more info visit: >>>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>>>_______________________________________________ >>>>Sqlrelay-discussion mailing list >>>>Sql...@li... >>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > - ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Sqlrelay-discussion mailing list Sql...@li... https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoYNmiLK8unYgEMQRAt/+AJ9OuuOG13vyOueT/oz9bvyMI7ZDPwCfbMEI /+dCjLkRrXQ8Yx3uwFzQyqE= =/9xw -----END PGP SIGNATURE----- |
|
From: david f. <df...@vi...> - 2005-12-15 08:52:22
|
I'm under php5.1.1(identical problem with 5.0.x), and use pear D, postgres
8.0.4, oups : sqlrelay 0.37
I send the following array as fields_values for an autoExecute insert.
Array
(
[id] => 1
[creating_date] => CURRENT_DATE()
[modify_date] => CURRENT_DATE()
[last_login] => CURRENT_DATE()
[login] => my_log
[password] => my_pass
[reference] => 59C1134WBA6355
[other_id] => 126
)
the array is still ok just before the sqlrcur_inputBind() method in
PEAR::sqlrelay.php
but the sqlrelay debug function return :
Sending Query: INSERT INTO users
(id,creating_date,modify_date,last_login,login,password,reference,other_id)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8) Length: 164
Requesting a new cursor.
Sending 8 Input Bind Variables: id(4:LONG)=1
creating_date(15:STRING)=CURRENT_DATE()(14)
modify_date(13:STRING)=CURRENT_DATE()(14)
last_login(12:STRING)=CURRENT_DATE()(14) login(7:STRING)=my_log(10)
password(10:STRING)=my_pass(7) reference(11:STRING)=59C1134WBA6355(14)
other_id(5:STRING)=126(3)
Sending Output Bind Variables:
Send Column Info: yes
Skipping and Fetching row to get: 99 S
kipping 0 rows
Fetching 100 rows Checking For An Error... error!!!
Getting Error From Server ERREUR: La valeur «current» pour la date et
heure n'est plus supportée Attempted Query: INSERT INTO users
(id,creating_date,modify_date,last_login,login,password,reference,other_id)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8)
Getting Cursor ID... Cursor ID: 0
Aborting Result Set For Cursor: 0
Deallocated cursor
The question is :
1 Why sqlrelay is taking care off the value and the string quotation, it
is not at all is role ?
2 Why the postgres method CURRENT_DATE() is conciderate as a string ?(and
so quoted)
2 Why the value CURRENT_DATE() is output by the database error handle as
"current" only ?
Please help
Regards for all this great job
David
|
|
From: david f. <df...@vi...> - 2005-12-15 08:48:59
|
I'm under php5.1.1(identical problem with 5.0.x), and use pear D, postgres
8.0.4
I send the following array as fields_values for an autoExecute insert.
Array
(
[id] => 1
[creating_date] => CURRENT_DATE()
[modify_date] => CURRENT_DATE()
[last_login] => CURRENT_DATE()
[login] => my_log
[password] => my_pass
[reference] => 59C1134WBA6355
[other_id] => 126
)
the array is still ok just before the sqlrcur_inputBind() method in
PEAR::sqlrelay.php
but the sqlrelay debug function return :
Sending Query: INSERT INTO users
(id,creating_date,modify_date,last_login,login,password,reference,other_id)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8) Length: 164
Requesting a new cursor.
Sending 8 Input Bind Variables: id(4:LONG)=1
creating_date(15:STRING)=CURRENT_DATE()(14)
modify_date(13:STRING)=CURRENT_DATE()(14)
last_login(12:STRING)=CURRENT_DATE()(14) login(7:STRING)=my_log(10)
password(10:STRING)=my_pass(7) reference(11:STRING)=59C1134WBA6355(14)
other_id(5:STRING)=126(3)
Sending Output Bind Variables:
Send Column Info: yes
Skipping and Fetching row to get: 99 S
kipping 0 rows
Fetching 100 rows Checking For An Error... error!!!
Getting Error From Server ERREUR: La valeur «current» pour la date et
heure n'est plus supportée Attempted Query: INSERT INTO users
(id,creating_date,modify_date,last_login,login,password,reference,other_id)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8)
Getting Cursor ID... Cursor ID: 0
Aborting Result Set For Cursor: 0
Deallocated cursor
The question is :
1 Why sqlrelay is taking care off the value and the string quotation, it
is not at all is role ?
2 Why the postgres method CURRENT_DATE() is conciderate as a string ?(and
so quoted)
2 Why the value CURRENT_DATE() is output by the database error handle as
"current" only ?
Please help
Regards for all this great job
David
|
|
From: Albert V. <av...@im...> - 2005-12-14 19:22:06
|
Hi all,
I've just downloaded and tried the sqlrelay application. It looks
great, however, I have a problem trying to connect using more than one db.
I have the following conf:
<instances>
<instance id="example" port="9000" socket="/tmp/example.socket"
dbase="mysql" connections="3" maxconnections="15" maxqueuelength="5"
growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
runasuser="nobody" runasgroup="nobody" cursors="5" authtier="listener"
handoff="pass" deniedips="" allowedips="" debug="listener_and_connection">
<users>
<user user="mysqltest" password="mysqltest"/>
</users>
<connections>
<connection connectionid="db1"
string="user=yyy;password=xxx;db=db1;host=myhost" metric="1"/>
<connection connectionid="db2"
string="user=yyy;password=xxx;db=db2;host=myhost" metric="1"/>
</connections>
</instance>
</instances>
And i'm using the dbi api this way:
my
$dbh=DBI->connect("DBI:SQLRelay:host=localhost;port=9000;socket=","mysqltest","mysqltest");
The problem is how can I choose between one connection or another?
For example, I have this two querys:
select * from table_1 -> this query must run over the connectionid db1.
select * from table_2 -> this query must run over the connectionid db2.
I've not found the way to deal with this problem, because using
DBI->connect method I cannot set the connectionid parameter. If I use
the DBI->connect method, one query works fine and the other one not.
Am I doing something wrong?
Thanks in advance.
|
|
From: Gena01 <ge...@gm...> - 2005-12-13 21:03:33
|
Ok. I just did a full uninstall. Then pulled the new rudiments from CVS. installed that and got SQLRelay to compile. Now something that is a bit strange to me is that I set it up to connect to Oracle and when I do ps aux I get: nobody 20157 0.0 0.2 5088 2004 pts/42 S 15:48 0:00 sqlr-listener-debug -id pdl1x-greg -config /usr/local/firstwork nobody 20159 0.0 1.8 846544 17024 pts/42 S 15:48 0:00 sqlr-connection-oracle8-debug -id pdl1x-greg -connectionid db1 nobody 20161 0.0 1.8 846552 16768 pts/42 S 15:48 0:00 sqlr-connection-oracle8-debug -id pdl1x-greg -connectionid db1 nobody 20163 0.0 1.7 846364 16040 pts/42 S 15:48 0:00 sqlr-connection-oracle8-debug -id pdl1x-greg -connectionid db1 nobody 20165 0.0 0.2 5044 1924 ? S 15:48 0:00 sqlr-scaler -id pdl1x-greg -debug -config /usr/local/firstworks The thing that throws me off is that when I configured the instance to use 10 cursors each connection to oracle thread is taking up 846,544 kb. (Yes I know it's virtual, but it does seem quite large) I think that number was a bit lower with the last stable release. Anything responsible for this? Somehow when using Oracle client directly I don't think we are limited to the number of cursors we can have and I don't think it's using that much memory, but maybe I need to check this myself. P.S. It also seems that according to documentation that sqlrelay when going through Pear DB interface ignores the database parameter. I know it should be possible to use a different database other than default. Is it possible to make use of this parameter? So if I am connecting as another user (possibly with lower privileges) I could use a different database for the lifetime of my script. Thank you, Gena01 On 12/13/05, David Muse <dav...@fi...> wrote: > > Looks like you have an old version of SQL Relay and/or rudiments lying > around in /usr/local/firstworks. Make sure to delete that before trying > to build a new version. > > Dave > > On Fri, 2005-12-09 at 16:08 -0500, Gena01 wrote: > > I just pulled the latest CVS code as anonymous user and tried > > compiling and it's breaking for me. The first thing was changes to > > rudiments, which I pulled separately. Now I am stuck. I am getting: > > > > g++ -Wall -pipe -o .libs/query .libs/query.o > > -L/home/gennady/sqlrelay-cvs/sqlrelay/src/util > /home/gennady/sqlrelay-cvs/sqlrelay/src/util/.libs/libsqlrutil.so > -L/usr/local/firstworks/lib -L/usr/kerberos/lib > -L/home/gennady/sqlrelay-cvs/sqlrelay/src/api/c++/src > /usr/local/firstworks/lib/libsqlrclient.so > /usr/local/firstworks/lib/librudiments.so -lpthread -lssl -lcrypto > -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -lz -lrt -lcrypt > -ldl -Wl,--rpath -Wl,/usr/local/firstworks/lib > > .libs/query.o(.text+0x3a3): In function `main': > > : undefined reference to > > `sqlrconnection::sqlrconnection[in-charge](char const*, unsigned > > short, char const*, char const*, char const*, int, int)' > > .libs/query.o(.text+0x3ff): In function `main': > > : undefined reference to `sqlrcursor::setResultSetBufferSize(unsigned > > long long)' > > .libs/query.o(.text+0x4b0): In function `main': > > : undefined reference to `sqlrcursor::getField(unsigned long long, > > unsigned)' > > collect2: ld returned 1 exit status > > make[2]: *** [query] Error 1 > > > > Gena01 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: David M. <dav...@fi...> - 2005-12-13 19:53:09
|
It appears to be crashing inside a call to row::addField(). Strangely enough though, there are no delete[]'s inside of that method. Random stuff like that generally means that a buffer overrun occurred somewhere earlier and either overwrote a pointer or a return address or something and then the app either jumped off into the weeds or dereferenced a pointer to some invalid page of memory. These kinds of bugs tend to be very difficult to track down. The only good way is to link in ElectricFence to libsqlrclient.so and let it run for a while. ElectricFence will cause a segfault in the exact instruction that overran the buffer and will help narrow down the problem, but it makes apps run slower and use more memory. It would help to know what query caused the problem, and whether or not that query always causes a crash, or if it just happens if it's been running a while. Dave dav...@fi... On Mon, 2005-12-12 at 19:23 -0200, Rodrigo P. Telles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi David, > > Last week that error happend twice and I could see a new information in log files: > > free(): invalid pointer 0x4c8017a8! > > just seconds before the exception. > > Follow a new variation of the exception, now in the sqlrelay shared library: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4C94D171 > Function=_ZN3row8addFieldEiPKcm+0x37 > Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1 > > Current Java thread: > at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method) > at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183) > at it.devel.Dao.consulta(Dao.java:59) > at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118) > at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95) > at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233) > at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158) > at it.devel.Bilhetagem.main(Bilhetagem.java:738) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > 08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > 40173000-4056f000 r-xp 00000000 08:06 134540 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > 4056f000-4058b000 rwxp 003fb000 08:06 134540 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > 405d5000-405dd000 r-xp 00000000 08:06 101710 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > 405dd000-405de000 rwxp 00007000 08:06 101710 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > 405de000-405e2000 rwxs 00000000 08:09 14631 /tmp/hsperfdata_callstart/3923 > 405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so > 405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so > 405ed000-405fd000 r-xp 00000000 08:06 101717 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > 405fd000-405ff000 rwxp 0000f000 08:06 101717 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > 405ff000-4061f000 r-xp 00000000 08:06 101718 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > 4061f000-40621000 rwxp 0001f000 08:06 101718 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > 40621000-40635000 r-xp 00000000 08:06 101720 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > 40635000-40638000 rwxp 00013000 08:06 101720 > /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > 40638000-41fdf000 r-xs 00000000 08:06 101803 > /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > 42029000-4203f000 r-xs 00000000 08:06 101742 > /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > 4203f000-4211c000 r-xs 00000000 08:06 101787 > /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > 4211c000-4212d000 r-xs 00000000 08:06 101743 > /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > 4212d000-42686000 r-xs 00000000 08:06 101788 > /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > 4472e000-4472f000 r-xs 00000000 08:06 117021 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > 4c7dc000-4c898000 r-xs 00000000 08:06 117684 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > 4c898000-4c8a6000 r-xs 00000000 08:06 117022 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > 4c92a000-4c930000 r-xs 00000000 08:06 117025 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > 4c930000-4c936000 r-xs 00000000 08:06 117026 > /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > 4c936000-4c939000 r-xp 00000000 08:06 377923 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > ction.so > 4c939000-4c93a000 rwxp 00002000 08:06 377923 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne > ction.so > 4c93a000-4c950000 r-xp 00000000 08:06 265533 > /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > .so.1.0.0 > 4c950000-4c953000 rwxp 00015000 08:06 265533 > /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35 > .so.1.0.0 > 4c953000-4c998000 r-xp 00000000 08:06 377564 > /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > 4c998000-4c9a2000 rwxp 00044000 08:06 377564 > /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > 4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > 4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > 4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > r.so > 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso > r.so > > Heap at VM Abort: > Heap > def new generation total 576K, used 315K [0x44730000, 0x447d0000, 0x44c10000) > eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000) > from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000) > to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000) > tenured generation total 1408K, used 162K [0x44c10000, 0x44d70000, 0x48730000) > the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, 0x44d70000) > compacting perm gen total 4096K, used 1766K [0x48730000, 0x48b30000, 0x4c730000) > the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, 0x48b30000) > > Local Time = Mon Dec 12 16:37:48 2005 > Elapsed Time = 81 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > > > Thanks for any help! > > Telles > > Rodrigo P. Telles wrote: > > Hi David, > > > > Firstworks/4access wrote: > > > >>>Is it possible to reliably reproduce the problem with a particular > >>>query, or is it kind of random? > > > > > > No it doesn't, it happens in a random fashion. Could happens twice in a week or > > once in a month. > > > > > >>>Offhand, it looks like java is trying to run (or return from) a native > >>>C++ function and has the wrong address for the function (or wrong return > >>>address) and it ends up jumping off into the weeds, possibly into a > >>>non-executable page of memory. This typically happens when a buffer > >>>overrun occurs and overwrites a jump address. > >>> > >>>Does this happen with really long queries? With > > > > > > No it doesn't. > > It happens in a simple query using INSERT or SELECT! > > > > > >>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >>>It's possible that there's some kind of bug where the SQL Relay client > >>>is copying too much data and overrunning it's buffer. If it's only long > >>>queries, that would make sense and should be easy to patch. > >>> > >>>Let me know... > > > > > > Let me know if I can do any thing to "collect" more informations about that problem. > > Thanks for your answer. > > > > Telles > > > > > >>>David Muse > >>>dav...@fi... > >>> > >>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > >>> > >>>Hi Guys, > >>> > >>>I've been experiencing some errors using JAVA with sqlrelay-0.35 API and MySQL > >>>4.1.7 as a DB backend. > >>> > >>>Some thimes when I'm doing a query the application failed with that output > >>>exception: > >>>---------------------------------------------------------------------------------- > >>>An unexpected exception has been detected in native code outside the VM. > >>>Unexpected Signal : 11 occurred at PC=0x400C6C48 > >>>Function=(null)+0x400C6C48 > >>>Library=/lib/libc.so.6 > >>> > >>>NOTE: We are unable to locate the function name symbol for the error > >>> just occurred. Please refer to release documentation for possible > >>> reason and solutions. > >>> > >>> > >>>Current Java thread: > >>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > >>> at it.devel.Dao.getBean(Dao.java:185) > >>> at it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > >>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > >>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > >>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > >>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) > >>> > >>>Dynamic libraries: > >>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java > >>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>40173000-4056f000 r-xp 00000000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405dd000-405de000 rwxp 00007000 08:06 101710 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>405de000-405e2000 rwxs 00000000 08:09 14628 /tmp/hsperfdata_callstart/19866 > >>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so > >>>405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>40621000-40635000 r-xp 00000000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40635000-40638000 rwxp 00013000 08:06 101720 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>42029000-4203f000 r-xs 00000000 08:06 101742 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>4212d000-42686000 r-xs 00000000 08:06 101788 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7 > >>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5 > >>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>> > >>>Heap at VM Abort: > >>>Heap > >>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, 0x44c10000) > >>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > >>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > >>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > >>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, 0x48730000) > >>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, 0x44d70000) > >>> compacting perm gen total 4096K, used 1696K [0x48730000, 0x48b30000, 0x4c730000) > >>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, 0x48b30000) > >>> > >>>Local Time = Fri Nov 11 15:34:29 2005 > >>>Elapsed Time = 771 > >>># > >>># The exception above was detected in native code outside the VM > >>># > >>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>>- > >>>-------------------------------------------------------------------------------------------------------- > >>> > >>>At the moment is not so easy for me to update to 0.36.x. > >>>Does some one can help with that problem? > >>> > >>>Thanks in advance. > >>>-- > >>>============================================ > >>>Rodrigo P. Telles <te...@de...> > >>>IT Manager > >>>Devel-IT - http://www.devel.it > >>>IVOZ # 1029 > >>>+55 14 3324-1200 > >>>Bestcom Group > >>>============================================ > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. Download > > it for free - -and be entered to win a 42" plasma tv or your very own > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > Sqlrelay-discussion mailing list > > Sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > > > > > > > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >>>Register for a JBoss Training Course. Free Certification Exam > >>>for All Training Attendees Through End of 2005. For more info visit: > >>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >>>_______________________________________________ > >>>Sqlrelay-discussion mailing list > >>>Sql...@li... > >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDnepPiLK8unYgEMQRAsaUAJ91+Psu77Wo/Z6OQjPYqLRH9f7f2QCeKXsR > 4RAFI3Go5Wd38918vMTbwOk= > =is1Z > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: David M. <dav...@fi...> - 2005-12-13 19:38:31
|
Looks like you have an old version of SQL Relay and/or rudiments lying around in /usr/local/firstworks. Make sure to delete that before trying to build a new version. Dave On Fri, 2005-12-09 at 16:08 -0500, Gena01 wrote: > I just pulled the latest CVS code as anonymous user and tried > compiling and it's breaking for me. The first thing was changes to > rudiments, which I pulled separately. Now I am stuck. I am getting: > > g++ -Wall -pipe -o .libs/query .libs/query.o > -L/home/gennady/sqlrelay-cvs/sqlrelay/src/util /home/gennady/sqlrelay-cvs/sqlrelay/src/util/.libs/libsqlrutil.so -L/usr/local/firstworks/lib -L/usr/kerberos/lib -L/home/gennady/sqlrelay-cvs/sqlrelay/src/api/c++/src /usr/local/firstworks/lib/libsqlrclient.so /usr/local/firstworks/lib/librudiments.so -lpthread -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -lz -lrt -lcrypt -ldl -Wl,--rpath -Wl,/usr/local/firstworks/lib > .libs/query.o(.text+0x3a3): In function `main': > : undefined reference to > `sqlrconnection::sqlrconnection[in-charge](char const*, unsigned > short, char const*, char const*, char const*, int, int)' > .libs/query.o(.text+0x3ff): In function `main': > : undefined reference to `sqlrcursor::setResultSetBufferSize(unsigned > long long)' > .libs/query.o(.text+0x4b0): In function `main': > : undefined reference to `sqlrcursor::getField(unsigned long long, > unsigned)' > collect2: ld returned 1 exit status > make[2]: *** [query] Error 1 > > Gena01 |
|
From: David M. <dav...@fi...> - 2005-12-13 19:35:09
|
Well, I see where it's crashing, but it's not obvious why. It looks
like memcpy() is causing the crash. That can happen when the source or
destination buffer pointers are invalid or the length is too long. That
usually happens when a buffer overrun somewhere else in the app
overwrites one of them with some garbage value. Those are notoriously
hard to track down. The only sure-fire way is to link ElectricFence
into your app. It'll cause the app to crash on the exact instruction
that overran the buffer. ElectricFence will make your app use a lot of
memory though, so it may or may not be possible to use it.
What language is your app written in? If it's c/c++ then there could be
a bug in it that's causing the crash. If it's something else, then
there is likely a bug in SQL Relay causing the crash. Either way, it'll
help narrow it down. It would also help to know the query that caused
the crash, and whether running that query always causes it to crash or
just after it's been running for a while.
David Muse
dav...@fi...
On Mon, 2005-12-05 at 17:21 +0900, =EB=B0=95=EC=A4=80=ED=9D=AC wrote:
> Hi
>=20
> =20
>=20
> I am working on setting up an multithreaded application with below os
> & library.
>=20
> =20
>=20
> OS: linux fc3
>=20
> Compiler: gcc 3.4.2 20041017
>=20
> Mysql-4.1.15
>=20
> Rudiments-0.28.2
>=20
> Sqlrelay-0.36.4
>=20
> =20
>=20
> For stress test. Concurrent 50 transaction loop 1000000 count.
>=20
> One day after, our application abnormal terminationtion with dump.
>=20
> 50 x 2856 transaction succeded.
>=20
> =20
>=20
> Below, gdb bactrace result.
>=20
> Any ideas? Whats it looking for?
>=20
> =20
>=20
> Thanks!
>=20
> ***************************************************
>=20
> =20
>=20
> (gdb) bt
>=20
> #0 0x001b04dc in memcpy () from /lib/tls/libc.so.6
>=20
> #1 0xf6e3869c in rudiments::rawbuffer::copy ()
>=20
> from /usr/local/firstworks/lib/librudiments-0.28.2.so.1
>=20
> #2 0xf6e1be1c in rudiments::filedescriptor::bufferedRead ()
>=20
> from /usr/local/firstworks/lib/librudiments-0.28.2.so.1
>=20
> #3 0xf6e1b720 in rudiments::filedescriptor::read ()
>=20
> from /usr/local/firstworks/lib/librudiments-0.28.2.so.1
>=20
> #4 0xf6fb8233 in sqlrcursor::getString ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #5 0xf6fb91fb in sqlrcursor::parseOutputBinds ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #6 0xf6fb77a7 in sqlrcursor::processResultSet ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #7 0xf6fb637c in sqlrcursor::runQuery ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #8 0xf6fb5aff in sqlrcursor::executeQuery ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #9 0xf6fb59e3 in sqlrcursor::sendQuery ()
>=20
> from /usr/local/firstworks/lib/libsqlrclient-0.36.4.so.1
>=20
> #10 0x08057e3b in CPxDB::get_contents (this=3D0x8bda688, aQuery=3D
>=20
> {static npos =3D 4294967295, _M_dataplus =3D
> {<std::allocator<char>> =3D {<__gnu_cxx::new_allocator<char>> =3D {<No
> data fields>}, <No data fields>}, _M_p =3D 0xc90f5034 "select Contents
> from ContentsTbl where Id in
> ('7975a859-1c30-a8d3-f807-3ade5511da7a','11d36c03-9978-02a6-126d-be5f23=
85b81e','51627791-31ed-69e2-4a62-0a9966749997','c5e7087a-4ba3-83ea-71c4-1=
0bca8059919"...}}, contents=3D@0x8f5723e0)
>=20
> at src/PxDB.cpp:167
>=20
> #11 0x0804cd99 in CPxThread::contents (this=3D0x8bdb088) at
> src/PxThread.cpp:424
>=20
> #12 0x0804c222 in CPxThread::transaction (this=3D0x8bdb088)
>=20
> at src/PxThread.cpp:228
>=20
> #13 0x0804be98 in CPxThread::responder (th_arg=3D0x8bdb088)
>=20
> at src/PxThread.cpp:150
>=20
> #14 0x0038b1d5 in start_thread () from /lib/tls/libpthread.so.0
>=20
> #15 0x0020c2da in clone () from /lib/tls/libc.so.6
>=20
> =20
>=20
>=20
|
|
From: David M. <dav...@fi...> - 2005-12-13 19:19:53
|
Sorry to take so long to respond... Actually, there is no good way to talk to SQL Relay from windows yet. Some parts work under cygwin, but CSQLRelay.so doesn't yet. I'm working on it, but it may be a while. David Muse dav...@fi... On Thu, 2005-12-01 at 10:51 -0600, D.Aguilera wrote: > Hi, > > I'm currently using sqlrelay installed in a Linux box. > > In the same box I installed the python api to access sqlrelay from > mod_python and nevow. ( same box also ). > > What I need now is to access sqlrelay from python inWindows XP. I've > checked the code and there's a dependency on a library... CSQLRelay.so > to make the api work. > > Is there any dll or pyd available for windows? > > Tks > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: Jose S. <js...@si...> - 2005-12-13 19:14:26
|
Hi,
=A0
My name is Jose and I'm having a problem with sqlrelay 0.36.2. I'm using =
Debian linux stable, PHP 4.3, and ORACLE 9.2.
=A0
The current sqlrelay configuration is:
=A0
<instance id=3D"test-con" port=3D"9090" socket=3D"/tmp/test-con.socket" d=
base=3D"oracle8" connections=3D"0" maxconnections=3D"25" maxqueuelength=3D=
"0" growby=3D"3" ttl=3D"60" endofsession=3D"commit" sessiontimeout=3D"600=
" runasuser=3D"oracle" runasgroup=3D"oracle" cursors=3D"10" authtier=3D"l=
istener" handoff=3D"pass">
<users>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <user=
user=3D"test" password=3D"test"/>
</users>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <connections>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <conn=
ection connectionid=3D"test" string=3D"user=3Dtest;password=3Dtest;oracle=
_sid=3DJOSE.WORLD" metric=3D"1"/>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </connections>
</instance>
=A0
As you can see, we have a ttl of 60. Here is the problem I'm currently ha=
ving:
=A0
The benchmark environment is set up so the site gets 3 requests every 5-1=
0 seconds, which needs between 1 and 3 connections active. (Note that we =
have an average of 25 queries per PHP page)
=A0
If I run apache benchmark requesting 500 pages with a level of concurrenc=
y of 5, the number of connections in the pool increases to reach 12-15.
=A0
The problem comes after the apache benchmark is done. Since the volume of=
requests goes down again, I was expecting to see the number of connectio=
ns in the pool going down after 60 seconds of inactivity, but this does n=
ot happen.
=A0
If I run the apache benchmark again (500 pages and 5 concurrency) the num=
ber of connections would go up again to reach 21-24. After the requests a=
re handled, the number of connections would not decrease.
=A0
This is a problem because it seems that those connections used during hig=
h volumes of requests are not available anymore once they have been inact=
ive more than 60 seconds, and instead of being released, they stay in the=
pool and not available for more upcoming requests.
=A0
If I run the same experiment described above with a 15 TTL this problem d=
oes not happen. The number of connections goes down right after the conne=
ctions have been inactive more than that TTL.
=A0
Here is an excerpt of the debug statements found in the connections that =
have this problem (60 TTL):
=A0=A0
12/09/2005 00:36:10 GMT connection [18919] : done initializing session...
=A0
12/09/2005 00:36:10 GMT connection [18919] : announcing availability...
=A0
12/09/2005 00:36:10 GMT connection [18919] :=A0=A0=A0 acquiring announce =
mutex
=A0=A0
---- Stuck here ---
=A0
=A0
And this is what I got when using 15 TTL:
=A0
12/08/2005 14:28:34 PST connection [31305] : initializing session...
=A0
12/08/2005 14:28:34 PST connection [31305] : done initializing session...
=A0
12/08/2005 14:28:34 PST connection [31305] : announcing availability...
=A0
12/08/2005 14:28:34 PST connection [31305] :=A0=A0=A0 acquiring announce =
mutex
=A0
12/08/2005 14:29:34 PST connection [31305] : decrementing connection coun=
t...
=A0
---- Releases resources just fine ----
Do you have any ideas on why the 60 TTL is causing this problem?.
=A0
Also, if I go ahead with the 15 TTL, what would be the performance impact=
in my application?
=A0
Any ideas/help would be much appreciated
=A0
Thanks in advance.=20
|
|
From: Rodrigo P. T. <te...@de...> - 2005-12-12 21:23:49
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi David,
Last week that error happend twice and I could see a new information in log files:
free(): invalid pointer 0x4c8017a8!
just seconds before the exception.
Follow a new variation of the exception, now in the sqlrelay shared library:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4C94D171
Function=_ZN3row8addFieldEiPKcm+0x37
Library=/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1
Current Java thread:
at com.firstworks.sqlrelay.SQLRCursor.sendQuery(Native Method)
at it.devel.SqlRelayDAO.consulta(SqlRelayDAO.java:183)
at it.devel.Dao.consulta(Dao.java:59)
at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:118)
at it.devel.e164.FullE164DAO.buscaCNS(FullE164DAO.java:95)
at it.devel.Bilhetagem.bilhetaSMART(Bilhetagem.java:233)
at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:158)
at it.devel.Bilhetagem.main(Bilhetagem.java:738)
Dynamic libraries:
08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java
08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java
40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so
40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so
40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so
40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so
4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so
4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so
4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so
40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so
40173000-4056f000 r-xp 00000000 08:06 134540
/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so
4056f000-4058b000 rwxp 003fb000 08:06 134540
/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so
405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so
405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so
405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so
405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so
405d5000-405dd000 r-xp 00000000 08:06 101710
/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so
405dd000-405de000 rwxp 00007000 08:06 101710
/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so
405de000-405e2000 rwxs 00000000 08:09 14631 /tmp/hsperfdata_callstart/3923
405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so
405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so
405ed000-405fd000 r-xp 00000000 08:06 101717
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so
405fd000-405ff000 rwxp 0000f000 08:06 101717
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so
405ff000-4061f000 r-xp 00000000 08:06 101718
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so
4061f000-40621000 rwxp 0001f000 08:06 101718
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so
40621000-40635000 r-xp 00000000 08:06 101720
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so
40635000-40638000 rwxp 00013000 08:06 101720
/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so
40638000-41fdf000 r-xs 00000000 08:06 101803
/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar
42029000-4203f000 r-xs 00000000 08:06 101742
/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar
4203f000-4211c000 r-xs 00000000 08:06 101787
/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar
4211c000-4212d000 r-xs 00000000 08:06 101743
/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar
4212d000-42686000 r-xs 00000000 08:06 101788
/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar
4472e000-4472f000 r-xs 00000000 08:06 117021
/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar
4c7b0000-4c7cc000 r-xs 00000000 08:06 117679
/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar
4c7cc000-4c7cf000 r-xs 00000000 08:06 117680
/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar
4c7cf000-4c7dc000 r-xs 00000000 08:06 117682
/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar
4c7dc000-4c898000 r-xs 00000000 08:06 117684
/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar
4c898000-4c8a6000 r-xs 00000000 08:06 117022
/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar
4c8a6000-4c8d3000 r-xs 00000000 08:06 117023
/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar
4c8d3000-4c92a000 r-xs 00000000 08:06 117024
/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar
4c92a000-4c930000 r-xs 00000000 08:06 117025
/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar
4c930000-4c936000 r-xs 00000000 08:06 117026
/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar
4c936000-4c939000 r-xp 00000000 08:06 377923
/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne
ction.so
4c939000-4c93a000 rwxp 00002000 08:06 377923
/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConne
ction.so
4c93a000-4c950000 r-xp 00000000 08:06 265533
/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35
.so.1.0.0
4c950000-4c953000 rwxp 00015000 08:06 265533
/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35
.so.1.0.0
4c953000-4c998000 r-xp 00000000 08:06 377564
/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0
4c998000-4c9a2000 rwxp 00044000 08:06 377564
/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0
4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7
4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7
4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7
4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7
4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so
4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so
4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5
4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5
4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1
4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1
4cbad000-4cbb7000 r-xp 00000000 08:06 377924
/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso
r.so
4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924
/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCurso
r.so
Heap at VM Abort:
Heap
def new generation total 576K, used 315K [0x44730000, 0x447d0000, 0x44c10000)
eden space 512K, 56% used [0x44730000, 0x447783d8, 0x447b0000)
from space 64K, 41% used [0x447c0000, 0x447c6b00, 0x447d0000)
to space 64K, 0% used [0x447b0000, 0x447b0000, 0x447c0000)
tenured generation total 1408K, used 162K [0x44c10000, 0x44d70000, 0x48730000)
the space 1408K, 11% used [0x44c10000, 0x44c38818, 0x44c38a00, 0x44d70000)
compacting perm gen total 4096K, used 1766K [0x48730000, 0x48b30000, 0x4c730000)
the space 4096K, 43% used [0x48730000, 0x488e9b30, 0x488e9c00, 0x48b30000)
Local Time = Mon Dec 12 16:37:48 2005
Elapsed Time = 81
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
Thanks for any help!
Telles
Rodrigo P. Telles wrote:
> Hi David,
>
> Firstworks/4access wrote:
>
>>>Is it possible to reliably reproduce the problem with a particular
>>>query, or is it kind of random?
>
>
> No it doesn't, it happens in a random fashion. Could happens twice in a week or
> once in a month.
>
>
>>>Offhand, it looks like java is trying to run (or return from) a native
>>>C++ function and has the wrong address for the function (or wrong return
>>>address) and it ends up jumping off into the weeds, possibly into a
>>>non-executable page of memory. This typically happens when a buffer
>>>overrun occurs and overwrites a jump address.
>>>
>>>Does this happen with really long queries? With
>
>
> No it doesn't.
> It happens in a simple query using INSERT or SELECT!
>
>
>>>Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query.
>>>It's possible that there's some kind of bug where the SQL Relay client
>>>is copying too much data and overrunning it's buffer. If it's only long
>>>queries, that would make sense and should be easy to patch.
>>>
>>>Let me know...
>
>
> Let me know if I can do any thing to "collect" more informations about that problem.
> Thanks for your answer.
>
> Telles
>
>
>>>David Muse
>>>dav...@fi...
>>>
>>>On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote:
>>>
>>>Hi Guys,
>>>
>>>I've been experiencing some errors using JAVA with sqlrelay-0.35 API and MySQL
>>>4.1.7 as a DB backend.
>>>
>>>Some thimes when I'm doing a query the application failed with that output
>>>exception:
>>>----------------------------------------------------------------------------------
>>>An unexpected exception has been detected in native code outside the VM.
>>>Unexpected Signal : 11 occurred at PC=0x400C6C48
>>>Function=(null)+0x400C6C48
>>>Library=/lib/libc.so.6
>>>
>>>NOTE: We are unable to locate the function name symbol for the error
>>> just occurred. Please refer to release documentation for possible
>>> reason and solutions.
>>>
>>>
>>>Current Java thread:
>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method)
>>> at it.devel.Dao.getBean(Dao.java:185)
>>> at it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131)
>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342)
>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320)
>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141)
>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693)
>>>
>>>Dynamic libraries:
>>>08048000-08056000 r-xp 00000000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java
>>>08056000-08059000 rwxp 0000d000 08:06 246208 /usr/local/j2sdk1.4.2_06/bin/java
>>>40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so
>>>40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so
>>>40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so
>>>40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so
>>>4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so
>>>4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so
>>>4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so
>>>40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so
>>>40173000-4056f000 r-xp 00000000 08:06 134540
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so
>>>4056f000-4058b000 rwxp 003fb000 08:06 134540
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so
>>>405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so
>>>405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so
>>>405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so
>>>405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so
>>>405d5000-405dd000 r-xp 00000000 08:06 101710
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so
>>>405dd000-405de000 rwxp 00007000 08:06 101710
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so
>>>405de000-405e2000 rwxs 00000000 08:09 14628 /tmp/hsperfdata_callstart/19866
>>>405e3000-405ec000 r-xp 00000000 08:05 213015 /lib/libnss_files-2.3.3.so
>>>405ec000-405ed000 rwxp 00009000 08:05 213015 /lib/libnss_files-2.3.3.so
>>>405ed000-405fd000 r-xp 00000000 08:06 101717
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so
>>>405fd000-405ff000 rwxp 0000f000 08:06 101717
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so
>>>405ff000-4061f000 r-xp 00000000 08:06 101718
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so
>>>4061f000-40621000 rwxp 0001f000 08:06 101718
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so
>>>40621000-40635000 r-xp 00000000 08:06 101720
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so
>>>40635000-40638000 rwxp 00013000 08:06 101720
>>>/usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so
>>>40638000-41fdf000 r-xs 00000000 08:06 101803
>>>/usr/local/j2sdk1.4.2_06/jre/lib/rt.jar
>>>42029000-4203f000 r-xs 00000000 08:06 101742
>>>/usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar
>>>4203f000-4211c000 r-xs 00000000 08:06 101787
>>>/usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar
>>>4211c000-4212d000 r-xs 00000000 08:06 101743
>>>/usr/local/j2sdk1.4.2_06/jre/lib/jce.jar
>>>4212d000-42686000 r-xs 00000000 08:06 101788
>>>/usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar
>>>4472e000-4472f000 r-xs 00000000 08:06 117021
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar
>>>4c7b0000-4c7cc000 r-xs 00000000 08:06 117679
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar
>>>4c7cc000-4c7cf000 r-xs 00000000 08:06 117680
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar
>>>4c7cf000-4c7dc000 r-xs 00000000 08:06 117682
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar
>>>4c7dc000-4c898000 r-xs 00000000 08:06 117684
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar
>>>4c898000-4c8a6000 r-xs 00000000 08:06 117022
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar
>>>4c8a6000-4c8d3000 r-xs 00000000 08:06 117023
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar
>>>4c8d3000-4c92a000 r-xs 00000000 08:06 117024
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar
>>>4c92a000-4c930000 r-xs 00000000 08:06 117025
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar
>>>4c930000-4c936000 r-xs 00000000 08:06 117026
>>>/usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar
>>>4c936000-4c939000 r-xp 00000000 08:06 377923
>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so
>>>4c939000-4c93a000 rwxp 00002000 08:06 377923
>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so
>>>4c93a000-4c950000 r-xp 00000000 08:06 265533
>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0
>>>4c950000-4c953000 rwxp 00015000 08:06 265533
>>>/usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0
>>>4c953000-4c998000 r-xp 00000000 08:06 377564
>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0
>>>4c998000-4c9a2000 rwxp 00044000 08:06 377564
>>>/usr/local/firstworks/lib/librudiments-0.27.so.1.0.0
>>>4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7
>>>4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7
>>>4c9d5000-4caab000 r-xp 00000000 08:06 115306 /usr/lib/libcrypto.so.0.9.7
>>>4caab000-4cabc000 rwxp 000d6000 08:06 115306 /usr/lib/libcrypto.so.0.9.7
>>>4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so
>>>4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so
>>>4caec000-4cb8a000 r-xp 00000000 08:06 114711 /usr/lib/libstdc++.so.5.0.5
>>>4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 /usr/lib/libstdc++.so.5.0.5
>>>4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1
>>>4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1
>>>4cbad000-4cbb7000 r-xp 00000000 08:06 377924
>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so
>>>4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924
>>>/usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so
>>>
>>>Heap at VM Abort:
>>>Heap
>>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, 0x44c10000)
>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000)
>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000)
>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000)
>>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, 0x48730000)
>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, 0x44d70000)
>>> compacting perm gen total 4096K, used 1696K [0x48730000, 0x48b30000, 0x4c730000)
>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, 0x48b30000)
>>>
>>>Local Time = Fri Nov 11 15:34:29 2005
>>>Elapsed Time = 771
>>>#
>>># The exception above was detected in native code outside the VM
>>>#
>>># Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
>>>-
>>>--------------------------------------------------------------------------------------------------------
>>>
>>>At the moment is not so easy for me to update to 0.36.x.
>>>Does some one can help with that problem?
>>>
>>>Thanks in advance.
>>>--
>>>============================================
>>>Rodrigo P. Telles <te...@de...>
>>>IT Manager
>>>Devel-IT - http://www.devel.it
>>>IVOZ # 1029
>>>+55 14 3324-1200
>>>Bestcom Group
>>>============================================
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
>
>
>
>
>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
>>>Register for a JBoss Training Course. Free Certification Exam
>>>for All Training Attendees Through End of 2005. For more info visit:
>>>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>>>_______________________________________________
>>>Sqlrelay-discussion mailing list
>>>Sql...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDnepPiLK8unYgEMQRAsaUAJ91+Psu77Wo/Z6OQjPYqLRH9f7f2QCeKXsR
4RAFI3Go5Wd38918vMTbwOk=
=is1Z
-----END PGP SIGNATURE-----
|
16 messages has been excluded from this view by a project administrator.
