octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weird behavior with mislocked: oct-file is unloaded while checking l


From: John W. Eaton
Subject: Re: Weird behavior with mislocked: oct-file is unloaded while checking lock state...
Date: Thu, 04 Sep 2008 10:16:23 -0400

On  4-Sep-2008, Michael Goffioul wrote:

| On Wed, Sep 3, 2008 at 5:23 PM, John W. Eaton <address@hidden> wrote:
| > The function shouldn't be invalidated unless the time stamp changes or
| > it is no longer visible.  Does the following change fix that problem?
| > I'm still not sure this is completely the correct thing to do, but I
| > think it will avoid the problem you are seeing.
| 
| This does not help (Note: after backend('fltk') call, __init_fltk__ is now
| correctly locked). When I trace code execution on
| 
|   backend('fltk')
|   mislocked('__init_fltk__')
| 
| I can see that on the "backend" call, fltk_backend.oct is mapped into
| memory. Then on "mislocked" call, I see that it is unmapped then
| remapped. If the new mapping occurs at the same address, everything
| is OK. If not, I get a crash when readline tries to execute the event hook
| on the next prompt (indeed, the function pointer stored in readline is
| obviously wrong).
| 
| I'm willing to help debug it, but I don't know what to look for.

The mislocked function calls symbol_table::find_function, which should
eventually call symbol_table::fcn_info::fcn_info_rep::find.  Can you
step through that function (and the functions it calls) and find out
where it is that fltk_backend.oct is unmapped?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]