Thomas Harning Jr. wrote: > Thomas Harning Jr. wrote: > ... > >>>I've found that calling .Ref() on the Pixbuf will save it, andso >>>will adding that pixbuf to an arraylist to preserve a reference >>>to it. >>>* This is a HORRIBLE kludge and I'm not even sure if it fixes it >>>permanently (it stops the NRE in the short-run). > > ... > > I think I may have found the culprit... I had a thread that was > setting values in the Treestore that called upon the TreeView to > update through the ThreadNotify method... thinking that the > TreeStore wasn't 'quite' GUI-enough to need thread-protection. But > it seems that way. > I removed all reference preservation and the .Ref() from the Pixbuf > as well as columns and such... and there are no more crashes. > I'll keep my eye open for this occurring in the future, however.
Well the virtually untraceable error has come back. I got GDB to trace it... and the highest point on the stack is g_timeout_funcs in libglib-2.0.so.0 [there are 4 more stack elements above it, but they won't resolve w/ mono via mono_print_method_from_ip.] I've tried to run mono --debug with GDB.... and the application runs fine. Strangely.. without GDB, mono --debug almost instantly crashes out w/ NRE. The thing I added which seems to have retriggered the NRE problems is using a single-column TreeStore and using callbacks to get the value for the other columns by referencing the object inside the TreeStore. The callbacks are preserved in instance variables so they don't get collected (which is apparently an issue in passing callbacks to GTK#). -- Thomas Harning Jr.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
