[Openmcl-devel] Error Running Currency Converter

Chris Van Dusen cavandusen at gmail.com
Thu Jul 31 02:23:35 UTC 2008


I've found that if it isn't implausible, then it will eventually occur.

After svn update, rebuild full gave me this:

;Loading #P"/Users/chrisvandusen/bin/ccl/bin/x8632-arch.dx64fsl"...
 > Error: Constant NIL-VALUE is already defined with a different value  
(12289)
 > While executing: CCL::DEFINE-CONSTANT, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Redefine NIL-VALUE to have new value 77825
 > Type :? for other options.

The backtrace shows:

5A400) : 0 (DEFINE-CONSTANT 'NIL-VALUE 77825) 261
  (65A428) : 1 (%DEFCONSTANT 'NIL-VALUE 77825 [...]) 141
  (65A450) : 2 (FUNCALL #'#<Anonymous Function #x3000400B0B1F>  
#<FASLSTATE  #x76AF0D>) 77
  (65A470) : 3 (%FASLOAD "/Users/chrisvandusen/bin/ccl/bin/x8632- 
arch.dx64fsl" [...]) 1285
  (65A518) : 4 (%LOAD #P"/Users/chrisvandusen/bin/ccl/bin/x8632- 
arch.dx64fsl" T NIL :ERROR :DEFAULT) 2381
  (65A680) : 5 (LOAD "/Users/chrisvandusen/bin/ccl/bin/x8632- 
arch.dx64fsl" [...]) 1037
  (65A720) : 6 (%COMPILE-FILE "/Users/chrisvandusen/bin/ccl/compiler/ 
X86/X8632/x8632-arch.lisp" "/Users/chrisvandusen/bin/ccl/bin/x8632- 
arch.dx64fsl" T NIL T NIL T T NIL :DEFER NIL #<BACKEND DARWINX8664  
#x30004073BE5D> :DEFAULT) 2981
  (65A7E8) : 7 (COMPILE-FILE "ccl:compiler;X86;X8632;x8632- 
arch.lisp" [...]) 1253
  (65A908) : 8 (UPDATE-MODULES '(CCL::X8632-ARCH CCL::X8664-ARCH  
CCL::X86-ARCH CCL::X8632ENV CCL::X8664ENV ...) [...]) 525
  (65A9A0) : 9 (COMPILE-CCL [...]) 165
  (65A9C0) : 10 (REBUILD-CCL [...]) 1813
  (65AAF8) : 11 (CALL-CHECK-REGS 'CCL:REBUILD-CCL [...]) 229
  (65AB30) : 12 (TOPLEVEL-EVAL '(CCL:REBUILD-CCL :FULL T) [...]) 733
  (65ABD0) : 13 (READ-LOOP [...]) 1741
  (65ADD8) : 14 (TOPLEVEL-LOOP) 125
  (65AE08) : 15 (FUNCALL #'#<(:INTERNAL (CCL:TOPLEVEL-FUNCTION  
(CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 101
  (65AE20) : 16 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER- 
PROCESS)>) 645
  (65AEB8) : 17 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1)  
[Active] #x300040D652AD> '(#)) 717
  (65AF48) : 18 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET- 
INTERNAL)> #<TTY-LISTENER listener(1) [Active] #x300040D652AD> '(#)) 389
  (65AF98) : 19 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP- 
FUNCTION)>) 293


Thanks,
Chris.

On Jul 30, 2008, at 6:42 PM, Gary Byers wrote:

> I was able to look at this (without having the lisp segfault on me  
> every
> time I looked at it funny) and think that it's now fixed in the trunk
> svn.  (The problem was caused/exposed by some code that's been in the
> trunk for a while, but which isn't in 1.2)
>
> If it's not fixed (after svn update/rebuild-ccl :full t) or if it
> recurs, please re-open
> <http://trac.clozure.com/openmcl/ticket/320>
>
> Although the details of the problem generally aren't interesting,  
> here's
> a bit of background that may or may not be documented elsewhere.
>
> A pointer to foreign memory generally doesn't remain valid across
> sessions: a foreign object (simple function or variable, ObjC class,
> etc.)  generally doesn't have the same address across sessions (some
> environments deliberately try to randomize the addresses where shared
> libraries load to make security exploits slightly harder to write;
> different library versions may be involved, etc.)  It'd generally
> be a coincidence if a foreign object's address didn't change and
> a subtle error to assume that it wouldn't.
>
> To help catch such errors (and make them less subtle), SAVE- 
> APPLICATION
> changes the type of every (non-NULL) MACPTR in the heap to "DEAD- 
> MACPTR";
> most primitive operations on MACPTRs typecheck their arguments and
> signal a type error if they receive a DEAD-MACPTR as an argument.
>
> So:
>
> ? (defvar *p* (#_malloc 1))
> *p*
> ? (setf (%get-unsigned-byte *p* 0) 17)
> 17
> ? (%get-unsigned-byte *p* 0)
> 17
> ? (save-application ...)
> ;; run the new image
> ? (%get-unsigned-byte *p* 0)
>
> should signal an error complaining that the value of *P* is a DEAD- 
> MACPTR
> (and not a MACPTR.)  It'd be blind luck if the address encapsulated by
> *P* was still valid (and could be referenced without causing a memory
> fault), and even blinder luck if it still pointed to 17.
>
> In that example (which isn't that implausible), the error's a user- 
> level
> error.  In the implementation itself, there are lots of opportunities
> for similar errors.
>
>
> On Wed, 30 Jul 2008, Chris Van Dusen wrote:
>
>> Thanks for all of the replies regarding this.
>> I understand that the current instability makes determining what's  
>> a user
>> error versus an implementation error difficult, and don't want to  
>> be a pest
>> about it.  In this particular case, I went by the responses that I  
>> had seen
>> in my search for this error (i.e., it was an error in the user's  
>> code), and
>> asked from that perspective.  In hindsight, I guess it would have  
>> helped if
>> I had sent the code. :)
>>
>> Thanks again,
>> Chris.
>>
>> On Wed, Jul 30, 2008 at 3:15 PM, Gary Byers <gb at clozure.com> wrote:
>>
>>> And in case anyone's confused by that reply:
>>>
>>> r10236 fixed a bug in the currency-converter example in 1.2 (a  
>>> method
>>> that was implicitly defined to return :id returned NIL.)  The same
>>> bug's in the trunk, but the error that Chris is seeing seems to be
>>> occurring during ObjC (re)initialization, long before we get to that
>>> point.
>>>
>>> r10246 fixed a bug in the kernel code that caused the frame pointer
>>> register to be restored incorrectly when PROCESS-INTERRUPT returned.
>>> that often led to a segfault and general wackiness.
>>>
>>> On Wed, 30 Jul 2008, Gary Byers wrote:
>>>
>>>> I'd be surprised if it does, but it may fix at least large parts of
>>>> the general trunk instability that I was admonishing about.  Just
>>>> doing:
>>>>
>>>> (require "COCOA")
>>>>
>>>> was (for me) a reliable way to trigger the bug.  (The initial  
>>>> thread
>>>> segfaulted when it returned from loading the Cocoa library via
>>>> PROCESS-INTERRUPT, and trying to track down another problem when
>>>> things were that flaky seemed pointless.)
>>>>
>>>> I'd also seen similar segfaults during QUIT, and I don't think that
>>>> that's quite the same scenario (PROCESS-INTERRUPT is used in QUIT,
>>>> but (IIRC) none of the functions invoked via PROCESS-INTERRUPT  
>>>> while
>>>> quitting ever return, and I'm not sure if that's another symptom
>>>> of the same problem.  (In QUIT, the thread that got the segfault
>>>> was something other than the initial thread, and the initial thread
>>>> got tired of waiting for it to die and terminates it with extreme
>>>> prejudice.)
>>>>
>>>> On Wed, 30 Jul 2008, R. Matthew Emerson wrote:
>>>>
>>>>>
>>>>> On Jul 30, 2008, at 3:41 PM, mikel evins wrote:
>>>>>
>>>>>>
>>>>>> On Jul 30, 2008, at 12:26 PM, Chris Van Dusen wrote:
>>>>>>
>>>>>>> Mikel,
>>>>>>>
>>>>>>> Running CurrencyConverter, I get this:
>>>>>>>
>>>>>>> Error during early application initialization:
>>>>>>>
>>>>>>> value #<A Dead Mac Pointer> is not of the expected type MACPTR.
>>>>>>>
>>>>>
>>>>>
>>>>> Does http://trac.clozure.com/openmcl/changeset/10236 fix this  
>>>>> problem?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openmcl-devel mailing list
>>>>> Openmcl-devel at clozure.com
>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Openmcl-devel mailing list
>>>> Openmcl-devel at clozure.com
>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>
>>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>




More information about the Openmcl-devel mailing list