Re: crash

At 02:35 PM 3/5/00 -0800, Kyle Jones wrote: Right, but I don't see how this can be achieved realistically. Every time you instantiate an image instance (and redisplay does this a lot) there is a chance that you will call lisp code. This works because GC does nothing and the specifier code spec-binds inhibit-quit. The flip side is that calling lisp should be a transient phenomenom since instances will very quickly get cached. The gutter is exactly the same as most image types. The difference is that it incorporates gui-item code that menubars use and these have eval-able slots that can call lisp when they get checked. Up until now I thought it was therefore safe to put the gutter updates outside the critical redisplay section (where menubar updates go). However, it is clear that the redisplay code itself *assumes* that GC will not happen and therefore doesn't bother to GCPRO anything. The gutter code breaks this by being outside of the critical redisplay section. The gutter sizing code breaks this by being called from Fmake_frame. So IMHO the fix is right for what we currently have, furthermore any slowdown due to lisp evaluation is only transient since images etc will be cached after the first access. I don't believe this is currently the case, but I'm prepared to be proved wrong. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd