From: Robert Klemme <shortcutter@...>
Date: 2006-07-07T01:17:21+09:00
Subject: Re: [BUG] thread/sync.rb memory corruption

------=_Part_40431_17060414.1152202634357
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2006/7/6, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov>:
> On Thu, 6 Jul 2006, Robert Klemme wrote:
>
> > Yes, but they are still queued up against the mutex.  I completely agree
> > with Tom's analysis.  Having an Observer trigger the notification again is
> > definitively a bad idea - at least if events are not queued up.
>
> ah - but they are indeed queued - this is precisely what sync.rb is supposed
> to do.  you can prove this for yourself by adding

With queued I meant something different in this case, i.e. have a
single event queue in the obervable that is processed by a single
thread only.

>    p 'Thread.list.size' => Thread.list.size
>
> in the notify method.  if you do so you'll see something like
>
>    on @ 1152201072.40667
>    {"Thread.list.size"=>1}
>    off @ 1152201072.41042
>    {"Thread.list.size"=>2}
>    on @ 1152201072.41508
>    {"Thread.list.size"=>3}
>    off @ 1152201072.4219
>    {"Thread.list.size"=>3}
>    on @ 1152201072.43386
>    {"Thread.list.size"=>2}
>    off @ 1152201072.44186
>    {"Thread.list.size"=>3}
>    on @ 1152201072.46079
>    {"Thread.list.size"=>2}

Well, yes. Still I think that the design is flawed because there is a
recursion via threads.  If you have two listeners the # of threads
will constantly grow.  Try it out!  I tried it with these changes
(attached). Probably your version crashes with a single listener
because threads are not as fast GC'ed as on my machine or whatever.

> the number of threads running will never exceed three.  the bug does not seem
> to be directly caused by sync.rb in any case.  here is a more minimal script
> which will produce the error:

Try my changes.  More and more threads queue up at the mutex.

> it will run fine.  if you run with
>
>    CORRUPT=true ruby a.rb
>
> you will trash memory.  if you have ef and do
>
>    CORRUPT=true ef ruby a.rb
>
> electric fence will core dump almost immediately.

Btw, it does not crash on cygwin - neither way. :-)

> note that the only difference between crashing and not is calling notify with
> and argument - when that occurs the number of threads will remain steady, but
> the GC will stop collecting finished threads even though no reference to them
> is held.

Weird indeed.

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/

------=_Part_40431_17060414.1152202634357
Content-Type: application/x-ruby; name=cr.rb
Content-Transfer-Encoding: base64
X-Attachment-Id: f_epbbn679
Content-Disposition: attachment; filename="cr.rb"

IyEgL3Vzci9iaW4vcnVieQoKcmVxdWlyZSAnc3luYycKCmNsYXNzIEEKCiAgZGVmIGluaXRpYWxp
emUKICAgIGV4dGVuZCBTeW5jX20KICAgIEBvYnNlcnZlcnMgPSBbXQogIGVuZAoKICBkZWYgbWV0
aAogICAgc3luY2hyb25pemUoOkVYKXsKICAgICAgcCBUaHJlYWQubGlzdC5zaXplCgogICAgICBA
b2JzZXJ2ZXJzLmVhY2ggZG8gfG98CiAgICAgICAgaWYgRU5WWydDT1JSVVBUJ10KICAgICAgICAg
IG8ubm90aWZ5IG5pbAogICAgICAgIGVsc2UKICAgICAgICAgIG8ubm90aWZ5CiAgICAgICAgZW5k
CiAgICAgIGVuZAogICAgfQogIGVuZAoKICBkZWYgYWRkX29ic2VydmVyIG8KICAgIHN5bmNocm9u
aXplKDpFWCl7CiAgICAgIEBvYnNlcnZlcnMgPDwgbwogICAgfQogIGVuZAplbmQKCmNsYXNzIEIK
ICBkZWYgaW5pdGlhbGl6ZSBhCiAgICBAYSA9IGEKICAgIEBhLmFkZF9vYnNlcnZlciBzZWxmCiAg
ZW5kCgogIGRlZiBub3RpZnkgKmEKICAgIFRocmVhZC5uZXd7IEBhLm1ldGggfQogIGVuZAplbmQK
CmEgPSBBLm5ldwpiID0gQi5uZXcgYQpjID0gQi5uZXcgYQphLm1ldGgKU1RESU4uZ2V0cwo=
------=_Part_40431_17060414.1152202634357--