Function lock and octave call stack (Was: seg-fault for default branch on Mac OSX?)

[John W. Eaton]

On  1-Sep-2008, Michael Goffioul wrote:

| On Mon, Sep 1, 2008 at 9:04 AM, Michael Goffioul
| <michael.goffioul at gmail.com> wrote:
| > Most probably due to a missing lock in FLTK backend
| > code. Can you try if adding "mlock()" in __init_fltk__
| > code in fltk_backend.cc does fix the problem? If yes,
| > I'll propose a complete patch later today.
| 
| I was looking at solving that problem, but I found something
| weird and I'm not sure how I'm supposed to tackle this.
| 
| I tried to add "mlock()" call in __init_fltk__ (in fltk_backend.cc),
| but I still got a crash. When debugging, I noticed that the lock
| was actually placed on "feval", instead of "__init_fltk__" (indeed,
| __init_fltk__ is called through feval).
| 
| More precisely, in octave_call_stack::do_caller(), the call stack is
| the following (when executing "backend('fltk')"):
| cs[0] : NULL
| cs[1] : backend
| cs[2] : feval
| cs[4] : __init_fltk__
| 
| curr_frame is 3, which means that do_caller() returns the "feval"
| frame. So "feval" is locked, while I wanted to lock __init_fltk__.
| The code for the latter looks like:
| 
| DEFUN (__init_fltk__, ...)
| {
|   if (...)
|   {
|     mlock ();
|   }
| }

The idea was that mlock would only be used inside Fmlock, so we should
get the caller (i.e., the .m file that called Fmlock), not the current
function (Fmlock).

Maybe we should define a separate internal function (or allow an
argument to the current mlock function) to allow locking the current
function on the call stack.

jwe