Extracting Structural Information from Bug Reports.

20
Rahul Premraj Saarland University, Germany Tom Zimmermann University of Calgary, Canada Nicolas Bettenburg Saarland University, Germany Sunghun Kim MIT CSAIL, Boston, USA Extracting Structural Information from Bug Reports

description

Bug Reports are usually treated as text. This is sub-optimal, since bug reports contain many structural elements, such as stack traces, source code, patches, enumerations or screenshots, that should not be treated as natural language text. Using this structured information can be used to faciliate better research processes and automated bug fixing techniques. We propose the infoZilla tool, that can detect and extract structural elements from bug reports and display its high presicion and recall.

Transcript of Extracting Structural Information from Bug Reports.

Page 1: Extracting Structural Information from Bug Reports.

Rahul PremrajSaarland University, Germany

Tom ZimmermannUniversity of Calgary, Canada

Nicolas BettenburgSaarland University, Germany

Sunghun KimMIT CSAIL, Boston, USA

Extracting Structural Information

from Bug Reports

Page 2: Extracting Structural Information from Bug Reports.

Bug Reports

In standard approaches: entirely treated as text.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Page 3: Extracting Structural Information from Bug Reports.

Bug Reports

In standard approaches: entirely treated as text.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

But they containmore

Page 4: Extracting Structural Information from Bug Reports.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Page 5: Extracting Structural Information from Bug Reports.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Source Code1

Page 6: Extracting Structural Information from Bug Reports.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Source Code1

Page 7: Extracting Structural Information from Bug Reports.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Patch2

Page 8: Extracting Structural Information from Bug Reports.

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

------- Comment #2 From Marcelo Paternostro 2006-04-27 10:44:24 -0400 -------

Fixed in the I200604270000 built

------- Comment #3 From Nick Boldt 2008-01-28 16:46:51 -0400 -------

Move to verified as per bug 206558.

Stack Trace3

Patch2

Page 9: Extracting Structural Information from Bug Reports.

SOURCE CODE

PATCHES

The infoZilla Tool

Detects and Extracts suchStructural Information:

STACK TRACES

ENUMERATIONS

Bug 137808

Summary: Exceptions from createFromString lock-up the editor

Product: [Modeling] EMF Reporter: Patrick Sodre <[email protected]>

Component: Core Assignee: Marcelo Paternostro <[email protected]>

Status: VERIFIED FIXED QA Contact:

Severity: normal

Priority: P3 CC: [email protected]

Version: 2.2

Target Milestone: ---

Hardware: PC

OS: Windows XP

Whiteboard:

Description: Opened: 2006-04-20 14:25 -0400

As discussed on the newsgroup under the Thread with the same name I am opening

this bug entry. Here is a history of the thread.

-- From Ed Merks

Patrick,

The value is checked before it's applied and can't be applied until it's valid.

But this BigDecimal cases behaves oddly because the exception thrown by

new BigDecimal("badvalue")

has a null message and the property editor relies on returning a non-null

message string to indicate there is an error.

Please open a bugzilla which I'll fix like this:

### Eclipse Workspace Patch 1.0

#P org.eclipse.emf.edit.ui

Index: src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java

===================================================================

RCS file:

/cvsroot/tools/org.eclipse.emf/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java,v

retrieving revision 1.10

diff -u -r1.10 PropertyDescriptor.java

--- src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 21 Mar 2006

16:42:30 -0000 1.10

+++ src/org/eclipse/emf/edit/ui/provider/PropertyDescriptor.java 20 Apr 2006

11:59:10 -0000

@@ -162,7 +162,8 @@

}

catch (Exception exception)

{

- return exception.getMessage();

+ String message = exception.getMessage();

+ return message == null ? exception.toString() : message;

}

}

Diagnostic diagnostic =

Diagnostician.INSTANCE.validate(EDataTypeCellEditor.this.eDataType, value);

Patrick Sodre wrote:

Hi,

It seems that if the user inputs an invalid parameter that gets created from

"createFromString" the Editor locks-up until the user explicitly calls "restore

Default Value".

Is this the expected behavior or could something better be done? For

instance if an exception is thrown restore the value back to what it was before

after displaying a pop-up error message.

I understand that for DataTypes defined by the user he/she should take care

of catching the exceptions but for the default ones like BigInteger/BigDecimal

I think the EMF runtime could do some of the grunt work...

