[jira] [Created] (DERBY-6951) ClientPreparedStatement may be buggy
Hao Zhong created DERBY-6951:
Summary: ClientPreparedStatement may be buggy
Key: DERBY-6951
URL: https://issues.apache.org/jira/browse/DERBY-6951
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Hao Zhong
DERBY-1610 fixed some bugs in PreparedStatement.java. I find that the buggy
file is similar to ClientPreparedStatement.java. For example, both files have
the following code:
{code}
public void setBigDecimal(int parameterIndex, java.math.BigDecimal x) throws
SQLException {
try
{
synchronized (connection_) {
if (agent_.loggingEnabled()) {
agent_.logWriter_.traceEntry(this, "setBigDecimal",
parameterIndex, x);
}
final int paramType =
getColumnMetaDataX().getColumnType(parameterIndex);
...
}
catch ( SqlException se )
{
throw se.getSQLException();
}
}
{code}
The fixed code is as follow:
{code}
public void setBigDecimal(int parameterIndex, java.math.BigDecimal x) throws
SQLException {
try
{
synchronized (connection_) {
if (agent_.loggingEnabled()) {
agent_.logWriter_.traceEntry(this, "setBigDecimal",
parameterIndex, x);
}
final int paramType =
getColumnMetaDataX().getColumnType(
checkForEscapedCallWithResult( parameterIndex ) );
...
}
catch ( SqlException se )
{
throw se.getSQLException();
}
}
{code}
The repair can be applied to ClientPreparedStatement.java
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (DERBY-6950) ClientConnection may be buggy
Hao Zhong created DERBY-6950:
Summary: ClientConnection may be buggy
Key: DERBY-6950
URL: https://issues.apache.org/jira/browse/DERBY-6950
Project: Derby
Issue Type: Bug
Reporter: Hao Zhong
DERBY-210 fixed some leaked statements in Connection.java. I notice that
ClientConnection. java is similar to the buggy version of Connection.java. For
example, both files have the following methods:
{code}
synchronized PreparedStatement prepareDynamicCatalogQuery(String sql) throws
SqlException {
PreparedStatement ps = newPreparedStatement_(sql,
java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY,
resultSetHoldability_, java.sql.Statement.NO_GENERATED_KEYS, null);
ps.isCatalogQuery_ = true;
ps.prepare();
openStatements_.put(ps,null);
return ps;
}
{code}
The fixed version of Connection.java is as follow:
{code}
synchronized PreparedStatement prepareDynamicCatalogQuery(String sql) throws
SqlException {
PreparedStatement ps = newPreparedStatement_(sql,
java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY,
resultSetHoldability_, java.sql.Statement.NO_GENERATED_KEYS, null);
ps.isCatalogQuery_ = true;
ps.prepare();
openStatements_.add(ps);
return ps;
}
{code}
It is worthy exploring whehter ClientConnection. java has similar problems. If
it is, it can be fixed as how DERBY-210 was fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6946) Argument checking for EmbedResultSet_setFetchSize(int) may be incorrect
[
https://issues.apache.org/jira/browse/DERBY-6946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075697#comment-16075697
]
Hao Zhong commented on DERBY-6946:
--
It turns out that my repository is out of date. I will update my repository.
> Argument checking for EmbedResultSet_setFetchSize(int) may be incorrect
> ---
>
> Key: DERBY-6946
> URL: https://issues.apache.org/jira/browse/DERBY-6946
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
>
> The EmbedResultSet_setFetchSize method has the following code to check its
> argument:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkStatus();
> if (rows < 0 || (this.getMaxRows() != 0 &&
> rows > this.getMaxRows()))
> {
> throw newSQLException(SQLState.INVALID_ST_FETCH_SIZE, rows);
> }else if ( rows > 0 ) // ignore the call if the value is zero
> fetchSize = rows;
> }
> {code}
> The check seems to be incorrect. DERBY-3573 fixed a similar problem, and
> explained why the check is incorrect. The buggy code is as follow:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkIfClosed("setFetchSize");
> if (rows < 0 || (stmt.getMaxRows() != 0 && rows >
> stmt.getMaxRows())) {
> throw
> Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
> new Integer(rows));
> } else if (rows > 0) // if it is zero ignore the call
> {
> fetchSize = rows;
> }
> }
> {code}
> The fixed code is:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkIfClosed("setFetchSize");
> if (rows < 0) {
> throw
> Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
> new Integer(rows));
> } else if (rows > 0) // if it is zero ignore the call
> {
> fetchSize = rows;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6946) Argument checking for EmbedResultSet_setFetchSize(int) may be incorrect
[
https://issues.apache.org/jira/browse/DERBY-6946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Zhong updated DERBY-6946:
-
Description:
The EmbedResultSet_setFetchSize method has the following code to check its
argument:
{code}
public void setFetchSize(int rows) throws SQLException {
checkStatus();
if (rows < 0 || (this.getMaxRows() != 0 &&
rows > this.getMaxRows()))
{
throw newSQLException(SQLState.INVALID_ST_FETCH_SIZE, rows);
}else if ( rows > 0 ) // ignore the call if the value is zero
fetchSize = rows;
}
{code}
The check seems to be incorrect. DERBY-3573 fixed a similar problem, and
explained why the check is incorrect. The buggy code is as follow:
{code}
public void setFetchSize(int rows) throws SQLException {
checkIfClosed("setFetchSize");
if (rows < 0 || (stmt.getMaxRows() != 0 && rows >
stmt.getMaxRows())) {
throw
Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
new Integer(rows));
} else if (rows > 0) // if it is zero ignore the call
{
fetchSize = rows;
}
}
{code}
The fixed code is:
{code}
public void setFetchSize(int rows) throws SQLException {
checkIfClosed("setFetchSize");
if (rows < 0) {
throw
Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
new Integer(rows));
} else if (rows > 0) // if it is zero ignore the call
{
fetchSize = rows;
}
}
{code}
was:
The EmbedResultSet_setFetchSize method has the following code to check its
argument:
{code}
public void setFetchSize(int rows) throws SQLException {
checkStatus();
if (rows < 0 || (this.getMaxRows() != 0 &&
rows > this.getMaxRows()))
{
throw newSQLException(SQLState.INVALID_ST_FETCH_SIZE, rows);
}else if ( rows > 0 ) // ignore the call if the value is zero
fetchSize = rows;
}
{code}
The check seems to be incorrect. DERBY-3573 fixed a similar problem, and
explained why the check is incorrect. The buggy code is identical, and the
fixed code is:
{code}
public void setFetchSize(int rows) throws SQLException {
checkIfClosed("setFetchSize");
if (rows < 0) {
throw
Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
new Integer(rows));
} else if (rows > 0) // if it is zero ignore the call
{
fetchSize = rows;
}
}
{code}
> Argument checking for EmbedResultSet_setFetchSize(int) may be incorrect
> ---
>
> Key: DERBY-6946
> URL: https://issues.apache.org/jira/browse/DERBY-6946
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
>
> The EmbedResultSet_setFetchSize method has the following code to check its
> argument:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkStatus();
> if (rows < 0 || (this.getMaxRows() != 0 &&
> rows > this.getMaxRows()))
> {
> throw newSQLException(SQLState.INVALID_ST_FETCH_SIZE, rows);
> }else if ( rows > 0 ) // ignore the call if the value is zero
> fetchSize = rows;
> }
> {code}
> The check seems to be incorrect. DERBY-3573 fixed a similar problem, and
> explained why the check is incorrect. The buggy code is as follow:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkIfClosed("setFetchSize");
> if (rows < 0 || (stmt.getMaxRows() != 0 && rows >
> stmt.getMaxRows())) {
> throw
> Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
> new Integer(rows));
> } else if (rows > 0) // if it is zero ignore the call
> {
> fetchSize = rows;
> }
> }
> {code}
> The fixed code is:
> {code}
> public void setFetchSize(int rows) throws SQLException {
> checkIfClosed("setFetchSize");
> if (rows < 0) {
> throw
> Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
> new Integer(rows));
> } else if (rows > 0) // if it is zero ignore the call
> {
> fetchSize = rows;
>
[jira] [Created] (DERBY-6946) Argument checking for EmbedResultSet_setFetchSize(int) may be incorrect
Hao Zhong created DERBY-6946:
Summary: Argument checking for EmbedResultSet_setFetchSize(int)
may be incorrect
Key: DERBY-6946
URL: https://issues.apache.org/jira/browse/DERBY-6946
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.12.1.1
Reporter: Hao Zhong
The EmbedResultSet_setFetchSize method has the following code to check its
argument:
{code}
public void setFetchSize(int rows) throws SQLException {
checkStatus();
if (rows < 0 || (this.getMaxRows() != 0 &&
rows > this.getMaxRows()))
{
throw newSQLException(SQLState.INVALID_ST_FETCH_SIZE, rows);
}else if ( rows > 0 ) // ignore the call if the value is zero
fetchSize = rows;
}
{code}
The check seems to be incorrect. DERBY-3573 fixed a similar problem, and
explained why the check is incorrect. The buggy code is identical, and the
fixed code is:
{code}
public void setFetchSize(int rows) throws SQLException {
checkIfClosed("setFetchSize");
if (rows < 0) {
throw
Util.generateCsSQLException(SQLState.INVALID_FETCH_SIZE,
new Integer(rows));
} else if (rows > 0) // if it is zero ignore the call
{
fetchSize = rows;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6927) SystemProcedures.hasSchema can fail to close the resultset.
[
https://issues.apache.org/jira/browse/DERBY-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937582#comment-15937582
]
Hao Zhong commented on DERBY-6927:
--
Indeed, it's my research project. It infers bug signatures from your past
fixes, and uses inferred bug signatures to detect new bugs.
My tool reads your past fixes and try to understand what happens when repairing
bugs. For your questions, it sounds like that I read your source code to locate
the buggy code.
Hope that my work can be useful to you.
> SystemProcedures.hasSchema can fail to close the resultset.
> ---
>
> Key: DERBY-6927
> URL: https://issues.apache.org/jira/browse/DERBY-6927
> Project: Derby
> Issue Type: Bug
> Components: Services
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
> Attachments: derby.patch
>
>
> The SystemProcedures.hasSchema method has the following code:
> {code:title=SystemProcedures.java|borderStyle=solid}
> ResultSet rs = conn.getMetaData().getSchemas();
> boolean schemaFound = false;
> while (rs.next() && !schemaFound)
> schemaFound = schemaName.equals(rs.getString("TABLE_SCHEM"));
> rs.close();
> {code}
> The while statement can throw exceptions, so the rs.close can never be
> executed. Indeed, DERBY-6297 fixed a similar bug. The buggy code is:
> {code:title=AccessDatabase.java|borderStyle=solid}
> boolean found=false;
> ResultSet result = conn.getMetaData().getSchemas();
> while(result.next()){
> if(result.getString(1).equals(schema)){
> found=true;
> break;
> }
> }
> return found;
> {code}
> The fixed code ensures that result is closed:
> {code:title=AccessDatabase.java|borderStyle=solid}
> ResultSet result = conn.getMetaData().getSchemas();
> try {
> while (result.next()) {
> if (result.getString(1).equals(schema)) {
> // Found it!
> return true;
> }
> }
> } finally {
> result.close();
> }
> // Didn't find the schema.
> return false;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (DERBY-6927) SystemProcedures.hasSchema can fail to close the resultset.
[
https://issues.apache.org/jira/browse/DERBY-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Zhong updated DERBY-6927:
-
Attachment: derby.patch
> SystemProcedures.hasSchema can fail to close the resultset.
> ---
>
> Key: DERBY-6927
> URL: https://issues.apache.org/jira/browse/DERBY-6927
> Project: Derby
> Issue Type: Bug
> Components: Services
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
> Attachments: derby.patch
>
>
> The SystemProcedures.hasSchema method has the following code:
> {code:title=SystemProcedures.java|borderStyle=solid}
> ResultSet rs = conn.getMetaData().getSchemas();
> boolean schemaFound = false;
> while (rs.next() && !schemaFound)
> schemaFound = schemaName.equals(rs.getString("TABLE_SCHEM"));
> rs.close();
> {code}
> The while statement can throw exceptions, so the rs.close can never be
> executed. Indeed, DERBY-6297 fixed a similar bug. The buggy code is:
> {code:title=AccessDatabase.java|borderStyle=solid}
> boolean found=false;
> ResultSet result = conn.getMetaData().getSchemas();
> while(result.next()){
> if(result.getString(1).equals(schema)){
> found=true;
> break;
> }
> }
> return found;
> {code}
> The fixed code ensures that result is closed:
> {code:title=AccessDatabase.java|borderStyle=solid}
> ResultSet result = conn.getMetaData().getSchemas();
> try {
> while (result.next()) {
> if (result.getString(1).equals(schema)) {
> // Found it!
> return true;
> }
> }
> } finally {
> result.close();
> }
> // Didn't find the schema.
> return false;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (DERBY-6928) The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string values
Hao Zhong created DERBY-6928: Summary: The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string values Key: DERBY-6928 URL: https://issues.apache.org/jira/browse/DERBY-6928 Project: Derby Issue Type: Improvement Components: Build tools Reporter: Hao Zhong Priority: Minor As some values are defined in org.apache.derby.iapi.types.TypeId, it is easier to maintain the code, if we replace them accordingly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (DERBY-6927) SystemProcedures.hasSchema can fail to close the resultset.
[
https://issues.apache.org/jira/browse/DERBY-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Zhong updated DERBY-6927:
-
Summary: SystemProcedures.hasSchema can fail to close the resultset. (was:
SystemProcedures.hasSchema does not close the resultset.)
> SystemProcedures.hasSchema can fail to close the resultset.
> ---
>
> Key: DERBY-6927
> URL: https://issues.apache.org/jira/browse/DERBY-6927
> Project: Derby
> Issue Type: Bug
> Components: Services
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
>
> The SystemProcedures.hasSchema method has the following code:
> {code:title=SystemProcedures.java|borderStyle=solid}
> ResultSet rs = conn.getMetaData().getSchemas();
> boolean schemaFound = false;
> while (rs.next() && !schemaFound)
> schemaFound = schemaName.equals(rs.getString("TABLE_SCHEM"));
> rs.close();
> {code}
> The while statement can throw exceptions, so the rs.close can never be
> executed. Indeed, DERBY-6297 fixed a similar bug. The buggy code is:
> {code:title=AccessDatabase.java|borderStyle=solid}
> boolean found=false;
> ResultSet result = conn.getMetaData().getSchemas();
> while(result.next()){
> if(result.getString(1).equals(schema)){
> found=true;
> break;
> }
> }
> return found;
> {code}
> The fixed code ensures that result is closed:
> {code:title=AccessDatabase.java|borderStyle=solid}
> ResultSet result = conn.getMetaData().getSchemas();
> try {
> while (result.next()) {
> if (result.getString(1).equals(schema)) {
> // Found it!
> return true;
> }
> }
> } finally {
> result.close();
> }
> // Didn't find the schema.
> return false;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (DERBY-6927) SystemProcedures.hasSchema doe not close the resultset.
Hao Zhong created DERBY-6927:
Summary: SystemProcedures.hasSchema doe not close the resultset.
Key: DERBY-6927
URL: https://issues.apache.org/jira/browse/DERBY-6927
Project: Derby
Issue Type: Bug
Components: Services
Affects Versions: 10.12.1.1
Reporter: Hao Zhong
The SystemProcedures.hasSchema method has the following code:
{code:title=SystemProcedures.java|borderStyle=solid}
ResultSet rs = conn.getMetaData().getSchemas();
boolean schemaFound = false;
while (rs.next() && !schemaFound)
schemaFound = schemaName.equals(rs.getString("TABLE_SCHEM"));
rs.close();
{code}
The while statement can throw exceptions, so the rs.close can never be
executed. Indeed, DERBY-6297 fixed a similar bug. The buggy code is:
{code:title=AccessDatabase.java|borderStyle=solid}
boolean found=false;
ResultSet result = conn.getMetaData().getSchemas();
while(result.next()){
if(result.getString(1).equals(schema)){
found=true;
break;
}
}
return found;
{code}
The fixed code ensures that result is closed:
{code:title=AccessDatabase.java|borderStyle=solid}
ResultSet result = conn.getMetaData().getSchemas();
try {
while (result.next()) {
if (result.getString(1).equals(schema)) {
// Found it!
return true;
}
}
} finally {
result.close();
}
// Didn't find the schema.
return false;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (DERBY-6927) SystemProcedures.hasSchema does not close the resultset.
[
https://issues.apache.org/jira/browse/DERBY-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Zhong updated DERBY-6927:
-
Summary: SystemProcedures.hasSchema does not close the resultset. (was:
SystemProcedures.hasSchema doe not close the resultset.)
> SystemProcedures.hasSchema does not close the resultset.
>
>
> Key: DERBY-6927
> URL: https://issues.apache.org/jira/browse/DERBY-6927
> Project: Derby
> Issue Type: Bug
> Components: Services
>Affects Versions: 10.12.1.1
>Reporter: Hao Zhong
>
> The SystemProcedures.hasSchema method has the following code:
> {code:title=SystemProcedures.java|borderStyle=solid}
> ResultSet rs = conn.getMetaData().getSchemas();
> boolean schemaFound = false;
> while (rs.next() && !schemaFound)
> schemaFound = schemaName.equals(rs.getString("TABLE_SCHEM"));
> rs.close();
> {code}
> The while statement can throw exceptions, so the rs.close can never be
> executed. Indeed, DERBY-6297 fixed a similar bug. The buggy code is:
> {code:title=AccessDatabase.java|borderStyle=solid}
> boolean found=false;
> ResultSet result = conn.getMetaData().getSchemas();
> while(result.next()){
> if(result.getString(1).equals(schema)){
> found=true;
> break;
> }
> }
> return found;
> {code}
> The fixed code ensures that result is closed:
> {code:title=AccessDatabase.java|borderStyle=solid}
> ResultSet result = conn.getMetaData().getSchemas();
> try {
> while (result.next()) {
> if (result.getString(1).equals(schema)) {
> // Found it!
> return true;
> }
> }
> } finally {
> result.close();
> }
> // Didn't find the schema.
> return false;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (DERBY-6926) InitPageOperation does not check before reading and writing
Hao Zhong created DERBY-6926:
Summary: InitPageOperation does not check before reading and
writing
Key: DERBY-6926
URL: https://issues.apache.org/jira/browse/DERBY-6926
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.12.1.1
Reporter: Hao Zhong
The readExternal and writeExternal methods are not checked before reading and
writing. Indeed, other classes do check before that. For example,
CompressSpacePageOperation implements the above two methods, and both are
checked. In particular, the code of CompressSpacePageOperation.readExternal is:
public void readExternal(ObjectInput in)
throws IOException, ClassNotFoundException
{
super.readExternal(in);
if( !(this instanceof CompressSpacePageOperation10_2) )
{
newHighestPage = in.readInt();
num_pages_truncated = CompressedNumber.readInt(in);
}
}
The code of InitPageOperation.readExternal is:
public void readExternal(ObjectInput in)
throws IOException, ClassNotFoundException
{
super.readExternal(in);
nextRecordId = CompressedNumber.readInt(in);
initFlag = CompressedNumber.readInt(in);
pageOffset = CompressedNumber.readLong(in);
pageFormatId = in.readInt();
}.
It is better to guide the method as CompressSpacePageOperation does.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
