Home » Modeling » GMF (Graphical Modeling Framework) » StackOverflowError with shared EditingDomain
| StackOverflowError with shared EditingDomain [message #143937] |
Tue, 24 July 2007 16:13  |
Eclipse User |
|
|
|
Hi everyone,
I am trying to get the generated GMF diagram editor to share its
TransactionalEditingDomain with my custom views and the EMF editor.
I have figured out how to get my subclassed GMF diagram editor to use my
editing domain -- I override the following:
@Override
protected IDocumentProvider getDocumentProvider(IEditorInput input)
{
if (input instanceof IFileEditorInput
|| input instanceof URIEditorInput)
{
return ???SyncDocumentProvider.INSTANCE;
}
return super.getDocumentProvider(input);
}
@Override
public IDocumentProvider getDocumentProvider()
{
return ???SyncDocumentProvider.INSTANCE;
}
Meanwhile, my ???SyncDocumentProvider has the following code:
public static ???SyncDocumentProvider INSTANCE = new ???
SyncDocumentProvider();
@Override
protected IDocument createEmptyDocument()
{
DiagramDocument document = new DiagramDocument();
document.setEditingDomain((TransactionalEditingDomain)
Context.getInstance().getEditingDomain());
return document;
}
The Context.getInstance().getEditingDomain() returns my EditingDomain
from the singleton instance in which it is registered.
Now, what ends up happening is the EditingDomain sharing seems to be
working for certain operations. Notably, renames, property changes, copy/
paste, even drag and drop. All of these operations take effect without
error.
However, any _pure create_ events -- creating a new Node, or creating a
child of a Node inside a compartment, or creating a connection among
nodes -- in short, anything that utilizes a CreateElementCommand, and is
accessible via the Palette Creation Tools, causes a huge stack trace.
The cause of failure is a StackOverflowError. You can see the stack
trace here:
http://pastebin.com/m69f3f97f
(lots of repetition, but note especially the top and the bottom)
This is especially puzzling for me because certain operations -- like a
node Copy/Paste operation -- actually create a new element in the
semantic model, and this occurs without error. Only "pure creation"
commands will fail.
The following notes may also be helpful:
1. although this stack trace occurs, the semantic element is actually
still created, but the notational view for it (the NodeEditPart in the
case of a Node) is not created.
2. a knock-on effect is that after this stack overflow occurs, the
diagram editor no longer functions properly. Even if I close all
resources and re-open them, the diagram editor will not allow any changes
to the View -- you can't move a NodeEditPart, change its color, or
anything like that.
3. after the stack overflow, any changes to the semantic model (like
renaming a node) will be reflected in the semantic model, but the View in
the GraphicalEditPart will not reflect those changes. In other words, a
rename will appear to have done nothing, even though it worked -- and the
diagram editor will even be marked as dirty, and saving/reopening will
reflect the change.
I know this is a lot of information, but I'm hoping someone will
recognize this problem and give me a hint in the right direction.
Much appreciated,
Andrew J. Montalenti
p.s. I'm using GMF 2.0RC1
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #146359 is a reply to message #143937] |
Mon, 13 August 2007 04:46  |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Andrew Montalenti wrote:
> Hi everyone,
>
> I am trying to get the generated GMF diagram editor to share its
> TransactionalEditingDomain with my custom views and the EMF editor.
>
[..snip overrides..]
> Now, what ends up happening is the EditingDomain sharing seems to be
> working for certain operations. Notably, renames, property changes, copy/
> paste, even drag and drop. All of these operations take effect without
> error.
>
> However, any _pure create_ events -- creating a new Node, or creating a
> child of a Node inside a compartment, or creating a connection among
> nodes -- in short, anything that utilizes a CreateElementCommand, and is
> accessible via the Palette Creation Tools, causes a huge stack trace.
>
> The cause of failure is a StackOverflowError.
I'm seeing the same kind of error, although my stack trace (attached)
doesn't display anything useful at the bottom (maybe the message stack
was full?):
!SESSION 2007-08-13 10:17:07.067
-----------------------------------------------
eclipse.buildId=I20070601-1539
java.version=1.6.0_01
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL
Framework arguments: -product org.eclipse.sdk.ide -pdelaunch
Command-line arguments: -product org.eclipse.sdk.ide -data C:\Documents
and Settings\rladan\workspace\mt-test -dev file:C:/Documents and
Settings/rladan/workspace/.metadata/.plugins/org.eclipse.pde .core/metatest/dev.properties
-pdelaunch -debug C:\Documents and
Settings\rladan\workspace\.metadata\.plugins\org.eclipse.pde .core\metatest/.options
-os win32 -ws win32 -arch x86
<whole bunch of "MESSAGE NLS unused" messages>
!ENTRY org.eclipse.ui 4 0 2007-08-13 10:18:13.509
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.StackOverflowError
at
org.eclipse.core.runtime.ProgressMonitorWrapper.internalWork ed(ProgressMonitorWrapper.java:94)
at
org.eclipse.core.runtime.SubProgressMonitor.internalWorked(S ubProgressMonitor.java:155)
<ad infinitum>
> This is especially puzzling for me because certain operations -- like a
> node Copy/Paste operation -- actually create a new element in the
> semantic model, and this occurs without error. Only "pure creation"
> commands will fail.
Here too.
>
> The following notes may also be helpful:
>
> 1. although this stack trace occurs, the semantic element is actually
> still created, but the notational view for it (the NodeEditPart in the
> case of a Node) is not created.
>
Here too, but if I close and re-open the resource, GMF shows the newly
created element.
> 2. a knock-on effect is that after this stack overflow occurs, the
> diagram editor no longer functions properly. Even if I close all
> resources and re-open them, the diagram editor will not allow any changes
> to the View -- you can't move a NodeEditPart, change its color, or
> anything like that.
>
Here too, but if I close and re-open the resource, movements work again.
[..snip renaming..]
> p.s. I'm using GMF 2.0RC1
Eclipse 3.3.0 I20070625-1500, EMF 2.3.0v20070626, GEF 3.3.0v20070620,
GMF 1.0.100.v20070601, JDK 1.6.0 update 2
The strange thing is that it used to work. A working setup seemed to be
one before July 10th. After that I _did_ change the models:
1. change & validate the ecore model because of some new requirements
2. update the genmodel file
3. regenerate the EMF editor (ok)
Now the GMF editor is broken as described.
4. update & validate the gmfgraph file to match some renamings in the
ecore file.
5. check if the gmftool file needs updating (no)
6. update & validate the gmfmap file
7. regenerate & validate the gmfgen file
8. regenerate the GMF editor
Now it is still broken.
Regards,
Rene
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #146376 is a reply to message #146359] |
Mon, 13 August 2007 05:03 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Rene Ladan wrote:
> Andrew Montalenti wrote:
>> Hi everyone,
>>
>> I am trying to get the generated GMF diagram editor to share its
>> TransactionalEditingDomain with my custom views and the EMF editor.
>>
> [..snip overrides..]
>
>> Now, what ends up happening is the EditingDomain sharing seems to be
>> working for certain operations. Notably, renames, property changes,
>> copy/
>> paste, even drag and drop. All of these operations take effect
>> without error.
>>
>> However, any _pure create_ events -- creating a new Node, or creating
>> a child of a Node inside a compartment, or creating a connection among
>> nodes -- in short, anything that utilizes a CreateElementCommand, and
>> is accessible via the Palette Creation Tools, causes a huge stack trace.
>>
>> The cause of failure is a StackOverflowError.
>
> I'm seeing the same kind of error, although my stack trace (attached)
> doesn't display anything useful at the bottom (maybe the message stack
> was full?):
>
> !SESSION 2007-08-13 10:17:07.067
> -----------------------------------------------
> eclipse.buildId=I20070601-1539
> java.version=1.6.0_01
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL
> Framework arguments: -product org.eclipse.sdk.ide -pdelaunch
> Command-line arguments: -product org.eclipse.sdk.ide -data C:\Documents
> and Settings\rladan\workspace\mt-test -dev file:C:/Documents and
> Settings/rladan/workspace/.metadata/.plugins/org.eclipse.pde .core/metatest/dev.properties
> -pdelaunch -debug C:\Documents and
> Settings\rladan\workspace\.metadata\.plugins\org.eclipse.pde .core\metatest/.options
> -os win32 -ws win32 -arch x86
>
> <whole bunch of "MESSAGE NLS unused" messages>
>
> !ENTRY org.eclipse.ui 4 0 2007-08-13 10:18:13.509
> !MESSAGE Unhandled event loop exception
> !STACK 0
> java.lang.StackOverflowError
> at
> org.eclipse.core.runtime.ProgressMonitorWrapper.internalWork ed(ProgressMonitorWrapper.java:94)
>
> at
> org.eclipse.core.runtime.SubProgressMonitor.internalWorked(S ubProgressMonitor.java:155)
>
> <ad infinitum>
>
>> This is especially puzzling for me because certain operations -- like
>> a node Copy/Paste operation -- actually create a new element in the
>> semantic model, and this occurs without error. Only "pure creation"
>> commands will fail.
> Here too.
>
>>
>> The following notes may also be helpful:
>>
>> 1. although this stack trace occurs, the semantic element is
>> actually still created, but the notational view for it (the
>> NodeEditPart in the case of a Node) is not created.
>>
> Here too, but if I close and re-open the resource, GMF shows the newly
> created element.
>
>> 2. a knock-on effect is that after this stack overflow occurs, the
>> diagram editor no longer functions properly. Even if I close all
>> resources and re-open them, the diagram editor will not allow any
>> changes to the View -- you can't move a NodeEditPart, change its
>> color, or anything like that.
>>
> Here too, but if I close and re-open the resource, movements work again.
>
> [..snip renaming..]
>
I'm also seeing that the Core property view of the generated GMF editor
stays empty (no name/value pairs) if I select an element. This means I
cannot change any property of any element, except creating/removing
child elements.
>> p.s. I'm using GMF 2.0RC1
>
> Eclipse 3.3.0 I20070625-1500, EMF 2.3.0v20070626, GEF 3.3.0v20070620,
> GMF 1.0.100.v20070601, JDK 1.6.0 update 2
>
> The strange thing is that it used to work. A working setup seemed to be
> one before July 10th. After that I _did_ change the models:
>
> 1. change & validate the ecore model because of some new requirements
> 2. update the genmodel file
> 3. regenerate the EMF editor (ok)
> Now the GMF editor is broken as described.
> 4. update & validate the gmfgraph file to match some renamings in the
> ecore file.
> 5. check if the gmftool file needs updating (no)
> 6. update & validate the gmfmap file
> 7. regenerate & validate the gmfgen file
> 8. regenerate the GMF editor
> Now it is still broken.
>
I don't know if it has anything to do with it, but I see that the GMF
code generator creates identical source files (apart from whitespace)
for some elements. These files have almost the same name, except for
their 'serial number' (none, '2', '3', etc.). Can this be caused when
you regenerate the Java code?
> Regards,
> Rene
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #146515 is a reply to message #146359] |
Tue, 14 August 2007 05:42 |
| Eclipse User |
|
|
|
Hi,
I am having the same kind of problem. Could anybody help us out ?
greets
dawid
Rene Ladan schrieb:
> Andrew Montalenti wrote:
>> Hi everyone,
>>
>> I am trying to get the generated GMF diagram editor to share its
>> TransactionalEditingDomain with my custom views and the EMF editor.
>>
> [..snip overrides..]
>
>> Now, what ends up happening is the EditingDomain sharing seems to be
>> working for certain operations. Notably, renames, property changes,
>> copy/
>> paste, even drag and drop. All of these operations take effect
>> without error.
>>
>> However, any _pure create_ events -- creating a new Node, or creating
>> a child of a Node inside a compartment, or creating a connection among
>> nodes -- in short, anything that utilizes a CreateElementCommand, and
>> is accessible via the Palette Creation Tools, causes a huge stack trace.
>>
>> The cause of failure is a StackOverflowError.
>
> I'm seeing the same kind of error, although my stack trace (attached)
> doesn't display anything useful at the bottom (maybe the message stack
> was full?):
>
> !SESSION 2007-08-13 10:17:07.067
> -----------------------------------------------
> eclipse.buildId=I20070601-1539
> java.version=1.6.0_01
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL
> Framework arguments: -product org.eclipse.sdk.ide -pdelaunch
> Command-line arguments: -product org.eclipse.sdk.ide -data C:\Documents
> and Settings\rladan\workspace\mt-test -dev file:C:/Documents and
> Settings/rladan/workspace/.metadata/.plugins/org.eclipse.pde .core/metatest/dev.properties
> -pdelaunch -debug C:\Documents and
> Settings\rladan\workspace\.metadata\.plugins\org.eclipse.pde .core\metatest/.options
> -os win32 -ws win32 -arch x86
>
> <whole bunch of "MESSAGE NLS unused" messages>
>
> !ENTRY org.eclipse.ui 4 0 2007-08-13 10:18:13.509
> !MESSAGE Unhandled event loop exception
> !STACK 0
> java.lang.StackOverflowError
> at
> org.eclipse.core.runtime.ProgressMonitorWrapper.internalWork ed(ProgressMonitorWrapper.java:94)
>
> at
> org.eclipse.core.runtime.SubProgressMonitor.internalWorked(S ubProgressMonitor.java:155)
>
> <ad infinitum>
>
>> This is especially puzzling for me because certain operations -- like
>> a node Copy/Paste operation -- actually create a new element in the
>> semantic model, and this occurs without error. Only "pure creation"
>> commands will fail.
> Here too.
>
>>
>> The following notes may also be helpful:
>>
>> 1. although this stack trace occurs, the semantic element is
>> actually still created, but the notational view for it (the
>> NodeEditPart in the case of a Node) is not created.
>>
> Here too, but if I close and re-open the resource, GMF shows the newly
> created element.
>
>> 2. a knock-on effect is that after this stack overflow occurs, the
>> diagram editor no longer functions properly. Even if I close all
>> resources and re-open them, the diagram editor will not allow any
>> changes to the View -- you can't move a NodeEditPart, change its
>> color, or anything like that.
>>
> Here too, but if I close and re-open the resource, movements work again.
>
> [..snip renaming..]
>
>
>> p.s. I'm using GMF 2.0RC1
>
> Eclipse 3.3.0 I20070625-1500, EMF 2.3.0v20070626, GEF 3.3.0v20070620,
> GMF 1.0.100.v20070601, JDK 1.6.0 update 2
>
> The strange thing is that it used to work. A working setup seemed to be
> one before July 10th. After that I _did_ change the models:
>
> 1. change & validate the ecore model because of some new requirements
> 2. update the genmodel file
> 3. regenerate the EMF editor (ok)
> Now the GMF editor is broken as described.
> 4. update & validate the gmfgraph file to match some renamings in the
> ecore file.
> 5. check if the gmftool file needs updating (no)
> 6. update & validate the gmfmap file
> 7. regenerate & validate the gmfgen file
> 8. regenerate the GMF editor
> Now it is still broken.
>
> Regards,
> Rene
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #146573 is a reply to message #146515] |
Wed, 15 August 2007 03:46 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Dawid wrote:
> Hi,
>
> I am having the same kind of problem. Could anybody help us out ?
>
Maybe the GMF build is somehow bad? No updates received for GMF since
20070621
>
> Rene Ladan schrieb:
>> Andrew Montalenti wrote:
>>> Hi everyone,
>>>
>>> I am trying to get the generated GMF diagram editor to share its
>>> TransactionalEditingDomain with my custom views and the EMF editor.
>>>
>> [..snip overrides..]
>>
>>> Now, what ends up happening is the EditingDomain sharing seems to be
>>> working for certain operations. Notably, renames, property changes,
>>> copy/
>>> paste, even drag and drop. All of these operations take effect
>>> without error.
>>>
>>> However, any _pure create_ events -- creating a new Node, or creating
>>> a child of a Node inside a compartment, or creating a connection
>>> among nodes -- in short, anything that utilizes a
>>> CreateElementCommand, and is accessible via the Palette Creation
>>> Tools, causes a huge stack trace.
>>>
>>> The cause of failure is a StackOverflowError.
>>
>> I'm seeing the same kind of error, although my stack trace (attached)
>> doesn't display anything useful at the bottom (maybe the message stack
>> was full?):
>>
>> !SESSION 2007-08-13 10:17:07.067
>> -----------------------------------------------
>> eclipse.buildId=I20070601-1539
>> java.version=1.6.0_01
>> java.vendor=Sun Microsystems Inc.
>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL
>> Framework arguments: -product org.eclipse.sdk.ide -pdelaunch
>> Command-line arguments: -product org.eclipse.sdk.ide -data
>> C:\Documents and Settings\rladan\workspace\mt-test -dev
>> file:C:/Documents and
>> Settings/rladan/workspace/.metadata/.plugins/org.eclipse.pde .core/metatest/dev.properties
>> -pdelaunch -debug C:\Documents and
>> Settings\rladan\workspace\.metadata\.plugins\org.eclipse.pde .core\metatest/.options
>> -os win32 -ws win32 -arch x86
>>
>> <whole bunch of "MESSAGE NLS unused" messages>
>>
>> !ENTRY org.eclipse.ui 4 0 2007-08-13 10:18:13.509
>> !MESSAGE Unhandled event loop exception
>> !STACK 0
>> java.lang.StackOverflowError
>> at
>> org.eclipse.core.runtime.ProgressMonitorWrapper.internalWork ed(ProgressMonitorWrapper.java:94)
>>
>> at
>> org.eclipse.core.runtime.SubProgressMonitor.internalWorked(S ubProgressMonitor.java:155)
>>
>> <ad infinitum>
>>
>>> This is especially puzzling for me because certain operations -- like
>>> a node Copy/Paste operation -- actually create a new element in the
>>> semantic model, and this occurs without error. Only "pure creation"
>>> commands will fail.
>> Here too.
>>
>>>
>>> The following notes may also be helpful:
>>>
>>> 1. although this stack trace occurs, the semantic element is
>>> actually still created, but the notational view for it (the
>>> NodeEditPart in the case of a Node) is not created.
>>>
>> Here too, but if I close and re-open the resource, GMF shows the newly
>> created element.
>>
>>> 2. a knock-on effect is that after this stack overflow occurs, the
>>> diagram editor no longer functions properly. Even if I close all
>>> resources and re-open them, the diagram editor will not allow any
>>> changes to the View -- you can't move a NodeEditPart, change its
>>> color, or anything like that.
>>>
>> Here too, but if I close and re-open the resource, movements work again.
>>
>> [..snip renaming..]
>>
>>
>>> p.s. I'm using GMF 2.0RC1
>>
>> Eclipse 3.3.0 I20070625-1500, EMF 2.3.0v20070626, GEF 3.3.0v20070620,
>> GMF 1.0.100.v20070601, JDK 1.6.0 update 2
>>
>> The strange thing is that it used to work. A working setup seemed to
>> be one before July 10th. After that I _did_ change the models:
>>
>> 1. change & validate the ecore model because of some new requirements
>> 2. update the genmodel file
>> 3. regenerate the EMF editor (ok)
>> Now the GMF editor is broken as described.
>> 4. update & validate the gmfgraph file to match some renamings in the
>> ecore file.
>> 5. check if the gmftool file needs updating (no)
>> 6. update & validate the gmfmap file
>> 7. regenerate & validate the gmfgen file
>> 8. regenerate the GMF editor
>> Now it is still broken.
>>
>> Regards,
>> Rene
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #147313 is a reply to message #146573] |
Tue, 21 August 2007 11:59 |
| Eclipse User |
|
|
|
Hi Rene,
On Wed, 15 Aug 2007 09:46:55 +0200, Rene Ladan wrote:
>>> I'm seeing the same kind of error, although my stack trace (attached)
>>> doesn't display anything useful at the bottom (maybe the message stack
>>> was full?):
Based on your e-mails, our behavior is the same. You mentioned that you
don't see any additional information in the stack trace. Neither did I
at first, except I did when I set break points somewhere near where the
error occurs in the Eclipse debugger. For some reason, just setting the
breakpoints altered the amount of detail in the stack trace output.
(Perhaps the debugger tries to anticipate Stack Overflows and dumps the
stack earlier...?)
I'm not sure what's going on, but it seems we could use some help.
For now I've tabled the Editing Domain sharing for a future release. You
said you haven't gotten any updates since 6/21. I am using Eclipse
3.3RC1, which I believe was an early June release. Now that 3.3 is
stable, for my next release I may consider upgrading and revisiting this
issue to see if it has magically gone away.
Has anyone found a relevant bug report for this? I'd love to nail this
issue down with a solution, or at least an adequate description of the
problem.
Regards,
Andrew
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #147320 is a reply to message #146573] |
Tue, 21 August 2007 11:59 |
| Eclipse User |
|
|
|
Hi Rene,
On Wed, 15 Aug 2007 09:46:55 +0200, Rene Ladan wrote:
>>> I'm seeing the same kind of error, although my stack trace (attached)
>>> doesn't display anything useful at the bottom (maybe the message stack
>>> was full?):
Based on your e-mails, our behavior is the same. You mentioned that you
don't see any additional information in the stack trace. Neither did I
at first, except I did when I set break points somewhere near where the
error occurs in the Eclipse debugger. For some reason, just setting the
breakpoints altered the amount of detail in the stack trace output.
(Perhaps the debugger tries to anticipate Stack Overflows and dumps the
stack earlier...?)
I'm not sure what's going on, but it seems we could use some help.
For now I've tabled the Editing Domain sharing for a future release. You
said you haven't gotten any updates since 6/21. I am using Eclipse
3.3RC1, which I believe was an early June release. Now that 3.3 is
stable, for my next release I may consider upgrading and revisiting this
issue to see if it has magically gone away.
Has anyone found a relevant bug report for this? I'd love to nail this
issue down with a solution, or at least an adequate description of the
problem.
Regards,
Andrew
|
|
|
| Re: StackOverflowError with shared EditingDomain [message #152256 is a reply to message #146573] |
Wed, 26 September 2007 10:39 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Rene Ladan wrote:
> Dawid wrote:
>> Hi,
>>
>> I am having the same kind of problem. Could anybody help us out ?
>>
> Maybe the GMF build is somehow bad? No updates received for GMF since
> 20070621
>
>>
>> Rene Ladan schrieb:
>>> Andrew Montalenti wrote:
>>>> Hi everyone,
>>>>
>>>> I am trying to get the generated GMF diagram editor to share its
>>>> TransactionalEditingDomain with my custom views and the EMF editor.
>>>>
>>> [..snip overrides..]
>>>
>>>> Now, what ends up happening is the EditingDomain sharing seems to be
>>>> working for certain operations. Notably, renames, property changes,
>>>> copy/
>>>> paste, even drag and drop. All of these operations take effect
>>>> without error.
>>>>
>>>> However, any _pure create_ events -- creating a new Node, or
>>>> creating a child of a Node inside a compartment, or creating a
>>>> connection among nodes -- in short, anything that utilizes a
>>>> CreateElementCommand, and is accessible via the Palette Creation
>>>> Tools, causes a huge stack trace.
>>>>
>>>> The cause of failure is a StackOverflowError.
>>>
>>> I'm seeing the same kind of error, although my stack trace (attached)
>>> doesn't display anything useful at the bottom (maybe the message
>>> stack was full?):
>>>
>>> !SESSION 2007-08-13 10:17:07.067
>>> -----------------------------------------------
>>> eclipse.buildId=I20070601-1539
>>> java.version=1.6.0_01
>>> java.vendor=Sun Microsystems Inc.
>>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL
>>> Framework arguments: -product org.eclipse.sdk.ide -pdelaunch
>>> Command-line arguments: -product org.eclipse.sdk.ide -data
>>> C:\Documents and Settings\rladan\workspace\mt-test -dev
>>> file:C:/Documents and
>>> Settings/rladan/workspace/.metadata/.plugins/org.eclipse.pde .core/metatest/dev.properties
>>> -pdelaunch -debug C:\Documents and
>>> Settings\rladan\workspace\.metadata\.plugins\org.eclipse.pde .core\metatest/.options
>>> -os win32 -ws win32 -arch x86
>>>
>>> <whole bunch of "MESSAGE NLS unused" messages>
>>>
>>> !ENTRY org.eclipse.ui 4 0 2007-08-13 10:18:13.509
>>> !MESSAGE Unhandled event loop exception
>>> !STACK 0
>>> java.lang.StackOverflowError
>>> at
>>> org.eclipse.core.runtime.ProgressMonitorWrapper.internalWork ed(ProgressMonitorWrapper.java:94)
>>>
>>> at
>>> org.eclipse.core.runtime.SubProgressMonitor.internalWorked(S ubProgressMonitor.java:155)
>>>
>>> <ad infinitum>
>>>
>>>> This is especially puzzling for me because certain operations --
>>>> like a node Copy/Paste operation -- actually create a new element in
>>>> the semantic model, and this occurs without error. Only "pure
>>>> creation" commands will fail.
>>> Here too.
>>>
>>>>
>>>> The following notes may also be helpful:
>>>>
>>>> 1. although this stack trace occurs, the semantic element is
>>>> actually still created, but the notational view for it (the
>>>> NodeEditPart in the case of a Node) is not created.
>>>>
>>> Here too, but if I close and re-open the resource, GMF shows the
>>> newly created element.
>>>
>>>> 2. a knock-on effect is that after this stack overflow occurs,
>>>> the diagram editor no longer functions properly. Even if I close
>>>> all resources and re-open them, the diagram editor will not allow
>>>> any changes to the View -- you can't move a NodeEditPart, change its
>>>> color, or anything like that.
>>>>
>>> Here too, but if I close and re-open the resource, movements work again.
>>>
>>> [..snip renaming..]
>>>
I did a fresh installation of Eclipse in a new directory to see if the above
problems disappeared, but they didn't :(. Versions :
* Eclipse 3.4 Integration 20070921919
* EMF 2.3.1 20070925
* OCL 2.0.* 20070921
* GEF 3.4.0 20070919
* GMF SDK 2.0 20070903 (Integration)
* Apache Batik 1.6.0 200706111724
I created a new test project (the coffee tutorial from OnJava.com) which
actually works fine. Steps:
1. Create a new GMF project
2a. Import the ecore, gmfmap, gmftool, gmfgraph files
2b. Set the nsURI/nsPrefix fiels in the ecore file
2c. Migrate the gmfgraph and gmfmap files to GMF 2.0
3. Generate the genmodel, gmfgen files using the defaults
4. Generate the code
So maybe the stack problems are gmf-model related? In both cases all models
validate fine.
>>>
>>>> p.s. I'm using GMF 2.0RC1
>>>
>>> Eclipse 3.3.0 I20070625-1500, EMF 2.3.0v20070626, GEF 3.3.0v20070620,
>>> GMF 1.0.100.v20070601, JDK 1.6.0 update 2
>>>
>>> The strange thing is that it used to work. A working setup seemed to
>>> be one before July 10th. After that I _did_ change the models:
>>>
>>> 1. change & validate the ecore model because of some new requirements
>>> 2. update the genmodel file
>>> 3. regenerate the EMF editor (ok)
>>> Now the GMF editor is broken as described.
>>> 4. update & validate the gmfgraph file to match some renamings in the
>>> ecore file.
>>> 5. check if the gmftool file needs updating (no)
>>> 6. update & validate the gmfmap file
>>> 7. regenerate & validate the gmfgen file
>>> 8. regenerate the GMF editor
>>> Now it is still broken.
>>>
>>> Regards,
>>> Rene
|
|
| |
| Re: StackOverflowError with shared EditingDomain [message #159613 is a reply to message #153843] |
Mon, 12 November 2007 06:36 |
| Eclipse User |
|
|
|
Originally posted by: trommas.yahoo.com
This solved the issue for me, but a new came up:
I can only create model elements in diagram 1, not in diagram 2.
Any ideas?
Best Regards,
Tomas Zijdemans
Nicolai Kamenzky wrote:
> Hi Rene, Dawid, Andrew!
>
> Is your problem still unsolved?
>
> Try this:
> In step 8 of:
> < http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomai n_instan
> ce_across_several_diagrams>
>
> you altered ???DocumentProvider.createEditingDomain().
>
> The id "org.eclipse.gmf.ecore.editor.EditingDomain" is used
> toindicate your EditingDomain.
>
> Please replace both occurences in the altered code with your
> actual id of your EditingDomain which you set in step 6.
> (Which would be "SharedEditingDomain".) Do this for every editor.
>
> Does the StackOverflowError still occur? If not, do your editors
> now work properly while sharing their EditingDomain?
>
> Cheers,
> Nicolai
>
>
|
|
|
Goto Forum:
Current Time: Fri Jul 18 02:00:23 EDT 2025
Powered by FUDForum. Page generated in 0.04621 seconds |
Home