I believe I''ve run afoul of a timing issue in wxruby that might explain some peoples'' segfaults. I have a radio button page as part of a notebook that selects a file to read in, which triggers a whole lot of other changes, including a rebuild of one of the other notebook pages. If I''m slow and deliberate (like 2+ seconds between clicks) it all works fine. However, if I click faster, I WILL get a segfault. Since my printed puts statements are all executing, my processing is being completed. Unfortunately, it appears that there is still background processing occurring at either the wxruby or wxW level that is not protected against such occurrences. How can I test for this and either defer the click processing or veto it? -- -- Don Wilde ph: 512-394-8896 skype: donwilde1 e: dwilde1@gmail.com "If you are creative and add value to the world, sleep well. You''ve earned it." _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
On 08.02.2011 22:10, Don Wilde wrote:> How can I test for this and either defer the click processing or veto it?I think the main problem is that the integration with the garbage collector is buggy and if enough stuff happens between when your object becomes garbage and when it is actually collected some data structures become corrupted. For example, I can completely avoid the segfaults in http://rubyforge.org/tracker/index.php?func=detail&aid=28871&group_id=35&atid=218 by immediately calling GC.start() after destroying the temporary windows, and the probability of a segfault goes down if I decrease the timer interval so it runs more often so more stuff gets allocated and the collector runs more often. - Florian.
On Wed, Feb 9, 2011 at 12:22 AM, Florian Hars <hars at pre-sense.de> wrote:> On 08.02.2011 22:10, Don Wilde wrote: > > How can I test for this and either defer the click processing or veto it? > > I think the main problem is that the integration with the garbage > collector is buggy and if enough stuff happens between when your object > becomes garbage and when it is actually collected some data structures > become corrupted. For example, I can completely avoid the segfaults in > > http://rubyforge.org/tracker/index.php?func=detail&aid=28871&group_id=35&atid=218 > by immediately calling GC.start() after destroying the temporary > windows, and the probability of a segfault goes down if I decrease the > timer interval so it runs more often so more stuff gets allocated and > the collector runs more often. > > That does make a scary kind of sense. I reconstitute an entire tab bookpage with hundreds of elements on it, and of course the old elements become garbage. if this is known-buggy, and nobody knows a better way to identify completion of the cleanup, I''ll have to rig another timer to defer the new operations for a few seconds. I''ll add the explicit call like you suggest, too, Florian. Thanks for the understanding and tips. -- -- Don Wilde ph: 512-394-8896 skype: donwilde1 e: dwilde1 at gmail.com "If you are creative and add value to the world, sleep well. You''ve earned it." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20110209/5bf2faa2/attachment-0001.html>
On Wed, Feb 9, 2011 at 9:24 AM, Don Wilde <dwilde1 at gmail.com> wrote:> > > On Wed, Feb 9, 2011 at 12:22 AM, Florian Hars <hars at pre-sense.de> wrote: > >> On 08.02.2011 22:10, Don Wilde wrote: >> >[snip]> by immediately calling GC.start() after destroying the temporary >> windows, and the probability of a segfault goes down if I decrease the >> timer interval so it runs more often so more stuff gets allocated and >> the collector runs more often. >> >> That does make a scary kind of sense. I reconstitute an entire tab book > page with hundreds of elements on it, and of course the old elements become > garbage. > > if this is known-buggy, and nobody knows a better way to identify > completion of the cleanup, I''ll have to rig another timer to defer the new > operations for a few seconds. > > I''ll add the explicit call like you suggest, too, Florian. Thanks for the > understanding and tips. > >Florian, the explixcit GC call was indeed all I needed. Many thanks! :D -- -- Don Wilde ph: 512-394-8896 skype: donwilde1 e: dwilde1 at gmail.com "If you are creative and add value to the world, sleep well. You''ve earned it." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20110209/120fd907/attachment.html>