Re: $2000 USD Reward for help fixing Segmentation Fault in GC

Hi Brent,

Although i can not anticipate the code structure, still suggesting... please
ignore if you have already tried that out!

using WekRef library, a lots of memory management problems can be solved...
i have implemented it in various cases and that worked out well.

like if u have a large object say a 5 MB file assigned to a variable

like file = File.open("myfile", "r")
.... all processing with file ......
GC.start #  withing the same process

then this time running GC.start will not swipe off the "file" object from
the memory as its reference still exists as "file"

by doing it like

require 'weakref'
file = WeakRef.new(File.open("myfile", "r"))
.... all processing with file ......
GC.start

this time the variable "file" will be swiped off, no matter whether the
reference exists or not!


so, what all i mean... that wherever you know the variable is assigned as
too big values that will not be useful after the current function....
you can make those variables as WeakRef object and can call GC.start at the
end of each function... thereby keeping the memory free.

like a string object can assigned as

str = WeakRef.new("my string")

so str will perform all the functions of String object... but remember one
thing it will be an object of WeakRef class, so you can not rely on anything
like str.class in your code... I mean, with WeakRef you will strongly need
to focus on DuckTyping.

thanks.

--
SurMax
http://expressica.com


On 5/31/07, Brent Roman <[e-mail]> wrote:
>
>
> Help!
>
> Our Ruby controlled Robotic Marine Laboratory started failing
> with Segmentation Faults just a few days before it was to be
> deployed.  We had seen random, very occasional Segmentation
> Faults for some months, as our application grew larger
> and more complex.  Then, just days before the ship
> was scheduled to sail, after we'd integrated a couple new and
> exciting features, we started getting segfaults regularly.
>
> Please see [ruby-core:11218] & [ruby-core:11228] for more details
> including URLs to a core dump and stack trace.
>
> The 200+ level stack trace indicates that the application was deep
> into a GC cycle while executing Marshal.dump when the segfault
> occurred.
>
>
> Here are the details on the reward:
>
>   The Monterey Bay Aquarium Research Institute (http://www.mbari.org)
> is offering $2000 USD to the first person to provide a software
> fix to the bug causing the above described Segmentation Faults
> in our application.  Our application is arguably one of the cooler,
> more unusual uses of Ruby:
>
> http://www.mbari.org/microbial/ESP/
> http://www.zenspider.com/dl/rubyconf2005/EmbeddedRuby.pdf
>
> I will provide support to individuals who offer plausible
> suggestions.  E-mail suggested fixes or queries for specific
> information to me directly if you do
> not wish to share them with the list.  Whatever fix finally
> is determined to work will be shared with the list, after
> the individual providing it is paid, so that the community
> may also benefit.
>
> The fine print:
>
> Funds will be paid by corporate cheque in U.S. Dollars after
> the bug fix is verified to work.  Verification may take up to 45 days
> from the submission of the prospective fix.  Only the first working
> bug fix submitted by email to [e-mail] will be rewarded.
>
> Individuals obligated to pay U.S. taxes on their income will
> be sent an IRS form 1099 from MBARI at year's end.
> If you are a United States citizen or have a "green card", you will
> need to send MBARI your mailing address and
> U.S. Social Security Number before receiving
> payment and should expect to pay income tax on the reward.
> Individuals not obligated to pay U.S. income tax will have the
> option to receive payment via bank wire rather than cheque.
>
> I will post to this list, roughly on a weekly basis, the number of
> plausible, prospective fixes we have received thus far.
> After we've received ten or so from different individuals, we will
> cease accepting any more.
>
> --
> Brent Roman                                   MBARI
> Software Engineer               Tel: [phone]
> 7700 Sandholdt Road,         Moss Landing, CA 95039
> mailto:[e-mail]  http://www.mbari.org/~brent
>
>
>


-- 
sur