[Openmcl-devel] Error Running Currency Converter
Chris Van Dusen
cavandusen at gmail.com
Wed Jul 30 19:23:35 PDT 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