Steel Bank Common Lisp

Hi Richard,

Thanks for letting me know about the bug in SBCL / Windows. How could  
I learned that this is a known problem (i.e., is it on a website  
somewhere?)


On Jun 20, 2008, at 10:38 AM, Richard M Kreuter wrote:

> Gary King writes:
>> I've been trying to test asdf-install on VMWare Windows 2000 (hosted
>> by OS X) under SBCL 1.0.13. The SBCL version of ASDF-Install just
>> hangs an the portable version gives an unenlightening error message.
>> The problem seems to be with calls to external programs. If I start
>> sbcl and try
>>
>> (with-output-to-string (out)
>>  (sb-ext:run-program "path-to-handle.exe"  nil :output out :wait t))
>>
>> SBCL just hangs. If I give up and type control-C, I am returned to  
>> the
>> shell.
>>
>> Any thoughts on debugging this will be much appreciated,
>
> This has been reported before.  Invoking RUN-PROGRAM so that the  
> output
> of the program goes to a Lisp stream doesn't work on Windows, and is
> less a debuggable detail than a tricky-to-support interface, where the
> tricks haven't been worked out yet on Windows [*].
>
> As a workaround, if you have a POSIX shell available on your Windows
> system, you might be able to get the desired result by having the  
> shell
> run the requisite commands redirecting the output to a file, and then
> reading the file in, e.g.
>
> (defun run-shell-command-for-output (command &rest args)
>  (let ((output
>         (pathname
>          (loop thereis (open (format nil "TEMP-~D" (random 100000))
>                              :direction :probe :if-exists nil
>                              :if-does-not-exist :create)))))
>    (run-program "sh" (list "-c" (format nil "~a ~{~a ~} > ~a"
>                                         command args (namestring  
> output)))
>                 :search t :wait t)
>    (prog1
>        (with-open-file (stream output)
>          (let ((buffer (make-array (file-length stream)
>                                    :element-type 'character)))
>            (subseq buffer 0 (read-sequence buffer stream))))
>      (delete-file output))))
>
> Hope that helps for now,
> Richard
>
> [*] IIRC, the specific issue is that Windows's select() only works on
> sockets, not descriptors corresponding to pipes; and at the moment
> SERVE-EVENT relies on a faked select() on Windows.  (There are some
> other oddities in the Windows-specific code in run-program.lisp,
> run-program.c, too, having to do with reads that can't possibly fail  
> to
> block, etc.)
>
> Supporting all of RUN-PROGRAM properly on Windows probably entails a
> nontrivial reworking of FD-STREAMs, SERVE-EVENT, and RUN-PROGRAM  
> itself,
> and there are some outstanding open design decisions involved, first  
> of
> which is whether to support both Win32-oid handles and POSIX-oid
> descriptors in the same SBCL on Windows.  (I have a tree where
> FD-STREAMs can use filehandles on Windows, and SERVE-EVENT seems to
> mostly work there (thanks to Alastair Bridgewater), but couldn't  
> manage
> to get RUN-PROGRAM working with Win32 CreateProcess.  If anybody wants
> to take this up, or wants me to continue working on this, please  
> contact
> me privately.)

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Gary King writes:
> 
> Thanks for letting me know about the bug in SBCL / Windows. How could  
> I learned that this is a known problem (i.e., is it on a website  
> somewhere?)

I searched for "Windows RUN-PROGRAM" in Gmane's reader, and found some
hits.

http://search.gmane.org/search.php?group=gmane.lisp.steel-bank.devel&query=windows+run-program

--
Richard

Gerard Robin writes:

> I am using sbcl (1.0.17) in Debian Sid and when I launch sbcl I do:
> 
> (symbop +)
> T
> (symbolp +)
> NIL
> 
> (quit)
> 
> I launch again sbcl :
> (symbolp -)
> NIL
> 
> (quit)
> 
> I launch again sbcl :
> (symbolp /)
> T
> (symbolp /)
> NIL
> 
> (quit)
> 
> I launch again sbcl :
> 
> (symbolp *)
> T
> (symbolp *)
> T
> 
> Are these results correct ?

The Common Lisp top level loop binds several variables, including +, -,
*, and /.  See

http://www.lispworks.com/documentation/HyperSpec/Body/25_aa.htm

--
RmK

On Tue, Jun 10, 2008 at 01:43:40PM -0400, Richard M Kreuter wrote:
>From: Richard M Kreuter <kreuter@...>
>To: Gerard Robin <g.robin3@...>
>Cc: sbcl-help <sbcl-help@...>
>Subject: Re: [Sbcl-help] + - / * are symbols or are not symbols ?
>X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 22.0.51
>
>Gerard Robin writes:
----------------------8<-------------------------
>> (symbolp *)
>> T
>> (symbolp *)
>> T
>> 
>> Are these results correct ?
>
>The Common Lisp top level loop binds several variables, including +, -,
>*, and /.  See
>
>http://www.lispworks.com/documentation/HyperSpec/Body/25_aa.htm

Many thanks.
-- 
Gérard

Shouldn't that be:

    (symbolp '+)
    (symbolp '-)
    etc.

Otherwise, if you don't quote it, it depends on whether or not the value 
of the symbol is a symbol.

The Lisp REP treats those specific symbols as a history mechanism 
therefore their values are dependent on how they are used in the history 
mechanism - which is system specific.

Blake McBride


Richard M Kreuter wrote:
> Gerard Robin writes:
>
>   
>> I am using sbcl (1.0.17) in Debian Sid and when I launch sbcl I do:
>>
>> (symbop +)
>> T
>> (symbolp +)
>> NIL
>>
>> (quit)
>>
>> I launch again sbcl :
>> (symbolp -)
>> NIL
>>
>> (quit)
>>
>> I launch again sbcl :
>> (symbolp /)
>> T
>> (symbolp /)
>> NIL
>>
>> (quit)
>>
>> I launch again sbcl :
>>
>> (symbolp *)
>> T
>> (symbolp *)
>> T
>>
>> Are these results correct ?
>>     
>
> The Common Lisp top level loop binds several variables, including +, -,
> *, and /.  See
>
> http://www.lispworks.com/documentation/HyperSpec/Body/25_aa.htm
>
> --
> RmK
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>
>

Gerard Robin writes:
> Hello,
> I am using sbcl (1.0.17) in Debian Sid and when I launch sbcl I do:
> 
> (symbop +) 
> T
> (symbolp +)
> NIL
> 
> Are these results correct ? 

Yes.

Remember the evaluation rules.  They're quite simple really.

To evaluate a lisp expression:
   if it is an atom then
       if it is a symbol then
           if the symbol is a symbol-macro then
               return the evaluation of the expansion of this symbol macro.
           else if there is a value bound to that symbol then
               return the value bound to that symbol 
           else
               it's an error (unbound variable)
           endif
       else
           return the expression itself 
       endif
   else -- it is a list
       the operator is the first element of the list
       the arguments are the remaining elements of the list
       if the operator is a special operator then
           return the result of the call to this special operator evaluation routine with the arguments
       else if the operator is a macro then
           return the evaluation of the expansion of this macro
       else if the operator is a symbol then
           evaluate each argument in turn and store the results in the parameters
           return the results of the call of the function fbound to that symbol with the parameters
       else if the operator is a lambda function then
           evaluate each argument in turn and store the results in the parameters
           return the results of the call of this lambda function with the parameters
       else
           it's an error
       endif
   endif
end


I took the pain to write it in English,  because any good lisp book
will cite the lisp version of the EVAL function, and you should
already know it by heart.

So, let's evaluate (symbolp +)

it is not a symbol so we jump to the else.  the operator is the symbol
SYMBOLP.  It is not a special operator, it is not a macro, it's a
function. So we must evaluate the arguments from the list (+) each one
in turn.

   The first argument is the symbol +.
   It is not a symbol-macro.
   It is bound to some value, so we return that value.

We get this  value and use it as the first  parameter for the function
fbound to the symbol SYMBOLP.

There's no more argument so we call the function fbound to the symbol
SYMBOLP.  According to the value it gets, it will return T or NIL.

This result is returned.


So for example:

(let ((+ 42))
  (print (symbolp +))
  (print (symbolp +))
  (values))

will print:

NIL
NIL

while

(let ((+ '+))
  (print (symbolp +))
  (print (symbolp +))
  (values))

will print:

T
T


Now to explain the results you get when you evaluate these expressions
at the REPL (Read Eval Print Loop), you have to know how the REPL is
specified.  Richard gave you a reference.

Here is my understanding of the REPL:

(defmacro handling-errors (&body body)
  `(HANDLER-CASE (progn ,@body)
     (simple-condition 
         (ERR) 
       (format *error-output* "~&~A: ~%" (class-name (class-of err)))
       (apply (function format) *error-output*
              (simple-condition-format-control   err)
              (simple-condition-format-arguments err))
       (format *error-output* "~&")
       (finish-output))
     (condition 
         (ERR) 
       (format *error-output* "~&~A: ~%  ~S~%"
               (class-name (class-of err)) err)
       (finish-output))))

(defvar -)
(defvar +)
(defvar ++)
(defvar +++)
(defvar /)
(defvar //)
(defvar ///)
(defvar *)
(defvar **)
(defvar ***)

(defun repl ()
  (do ((+eof+ (gensym))
       (hist 1 (1+ hist)))
      (nil)
    (format t "~%~A[~D]> " (package-name *package*) hist)
    (finish-output)
    (handling-errors
     (setf - (read *standard-input* nil +eof+))
     (when (or (eq - +eof+)
               (member - '((quit)(exit)(continue)) :test (function equal)))
       (return-from repl))
     (let ((results (multiple-value-list (eval -))))
       (shiftf +++ ++ + -)
       (shiftf /// // / results)
       (shiftf *** ** * (first /)))
     (format t "~& --> ~{~S~^ ;~%     ~}~%" /)
     (finish-output))))

So as you can see, each time you give an expression to the REPL, the
variable + is bound to the expression you gave.

See also http://www.lispworks.com/documentation/HyperSpec/Body/03_.htm

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"You can tell the Lisp programmers.  They have pockets full of punch
 cards with close parentheses on them." --> http://tinyurl.com/8ubpf

"Leslie P. Polzer" <leslie.polzer@...> writes:

> Is there a way to access the condition object in the debugger?
> I'd like to take a look at a simple condition's FORMAT-CONTROL/FORMAT-ARGUMENTS.

For the case that you use Slime, you can press `C' in SLDB, which pops
up the inspector on the condition object. In the inspector you can press
`M-RET' on the header line (the #<SIMPLE-ERROR {...}>) to send the
object to the REPL where you can frob with it as you want.

If you don't use Slime, and want to know the programmatic way, you can
look into swank-sbcl.lisp how this feature is implemented.

HTH,

  -T.

> If you don't use Slime, and want to know the programmatic way, you can
> look into swank-sbcl.lisp how this feature is implemented.

I think Swank just HANDLER-BINDs any conditions in its debugging environment setup

But I just found it using APROPOS trial and success:

SB-DEBUG:*DEBUG-CONDITION* holds the condition object.

  Leslie

On Jun 1, 2008, at 15:43, Patrick Stein wrote:
> If I do "./run.sh" then everything works just as I would expect.
> And, I can do "./run.sh ; ./run.sh" and it runs twice.
>
> But, if I try to do "./run.sh & ./run.sh" so that they both run at
> the same time, I get one SEGV and one success.  If I put three in
> the background and one in the foreground, I get three SEGVs and one
> success.

I noticed the same behavior a long time ago, and can reproduce it  
even now, as shown below. I am also on a PPC Mac (PowerBook G4), Mac  
OS X 10.4.11.

If anyone would like me to try building with experimental fixes or  
debugging traces, let me know (on sbcl-devel).


[Magpie:~ kpreid]$ for x in 1 2 3 4; do sbcl --no-sysinit --no- 
userinit --eval "(progn (print $x) (quit))" & done
[5] 4991
[6] 4992
[7] 4993
[8] 4994
[Magpie:~ kpreid]$ This is SBCL 1.0.16.11, an implementation of ANSI  
Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
This is SBCL 1.0.16.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
This is SBCL 1.0.16.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
This is SBCL 1.0.16.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

4
[5]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval  
"(progn (print $x) (quit))"
[6]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval  
"(progn (print $x) (quit))"
[7]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval  
"(progn (print $x) (quit))"
[8]-  Done                    sbcl --no-sysinit --no-userinit --eval  
"(progn (print $x) (quit))"
[Magpie:~ kpreid]$

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>

> [5]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval
> "(progn (print $x) (quit))"
> [6]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval
> "(progn (print $x) (quit))"
> [7]   Segmentation fault      sbcl --no-sysinit --no-userinit --eval
> "(progn (print $x) (quit))"
> [8]-  Done                    sbcl --no-sysinit --no-userinit --eval
> "(progn (print $x) (quit))"

This is very wierd. Even with segfaults in unknown addresses you
should be getting debugger (or at least LDB) prompts and reports from
the shell about stopped processes. If SBCL dies from a segfault like
this it seems to me that the handlers have not been set up yet, which
means nothing very much is happening yet.

I might be instructive to stick

 sleep(60);
 exit(42);

into main(), and see how far things get. I suspect the trouble happens
just before the call

  enable_lossage_handler()

...that in turn make me think that maybe mmap'ing the core didn't go
quite right.

Cheers,

 -- Nikodemus

On Sun, Jun 1, 2008 at 6:30 PM, Nikodemus Siivola
<nikodemus@...> wrote:
> This is very wierd. Even with segfaults in unknown addresses you
> should be getting debugger (or at least LDB) prompts and reports from
> the shell about stopped processes. If SBCL dies from a segfault like
> this it seems to me that the handlers have not been set up yet, which
> means nothing very much is happening yet.

Yes, I was hoping to figure out what was going on in gdb(1), but I definitely
wasn't getting the core read in right there.  Or, at least the initial function
it chose was on a page that wasn't executable.

When I get a chance, I'll try sticking some stuff into main to figure out
exactly where.  I suppose if it set up the interrupt handlers to jump into
the sbcl.core somewhere and then managed to catch a signal before
the mmap was ready... I dunno....

I, too, suspect mmap(2), but there's a segment of code where it tries to
determine if you're masked from getting an interrupt while handling an
interrupt.  That seems like a potential place to go afoul in the kernel, too.

more later,
Patrick

ps. Sorry about the vacuous reply earlier, Nikodemus.  I have not yet
mastered iPhone+Gmail+MailingLists.

On Mon, Jun 2, 2008 at 5:36 AM, Patrick Stein <sbcl-help@...> wrote:

> Yes, I was hoping to figure out what was going on in gdb(1), but I definitely
> wasn't getting the core read in right there.  Or, at least the initial function
> it chose was on a page that wasn't executable.

Oh, I missed that bit of your email. GDB can't understand SBCL core
files To run SBCL under GDB you normally just do "gdb sbcl".

In this case, something like this might be instructive:

cat > cmds
handle SIGUSR1 nostop noprint pass
trace main
trace enable_lossage_handler
trace arch_install_interrupt_handlers
trace create_initial_thread
run --eval '(progn (sleep 1) (quit))'
q
^D

gdb -x cmds sbcl & gdb -x cmds sbcl

> When I get a chance, I'll try sticking some stuff into main to figure out
> exactly where.  I suppose if it set up the interrupt handlers to jump into
> the sbcl.core somewhere and then managed to catch a signal before
> the mmap was ready... I dunno....
>
> I, too, suspect mmap(2), but there's a segment of code where it tries to
> determine if you're masked from getting an interrupt while handling an
> interrupt.  That seems like a potential place to go afoul in the kernel, too.

My mmap suspicions are centered getting the memory at the wrong
address (but having mmap lie about it), or getting MAP_SHARED even
when we ask for MAP_PRIVATE.

> ps. Sorry about the vacuous reply earlier, Nikodemus.  I have not yet
> mastered iPhone+Gmail+MailingLists.

Heh, no problem. I added the list back to CC. :)

Cheers,

 -- Nikodemus

On Mon, Jun 2, 2008 at 3:18 AM, Nikodemus Siivola
<nikodemus@...> wrote:
> Oh, I missed that bit of your email. GDB can't understand SBCL core
> files To run SBCL under GDB you normally just do "gdb sbcl".

Yes, there was some confusing language in my previous message
because I was at times trying to refer to the /usr/local/lib/sbcl/sbcl.core
and at other times trying to refer to the core file created by Darwin for
me after the SEGV.  I was hoping that GDB would be able to still grok
the Darwin generated core file.  And, it looks like it does.  It doesn't
understand the stack very well though.  But, I can still query global
C variables and such.

So, I did this.  I added these lines to the top of runtime.c:
const char* cur_file = __FILE__;
unsigned int cur_line = __LINE__;

and these at the top of some other files:
extern const char* cur_file;
extern unsigned int cur_line;

Then, at various points around runtime.c and thread.c, I did this:
{ cur_file = __FILE__; cur_line = __LINE__; }

When, I had only done it for runtime.c, I made it the whole way down
the end of main() to the create_initial_thread().  That doesn't mean that
everything went well before then... it still could be the mmap(2) having
problems.  But, it didn't die in the enable_lossage_handler() portion.

Now, I've run it again with the flagging in thread.c.  I've made it to the
last line of initial_thread_trampoline()... the 'funcall0'.  And, by the looks
of the program-counter, I am actually well into executing... I've made it
significantly past the address of the initial function.  I'm not sure that
my ppc asm fu is ready to try to continue my __LINE__ tracing into
the call_into_lisp() routine.  But, it does seem like it's getting into lisp
and executing for a bit before the fall.

I am ending up in ldb again now.  Yesterday, I wasn't.
Doh, spoke too soon... I didn't end up in ldb this time.

> My mmap suspicions are centered getting the memory at the wrong
> address (but having mmap lie about it), or getting MAP_SHARED even
> when we ask for MAP_PRIVATE.

Yes, I could imagine a race condition in the kernel around MAP_PRIVATE.
MAP_PRIVATE and MAP_SHARED should be identical until you try to
write.  So, I'm supposing that we MAP_PRIVATE the sbcl.core and
start motoring along.  Then, maybe both processes try to write to the
same page that's well into the core... somewhere where the kernel
hasn't bothered reading it in off the disk yet since we haven't needed
that part at all yet.  Now, right in the middle of reading it in from the
disk, it realizes that it needs a second copy of that same page since
both procs want to write to it.  It still hasn't finished sucking it off the
disk yet and freaks out.

But, something like that... I would expect to see show up in various
shared library loads.  And, I would expect it to result in a kernel
panic rather than a user-level core dump.  So, I'm still cautious here.

But, I'm going to write a little code to MAP_SHARED something into two
procs and try to get one to SEGV.

ttyl,
Patrick

On Mon, Jun 2, 2008 at 9:51 AM, Patrick Stein <sbcl-help@...> wrote:
> On Mon, Jun 2, 2008 at 3:18 AM, Nikodemus Siivola
> <nikodemus@...> wrote:
>> My mmap suspicions are centered getting the memory at the wrong
>> address (but having mmap lie about it), or getting MAP_SHARED even
>> when we ask for MAP_PRIVATE.

So, I like the MAP_SHARED theory... but I don't like the wrong address theory.
I can't form a useful hypothesis about why it would lie to all but one of the
procs in this scenario.  I would expect to it to either lie to all of
them or just
some percentage of them.  But, it would have to be lying to n-1 of them.
And, I can't think of how it could manage that.

ttyl,
Patrick

So, I just recompiled with QSHOW defined.  Then, I did this:
===============================================================
for job in 1 2; do
    /tmp/sbcl/bin/sbcl --noinform --no-userinit --no-sysinit \
        --eval "(progn (print ${job}) (quit))" \
        1> /tmp/out.${job} 2>&1 &
done
===============================================================

I was really surprised by the output.  Job 1 crashed.  Job 2 generated
all kinds of complaints about possible heap WP violations and
succeeded.

Job 1 crashed with the program counter at 0x10aea7d8
          whilst the initial_function was 0x1000f9bd.

So, it's looking like both processes memory fault, one catches the
faults, the other doesn't.  Of course, none of the memory faults
in job 2 seem to have happened while the PC was at 10aea7d8.  Though,
I suppose that maybe job 1 is trying to handle the fault by jumping
into someplace bad.  I dunno.

more later,
Patrick

====diff -c out.1 out.2========================================
*** out.1	2008-06-02 11:35:51.000000000 -0500
--- out.2	2008-06-02 11:35:51.000000000 -0500
***************
*** 77,79 ****
--- 77,209 ----
  /os_install_interrupt_handlers()/bsd-os/defined(GENCGC)
  /leaving os_install_interrupt_handlers()
  /funcalling initial_function=0x1000f9bd
+ Memory fault at: 0x100e749c, PC: 0x10061290
+ heap WP violation? fault_addr=100e749c, page_index=231
+ Memory fault at: 0x101421d0, PC: 0x101a7dd8
+ heap WP violation? fault_addr=101421d0, page_index=322
+ Memory fault at: 0x100cfdfc, PC: 0x100480e0
+ heap WP violation? fault_addr=100cfdfc, page_index=207
+ Memory fault at: 0x10eaa920, PC: 0x10421c58
+ heap WP violation? fault_addr=10eaa920, page_index=3754
+ Memory fault at: 0x10b7e0dc, PC: 0x10421c68
+ heap WP violation? fault_addr=10b7e0dc, page_index=2942
+ Memory fault at: 0x10ea70c8, PC: 0x10421c98
+ heap WP violation? fault_addr=10ea70c8, page_index=3751
+ Memory fault at: 0x102dc130, PC: 0x10421c58
+ heap WP violation? fault_addr=102dc130, page_index=732
+ Memory fault at: 0x101716fc, PC: 0x10421c68
+ heap WP violation? fault_addr=101716fc, page_index=369
+ Memory fault at: 0x102c3898, PC: 0x10421c98
+ heap WP violation? fault_addr=102c3898, page_index=707
+ Memory fault at: 0x10360170, PC: 0x109285d8
+ heap WP violation? fault_addr=10360170, page_index=864
+ Memory fault at: 0x10179d98, PC: 0x102e7e00
+ heap WP violation? fault_addr=10179d98, page_index=377
+ Memory fault at: 0x100812f4, PC: 0x1013e354
+ heap WP violation? fault_addr=100812f4, page_index=129
+ Memory fault at: 0x1026bf64, PC: 0x1013e3b8
+ heap WP violation? fault_addr=1026bf64, page_index=619
+ Memory fault at: 0x100d1d1c, PC: 0x1013e48c
+ heap WP violation? fault_addr=100d1d1c, page_index=209
+ Memory fault at: 0x10124ef4, PC: 0x10195618
+ heap WP violation? fault_addr=10124ef4, page_index=292
+ Memory fault at: 0x100514ac, PC: 0x101950f4
+ heap WP violation? fault_addr=100514ac, page_index=81
+ Memory fault at: 0x1017ce14, PC: 0x102f252c
+ heap WP violation? fault_addr=1017ce14, page_index=380
+ Memory fault at: 0x1002801c, PC: 0x1031194c
+ heap WP violation? fault_addr=1002801c, page_index=40
+ Memory fault at: 0x10178f64, PC: 0x102e7e00
+ heap WP violation? fault_addr=10178f64, page_index=376
+ Memory fault at: 0x10027464, PC: 0x10195344
+ heap WP violation? fault_addr=10027464, page_index=39
+ Memory fault at: 0x100114bc, PC: 0x10b19c98
+ heap WP violation? fault_addr=100114bc, page_index=17
+ /entering POSIX install_handler(2, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(2, ..)
+ /entering POSIX install_handler(15, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(15, ..)
+ /entering POSIX install_handler(4, ..)
+ /interrupt_low_level_handlers[signal]=d920
+ /leaving POSIX install_handler(4, ..)
+ /entering POSIX install_handler(6, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(6, ..)
+ /entering POSIX install_handler(7, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(7, ..)
+ /entering POSIX install_handler(8, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(8, ..)
+ /entering POSIX install_handler(10, ..)
+ /interrupt_low_level_handlers[signal]=df00
+ /leaving POSIX install_handler(10, ..)
+ /entering POSIX install_handler(11, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(11, ..)
+ /entering POSIX install_handler(12, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(12, ..)
+ /entering POSIX install_handler(13, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(13, ..)
+ /entering POSIX install_handler(14, ..)
+ /interrupt_low_level_handlers[signal]=0
+ /leaving POSIX install_handler(14, ..)
+ Memory fault at: 0x1011f22c, PC: 0x103eb69c
+ heap WP violation? fault_addr=1011f22c, page_index=287
+ Memory fault at: 0x1002ec50, PC: 0x103eb78c
+ heap WP violation? fault_addr=1002ec50, page_index=46
+ Memory fault at: 0x1002f000, PC: 0x103eb78c
+ heap WP violation? fault_addr=1002f000, page_index=47
+ /entering collect_garbage(0)
+ Memory fault at: 0x100567d4, PC: 0xf158
+ heap WP violation? fault_addr=100567d4, page_index=86
+ /starting one full scan of newspace generation 7
+ /done with one full scan of newspace generation 7
+ Memory fault at: 0x10056874, PC: 0x4aac
+ heap WP violation? fault_addr=10056874, page_index=86
+ Next gc when 38751192 bytes have been consed
+ /returning from collect_garbage
+ Memory fault at: 0x10025c44, PC: 0x10034ac0
+ heap WP violation? fault_addr=10025c44, page_index=37
+ Memory fault at: 0x102e0048, PC: 0x10421c58
+ heap WP violation? fault_addr=102e0048, page_index=736
+ Memory fault at: 0x1017255c, PC: 0x10421c68
+ heap WP violation? fault_addr=1017255c, page_index=370
+ Memory fault at: 0x102e4010, PC: 0x10421c98
+ heap WP violation? fault_addr=102e4010, page_index=740
+ Memory fault at: 0x102e5000, PC: 0x10421c98
+ heap WP violation? fault_addr=102e5000, page_index=741
+ Memory fault at: 0x102e3008, PC: 0x10421cd8
+ heap WP violation? fault_addr=102e3008, page_index=739
+ Memory fault at: 0x100d002c, PC: 0x108b7274
+ heap WP violation? fault_addr=100d002c, page_index=208
+ Memory fault at: 0x10011624, PC: 0x101e4ad4
+ heap WP violation? fault_addr=10011624, page_index=17
+ Memory fault at: 0x10360170, PC: 0x109285d8
+ heap WP violation? fault_addr=10360170, page_index=864
+ Memory fault at: 0x10e49eb8, PC: 0x10140528
+ heap WP violation? fault_addr=10e49eb8, page_index=3657
+ Memory fault at: 0x110ea69c, PC: 0x1014051c
+ heap WP violation? fault_addr=110ea69c, page_index=4330
+ Memory fault at: 0x10b7feec, PC: 0x10b7f7d4
+ heap WP violation? fault_addr=10b7feec, page_index=2943
+ Memory fault at: 0x1000ca44, PC: 0x10004674
+ heap WP violation? fault_addr=1000ca44, page_index=12
+ Memory fault at: 0x10171700, PC: 0x101a7f98
+ heap WP violation? fault_addr=10171700, page_index=369
+ Memory fault at: 0x102186d0, PC: 0x10922908
+ heap WP violation? fault_addr=102186d0, page_index=536
+ Memory fault at: 0x1017d12c, PC: 0x102f252c
+ heap WP violation? fault_addr=1017d12c, page_index=381
+ Memory fault at: 0x100daaf4, PC: 0x101b6674
+ heap WP violation? fault_addr=100daaf4, page_index=218
+ Memory fault at: 0x10123d84, PC: 0x101b66e4
+ heap WP violation? fault_addr=10123d84, page_index=291
+ Memory fault at: 0x1002ae0c, PC: 0x1000d8ec
+ heap WP violation? fault_addr=1002ae0c, page_index=42
+
+ 2

On Mon, Jun 2, 2008 at 7:53 PM, Patrick Stein <sbcl-help@...> wrote:

> + Memory fault at: 0x100e749c, PC: 0x10061290
> + heap WP violation? fault_addr=100e749c, page_index=231

These seem business as usual: the heap is WP protected, so that we can
mark pages dirty when they are first written to.

Cheers,

 -- Nikodemus

On 6/2/08, Nikodemus Siivola <nikodemus@...> wrote:
> These seem business as usual: the heap is WP protected, so that we can
> mark pages dirty when they are first written to.

Ah, that makes sense. I have recompiled with a more advanced tracking
of which lines in src/runtime/ have been visited. It doesn't seem like
the dying proc ever makes it into the memory fault handler.  I have
now placed markers in the other interrupt handlers, but the PC seems
to indicate those aren't involved either.

Somehow, the dying proc segfaults without getting caught.

more later,
Patrick