Hi Have been wrestling with the frequent GC segfaults on Windows. Seems they occur b/c Windows sends Events (UpdateUIEvents, I think) with the same pointer repeatedly. These get wrapped in a ruby Event object as they are processed, and a mapping stored through SWIG''s trackobjects. However, the ruby object isn''t referenced anywhere, so gets swept and destroyed by GC when it runs. For some reason, the mapping isn''t removed, so the next time the same Event object is sent for processing (ProcessEvent), SWIG tries to retrieve a destroyed object, and segfaults. I can''t pin down where the tracking should be getting removed but isn''t, but switching off trackobjects altogether for wxEvent seems to avoid the problem (using VS express 2005) I don''t *think* this is a problem, because I don''t think Event objects are ever returned by wxruby methods; they are only ever passed into ruby from C++ API (in normal event handlers), or occasionally passed into C++ from Ruby (if ''faking'' events). So I''d be grateful if you could try the attached patch and see 1) does this fix the issue? 2) is it going to cause other problems down the line? thanks alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Event_i.patch Url: http://rubyforge.org/pipermail/wxruby-development/attachments/20070123/b79ba476/attachment.ksh
Alex Fenton wrote:> Hi > > Have been wrestling with the frequent GC segfaults on Windows.<snip>> > So I''d be grateful if you could try the attached patch and see > 1) does this fix the issue? > 2) is it going to cause other problems down the line?Hi Alex. This patch doesn''t seem to completely address all crash issues. The sample I use for showing the crashing is the Gauge sample in bigdemo. The sample actually runs for a while now -if- you don''t move the mouse cursor out of the gauge pane. As soon as you do, it crashes. One time it just hung the application and didn''t crash, so I had to kill it. So, it may have some other side effects that need to be investigated. I haven''t specifically tested using GC with the samples I made before so I can''t say if it addressed those. I thought you''d appreciate a little feedback on it. Roy
Hi Roy Thanks for the feedback, it''s appreciated.>> 1) does this fix the issue? >> 2) is it going to cause other problems down the line? >> > This patch doesn''t seem to completely address all crash > issues. The sample I use for showing the crashing is the Gauge sample > in bigdemo. The sample actually runs for a while now -if- you don''t > move the mouse cursor out of the gauge pane. As soon as you do, it > crashes.I followed this up, and I think it''s an unrelated crasher. Could you let me know if the crash happens when you move the cursor out of the pane and over the splitter, so that the resize cursor would be shown. From the backtrace what I think is happening is that C++ splitter window stores references to the resize cursors which are shown on hover. There are no ruby refs to these objects so they get destroyed by GC. When they are next displayed it triggers the crash. At the moment not quite sure how to fix this one. If we can think something up I''d like to put out a release. We''ve got quite a few incremental bugfixes and features that users would probably appreciate. What do you all think? cheers alex