If you think this is something worth pursuing I could post an entry in

Bugzilla.

Regards,

Patrick Sodre

Below is the stack trace that I got from the Editor...

java.lang.NumberFormatException

at java.math.BigDecimal.<init>(BigDecimal.java:368)

at java.math.BigDecimal.<init>(BigDecimal.java:647)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEBigDecimalFromString(EcoreFactoryImpl.java:559)

at

org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createFromString(EcoreFactoryImpl.java:116)

at

org.eclipse.emf.edit.ui.provider.PropertyDescriptor$EDataTypeCellEditor.doGetValue(PropertyDescriptor.java:183)

at org.eclipse.jface.viewers.CellEditor.getValue(CellEditor.java:449)

at

org.eclipse.ui.views.properties.PropertySheetEntry.applyEditorValue(PropertySheetEntry.java:135)

at

org.eclipse.ui.views.properties.PropertySheetViewer.applyEditorValue(PropertySheetViewer.java:249)

at

------- Comment #1 From Ed Merks 2006-04-20 15:09:23 -0400 -------

The fix has been committed to CVS. Thanks for reporting this problem.

Page 10: Extracting Structural Information from Bug Reports.

Evaluating the Performance

Has SOURCE CODE ? Has PATCHES ? Has

ENUMERATIONS ?Has STACK TRACES ?

HGFEC DBA

YES NO YES NO YES NO YES NO

BUG

REPORT

BUG

REPORT

BUG

REPORT

BUG

REPORT

61334 61334 61334 61334

Page 11: Extracting Structural Information from Bug Reports.

Evaluating the Performance

Has SOURCE CODE ? Has PATCHES ? Has

ENUMERATIONS ?Has STACK TRACES ?

HGFEC DBA

‣ Parse 161,500 reports from ECLIPSE.

YES NO YES NO YES NO YES NO

BUG

REPORT

BUG

REPORT

BUG

REPORT

BUG

REPORT

61334 61334 61334 61334

Page 12: Extracting Structural Information from Bug Reports.

Evaluating the Performance

Has SOURCE CODE ? Has PATCHES ? Has

ENUMERATIONS ?Has STACK TRACES ?

HGFEC DBA

‣ Parse 161,500 reports from ECLIPSE.‣ From ... randomly sample 100 reports each.A H

YES NO YES NO YES NO YES NO

BUG

REPORT

BUG

REPORT

BUG

REPORT

BUG

REPORT

61334 61334 61334 61334

Page 13: Extracting Structural Information from Bug Reports.

Evaluating the Performance

Has SOURCE CODE ? Has PATCHES ? Has

ENUMERATIONS ?Has STACK TRACES ?

HGFEC DBA

‣ Parse 161,500 reports from ECLIPSE.‣ From ... randomly sample 100 reports each.‣ Manually inspect these 800 reports.

A H

YES NO YES NO YES NO YES NO

BUG

REPORT

BUG

REPORT

BUG

REPORT

BUG

REPORT

61334 61334 61334 61334

Page 14: Extracting Structural Information from Bug Reports.

Detection of Elements

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Precision Recall

95%99% 100%97% 100%100% 99%98%

Source Code Patches Stack Traces Enumerations

Page 15: Extracting Structural Information from Bug Reports.

Extraction of Elements

4%5% 91%

Perfect extraction More than 50% correct Less than 50% correct

Extraction Performance:

13%

21%

65%

Patches Source Code

Page 16: Extracting Structural Information from Bug Reports.

Extraction of Elements

9%

7%

84%

Perfect extraction More than 50% correct Less than 50% correct

Extraction Performance:

9%2%

89%

Stack Traces Enumerations

Page 17: Extracting Structural Information from Bug Reports.

Applications of infoZilla

Do duplicates contain additional information?

Page 18: Extracting Structural Information from Bug Reports.

Applications of infoZilla

Do duplicates contain additional information?

Stack Traces

23,857

7,909

Original Reports Extended Reports (Original + Duplicates)Amount of unique information available in:

Source Code Lines

494,302

318,526

Page 19: Extracting Structural Information from Bug Reports.

Do duplicates contain additional information?

Applications of infoZilla

Page 20: Extracting Structural Information from Bug Reports.

Inspect crash patterns using stack traces.

Do duplicates contain additional information?

Support automated bug triaging.

Applications of infoZilla