On Thu, 2006-02-09 at 13:52 +0100, Mark Wielaard wrote: > Hi, > > After a lot of debugging I finally found out why a program I was testing > was crashing sometimes. (The hsqldb AWT frontend - try the > org.hsqldb.util.DatabaseManager class from the hsqldb.jar as distributed > with OpenOffice for example.) A GtkGraphics object is created > differently for realized and un-realized components. When we get a paint > event for an unrealized component and try to use the associated > GdkGraphics object bad things happen (because NSA_GET_G_PTR returns null > in such cases). > > The attached hack makes things work for now by just ignoring such paint > events for such objects. It gives: > > NOT handling java.awt.event.PaintEvent[UPDATE,updateRect=java.awt.Rectangle[x=0,y=0,width=360,height=300]] on org.hsqldb.util.Grid[panel0,0,0,360x300,invalid,parent=panel1] for UNREALIZED org.hsqldb.util.Grid[panel0,0,0,360x300,invalid,parent=panel1] > > I like to debug this a bit further, but I couldn't find good > documentation on the handling of (un)realized GtkComponentPeers. Does > anybody have a link or an explanation of whether or not the above should > ever happen? Yes it can happen especially in multi-threaded applications. You're probably right to just ignore the paint event. It'd be useful to know if hsqldb makes calls into the peers from different threads. For example if it shows a window in one thread and another thread handles painting on that window. An unrealized GtkComponentPeer is a GtkWidget that has an uninitialized X window field. In other words, the X server doesn't have a window data structure allocated for it. We used to force-realize every GtkComponentPeer on construction but that lead to strange behaviour when adding a hierarchy of components to an already-shown container (all components would be shown first at 0,0-1x1 then layed out after that). Delayed realization makes the peer code much more complicated, and adding a container to an already-shown container is rare so I'm thinking it may be acceptable to switch the code back to force-realization-on-creation. It would simplify GtkComponentPeer GdkGraphics and would probably eliminate these situations that you're describing. Tom
