Re: [rvm-research] Potential issues with longjmp in bootImageRunner

Hi,

> [...]
> thanks for the bug report. This seems to be the same problem that
> Kathiravelu Pradeeban mentioned a few days ago.

Ah, I hadn't picked up on that.

> On my Ubuntu 12.10 x64 machine, using "ulimit -s unlimited" does not
> seem to cause the problem (I already had it set to unlimited) but I was
> able to reproduce the problem using "setarch x86_64 -L".

Interesting.

> Moreover, it seems that the problem is related to another problem with
> longjmp that I have on a PPC-32 machine: applying your patch also fixes
> that problem. For the PPC problem, I don't get a backtrace at all and
> the crash happens in sysThreadTerminate(). Interestingly, the PPC
> problem disappears when compiling the bootimage runner without
> optimizations (i.e. -O0 instead of -O in the appropriate file in
> build/hosts). Is that also the case for the problem on your machine?

I'm not sure why that would make a difference, but I will test to find out.

>> There are a number of approaches to dealing with this:
>>  1. assume allocation will always be top-down and ignore,
>>  2. explicitly allocate thread stacks (these can be passed to pthread_create),
>>  3. replace use of setjmp/longjmp with savecontext/swapcontext
>> (although these are deprecated in POSIX),
>>  4. implement a local version of longjmp without a check,
>>  5. bypass the __longjmp_chk by using glibc's internal __libc_longjmp().
>>
>> Disregarding (1), (5) is the smallest change set.
>
> I'd also disregard (1). (3) and (4) don't seem attractive to me; we
> ought to rely on non-deprecated methods from the system libraries as
> much as possible.

My opinion is (3) the best option as (2) requires the bootImageRunner
to allocate memory at a specific place in memory and manage it
(because thread heap will need to be freed).  Instead of
reimplementing setjmp/longjmp completely, bootThread already has to be
implemented in machine specific assembly to pivot the stack when
entering the VM, the existing code should hence be extended to allow
for pivoting back onto the thread stack.  In effect bootThread should
return when sysThreadTerminate is called.

I'll put together a patch that implements the above in the next couple
of days for further comment.

> If there's a way to fix our code without having to resort to using
> internal (i.e. non-api) functions, I'd prefer that way, even if it's a
> larger diff and/or more risky change. The code in sys.C hasn't seen any
> real changes for quite some time and is in need of refactoring anyway.
> (There are some refactorings in the code of the Metacircular Research
> Platform but we haven't gotten around to pulling them yet.)

Yes, the bootImageRunner code looks like it could use some
refactoring.  The work done by the Metacircular Research Platform is
fairly extensive, although not in appropriate.

> That said, my C is really rusty so I probably won't be providing related
> patches in the near future.

I may provide a few, although my opinion is not to refactor unless
there are specific bugs that it would fix.

Cheers,

Carl

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter