headers
Nikodemus Siivola | 1 Apr 2007 03:09
Gravatar

Mach exception handling thread

Snipped from signal_emulation_wrapper:

     context = (struct ucontext*) os_validate(0, sizeof(struct ucontext));
     regs = (struct mcontext*) os_validate(0, sizeof(struct mcontext));
     context->uc_mcontext = regs;

     /* when BSD signals are fired, they mask they signals in sa_mask
        which always seem to be the blockable_sigset, for us, so we
        need to:
        1) save the current sigmask
        2) block blockable signals
        3) call the signal handler
        4) restore the sigmask */

     build_fake_signal_context(context, thread_state, float_state);

     block_blockable_signals();

     handler(signal, siginfo, context);

     update_thread_state_from_context(thread_state, float_state, context);

     os_invalidate((os_vm_address_t)context, sizeof(struct ucontext));
     os_invalidate((os_vm_address_t)regs, sizeof(struct mcontext));

     /* Trap to restore the signal context. */
     asm volatile ("movl %0, %%eax; movl %1, %%ebx; .long 0xffff0b0f"
                   : : "r" (thread_state), "r" (float_state));

The handler function may unwind, in which case we leak memory every
(Continue reading)

Permalink | Reply | 3 comments |
headers
Cyrus Harmon | 1 Apr 2007 07:18

Re: Mach exception handling thread

No, I wasn't aware of this leak and that sounds right. But see the  
comment right before this block:

     /* CLH: FIXME **NOTE: HACK ALERT!** Ideally, we would allocate
      * context and regs on the stack as local variables, but this
      * causes problems for the lisp debugger. When it walks the stack
      * for a back trace, it sees the 1) address of the local variable
      * on the stack and thinks that is a frame pointer to a lisp
      * frame, and, 2) the address of the sap that we alloc'ed in
      * dynamic space and thinks that is a return address, so it,
      * heuristicly (and wrongly), chooses that this should be
      * interpreted as a lisp frame instead of as a C frame.
      * We can work around this in this case by os_validating the
      * context (and regs just for symmetry).
      */

So it sounds like os_validating this instead of putting it on the  
stack, which we do to work around the debugger problem is not just  
expensive, but also leaky. The proper fix is to fix the debugger, I  
think. Alastair looked at this in some detail and is of the opinion  
that there isn't a good fix without some fairly major changes to the  
calling conventions.

The leak is a good argument for putting some more thought into fixing  
this.

Thanks,

Cyrus
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Reid | 1 Apr 2007 15:35
Picon
Gravatar

Patch: safer *break-on-signals*

Currently,

$ sbcl
This is SBCL 1.0.4, ...
* (setf *break-on-signals* 'biff)

BIFF
* (signal "oops")
Control stack guard page temporarily disabled: proceed with caution
Illegal instruction
$

When TYPEP encounters the bogus type specifier, it signals an error,  
at which time *break-on-signals* has not yet been rebound to NIL,  
therefore recursing infinitely.

This patch rebinds *break-on-signals* around the test of it, so that  
the processing of signals resulting from the test does not re-involve  
the bogus value.

Also, the REASSIGN restart is given a description which does not  
mention "Return from BREAK", in this situation.

$ src/runtime/sbcl --core output/sbcl.core
This is SBCL 1.0.4.12, ...
* (setf *break-on-signals* 'biff)

BIFF
* (signal "yay")
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 1 Apr 2007 18:02
Gravatar

Killing off HPPA?

Any objections to cutting the HPPA port from the tree?

It is stale and unmaintained, and trying to reflect eg.
runtime changes there is a waste of time, as I suspect
that if ever someone wants to resurrect it, they are
equally well of with what they can pull from CVS history
as with us trying to somehow keep it up to date.

Cheers,

   -- Nikodemus

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Alastair Bridgewater | 1 Apr 2007 19:58

Re: Mach exception handling thread

Cyrus Harmon writes: 

> No, I wasn't aware of this leak and that sounds right. But see the  
> comment right before this block: 
> 
>      /* CLH: FIXME **NOTE: HACK ALERT!** Ideally, we would allocate
>       * context and regs on the stack as local variables, but this
>       * causes problems for the lisp debugger. When it walks the stack
>       * for a back trace, it sees the 1) address of the local variable
>       * on the stack and thinks that is a frame pointer to a lisp
>       * frame, and, 2) the address of the sap that we alloc'ed in
>       * dynamic space and thinks that is a return address, so it,
>       * heuristicly (and wrongly), chooses that this should be
>       * interpreted as a lisp frame instead of as a C frame.
>       * We can work around this in this case by os_validating the
>       * context (and regs just for symmetry).
>       */ 
> 
> So it sounds like os_validating this instead of putting it on the  
> stack, which we do to work around the debugger problem is not just  
> expensive, but also leaky. The proper fix is to fix the debugger, I  
> think. Alastair looked at this in some detail and is of the opinion  
> that there isn't a good fix without some fairly major changes to the  
> calling conventions.

Right.  The proper fix is to change the calling convention again so that 
lisp and C frames have the same format.  Meanwhile, the best thing might be 
to wedge a UWP in there that frees the memory if an unwind is performed. 

And I could have sworn that at one point I was told that we don't unwind
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lutz Euler | 1 Apr 2007 19:58
Picon
Favicon

[Patch] Re: Shrink package hash tables in the core?

Hi,

I wrote:

> I can think of the following options:
>
> 1. Shrink package hash tables during SAVE-LISP-AND-DIE.
>
> 2. In FINISH-SYMBOLS, count the symbols saved for each package and base
>    the calculation of the sizes of the package hash tables on these
>   counts.
>
> 3. Make UNINTERN check whether the package hash tables get too sparse
>    and rehash them if so.

William Newman answered:

> I think #3 is worth doing whether or #1 and #2 are done. An
> application programmer can reasonably expect an exported
> delete-from-table operation to be implemented efficiently. It also
> looks relatively easy to test #3, which should tend to make it easier
> to set up and maintain.
> 
> #1 and #2 could still be improvements worth doing, but in trying to
> determine how much they improve things, I think the best baseline
> would be relative to #3.

Thanks for the feedback!

I have implemented all three variants and tested their effects
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 1 Apr 2007 20:16
Gravatar

Re: Mach exception handling thread

Alastair Bridgewater wrote:

 > And I could have sworn that at one point I was told that we don't unwind
 > from signal handlers anyway, and jump through hoops to ensure that this
 > is so (of course, this doesn't apply to Win32, where we can, do, and
 > must unwind from exception handlers, and jump through hoops to ensure
 > that it works correctly).

We may currently unwind over C-frames from all lisp side signal
handlers except for those few which we call via a_r_t_l_f. ...what
is more, currently we _must_ unwind from all trap_Errors.

Cheers,

  -- Nikodemus

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
David | 2 Apr 2007 02:15
Picon
Favicon

found circular reading bug

Hi,

I'm using SBCL 1.0.2 and think I found a bug in the reader.  The 
following code returns NIL.  I believe it should return T.

(let ((foo (cons #1=(cons nil nil) #1#)))
       (eq (car foo) (cdr foo)))

Can someone confirm this?

Thanks,
David

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 3 comments |
headers
Brian Mastenbrook | 2 Apr 2007 02:39

Re: found circular reading bug

On 4/1/07 7:15 PM, "David" <rsucfeq02 <at> sneakemail.com> wrote:

> Hi,
> 
> I'm using SBCL 1.0.2 and think I found a bug in the reader.  The
> following code returns NIL.  I believe it should return T.
> 
> (let ((foo (cons #1=(cons nil nil) #1#)))
>        (eq (car foo) (cdr foo)))
> 
> Can someone confirm this?

The behavior that SBCL exhibits is correct. To prove this to yourself, eval
a quoted version of the whole expression so you can see what it looks like
after the reader is done with it:

CL-USER(1): '(let ((foo (cons #1=(cons nil nil) #1#)))
       (eq (car foo) (cdr foo)))

(LET ((FOO (CONS (CONS NIL NIL) (CONS NIL NIL))))
  (EQ (CAR FOO) (CDR FOO)))

It's irrelevant that the code shares structure; the objects it produces do
not.

--

-- 
Brian Mastenbrook
brian <at> mastenbrook.net
http://brian.mastenbrook.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
David | 2 Apr 2007 04:41
Picon
Favicon

Re: found circular reading bug

Kevin Reid wrote:
> This is not a bug. While the two CONS subforms may be the same 
> s-expression, they are still separate parts of the code, and evaluated 
> independently, and each produces a fresh cons cell.
>
> (flet ((bar () (cons nil nil)))
>   (let ((foo (cons (bar) (bar))))
>     (eq (car foo) (cdr foo))))
I see.  So what I should have written to get what I want is this:

(let* ((foo (cons nil nil))
        (bar (cons #1=foo #1#)))
       (eq (car bar) (cdr bar)))

That works as I expect.  Thank you for the explanation, and thank you 
sbcl-devel for such a great compiler.

Cheers,
David

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |

Gmane