Attempt to access destroyed widget in the DOM - destroy() called at invalid time

[DSingh]

Using version /builds/SmartGWT/2.5p/PowerEdition/2013-02-27

Can you give some input on below error?

[ERROR] [gwt] - 11:46:15.352:MUP6[E]:WARN:ImgSectionHeader:isc_ImgSectionHeader_8:Attempt to access destroyed widget in the DOM - destroy() called at invalid time (eg: mid-draw) or invalid method called on destroy()d widget. Stack Trace:
[a]MathFunction.getStackTrace(_1=>undef, _2=>undef, _3=>undef, _4=>undef, _5=>undef)
Canvas.getHandle()
Canvas.$ux(_1=>"parentDrawn")
Canvas.$ut(_1=>"parentDrawn")
Canvas.adjustOverflow(_1=>"parentDrawn", _2=>undef, _3=>undef)
Canvas.$qx(_1=>Array[8])
Layout.layoutChildren(_1=>"membersAdded", _2=>undef, _3=>undef)
Layout.reflowNow(_1=>"membersAdded", _2=>2)
anonymous()
[c]EventHandler.runTeas()
[c]EventHandler.$h2()
[c]EventHandler.dispatch(_1=>[c]EventHandler.handleMouseUp(), _2=>[object MouseEvent])
anonymous(event=>[object MouseEvent])

Thanks,
Deepak Singh

[Isomorphic]

The error implies that something in your application is causing an attempt to get at the handle (the DOM element) for a widget that has been destroy()'d.
As the error message implies, this can be caused by a call to destroy() being made from the middle of something like a draw() handler.

Are you explicitly destroy()'ing a SectionStack in your app? If so, experiment with that code flow.
If not, this could be being triggered by something like changing the set of sections displayed in the stack such that one of the section headers gets discarded (and automatically destroy()'d) -- take a look at any logic you have to modify the set of sections displayed and experiment with the code flow there.

Once you have an idea what's actually causing the problem in your app, you may find you have a logic bug at the application level that you can resolve yourselves. If not, and you think you've hit a framework bug, you will probably be able to put together a simple test case that demonstrates the problem. A reproducible case like this will allow us to try the issue out on our end and we can advise you further at this point, or provide a patch if it is indeed something we should resolve at the framework level.

Regards
Isomorphic Software