Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330822

Summary:	[breakpoints] import changes attributes from String to Integer or Boolean
Product:	[Eclipse Project] Platform	Reporter:	Alan Boxall <boxall>
Component:	Debug	Assignee:	Platform-Debug-Inbox <platform-debug-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	curtis.windatt.public, Michael_Rennie, pawel.1.piech
Version:	3.6.1
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Alan Boxall

2010-11-22 11:25:48 EST

Build Identifier: 3.6.1 M20101013-0800

Breakpoint marker attributes that were written as Strings are imported as an Integer (if the attribute value is a valid number) or Boolean (if the attribute is a valid boolean value)
This causes problems for attributes that are expected to be strings even if they have a valid Integer or Boolean value.

For example a file name can be called "1" and is stored as a string in a "FileName" attribute but is imported as an Integer.

Not sure why the ImportBreakpointOperation.readAttribute() method doesn't use the same readAttribute strategy as Marker

As a workaround I will have to add ".toString" for each attribute I read in and expect to be a string.

I feel that the core code should respect the attribute type.

Reproducible: Always

Comment 1 Michael Rennie

2010-11-22 12:57:27 EST

The problem is with the way we write + read the .bkpt file. Unlike persisted IMarkers we do not have the attributes set in their own kind of entry.

IMarker attributes are stored in their own named entry in the memento like INTEGER_ATTRIBUTE, BOOLEAN_ATTRIBUTE, etc. Whereas in our bkpt file we store entries as just ATTRIB. Had we been thinking at the time we should have stored them according to their kind like IMarkers do.

That being said, we would have to move to a system like that (the IMarker scheme)to ensure this problem does not occur or add a 'type' field to the ATTRIB in the bkpt file. Either way we have to be careful to maintain backwards compatibility for reading older file formats.

For example we could add a 'type' field like:

<attrib name="workingset_name" value="" type=STRING/>

or make individual attribute kinds, like:

<int_attrib name="org.eclipse.jdt.debug.core.installCount" value="0"/>
<bool_attrib name="org.eclipse.jdt.debug.core.caught" value="false"/>
<str_attrib name="workingset_name" value=""/>

Comment 2 Alan Boxall

2010-11-22 13:06:36 EST

I would think that most implementors of import/export do not expect strings to potentially come back as Integers or Booleans.   So rather than be a compatibility issue this may fix incorrectly imported breakpoint attributes.

I know when we coded the import part of our breakpoint support we expected attributes to come back as we had described them.

Comment 3 Michael Rennie

2010-11-22 14:21:46 EST

(In reply to comment #2)
> I would think that most implementors of import/export do not expect strings to
> potentially come back as Integers or Booleans.   So rather than be a
> compatibility issue this may fix incorrectly imported breakpoint attributes.
> 

I agree 100%, but we would have to ensure the import code could still read a .bkpt file that does not have the new kind of attributes.

Comment 4 Lars Vogel

2019-11-14 03:46:52 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.