gmane.lisp.openmcl.devel

headers Chris Van Dusen | 29 Jul 04:40 · /Contents/

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel <at> clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel

On Jul 28, 2008, at 9:40 PM, Chris Van Dusen wrote:

> Hi,
>
> I'm going through the currency converter example, and got to the  
> point of building the application.  After hitting Enter, the Clozure  
> IDE disappears (which, even though the tutorial says, "If all goes  
> well, BUILD-APPLICATION constructs an application bundle, copies  
> 'CurrencyConverter.nib' into it, writes the application executable,  
> and quits.", I don't know that this is what was meant).
>
> Anyway, the CurrencyConverter.app shows up, but when I double-click  
> it "nothing happens".  I looked in Console and found the following:
>
> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] Error  
> during early application initialization:
> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] value  
> #<A Dead Mac Pointer> is not of the expected type MACPTR.
> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] ? for  
> help
> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] [9130]  
> OpenMCL kernel debugger:
> 7/28/08 8:51:14 PM com.apple.launchd[73]  
> ([0x0-0x8a08a].com.clozure.Clozure CL[9130]) Exited: Killed
>
> Googling for the error seemed to indicate that this tends to be a  
> user error.
>
> Is this correct?  If so, I'll go back to triple check the code and  
> the Application Builder.  If not, would anyone know where to look  
> for possible clues?

It's also possible that recent changes broke the app builder somehow.

Try running the built application from the terminal. (open a terminal  
and run the executable that is in Currency Converter,app/Contents/ 
MacOS/). If it enters the kernel debugger as the log seems to  
indicate, then you should be able to use kernel debugger command to  
generate some useful debugging information. Use the "?" command to get  
a printout of the available commands. A stack backtrace is often  
useful for figuring out how the lisp crashed into the kernel debugger.

With any luck we can figure out why it happened and fix it, whether  
it's at your end or ours.

--me

On Tue, 29 Jul 2008, mikel evins wrote:

> It's also possible that recent changes broke the app builder somehow.

In fact, it's likely.

This is yet another example of why we keep saying "the trunk is really
volatile right now, we're continuing to make changes and it's generally
more important at the moment to make those changes than it is to fix
bugs that those changes inevitably introduce."  Once things settle down
a bit (they're settling), we'd certainly want to address them.  In the
meantime, there's a fairy good chance that today's bugs in the trunk
will be replaced by a new set tomorrow: if you want to use the trunk
right now, please (a) expect bugs and (b) be patient.  Thank you.

I'll add this in Trac, so that when the dust does settle it'll
still be glaringly open.

Mikel,

Running CurrencyConverter, I get this:

Error during early application initialization:

value #<A Dead Mac Pointer> is not of the expected type MACPTR.
? for help
[747] OpenMCL kernel debugger: ?
(G)  Set specified GPR to new value
(R)  Show raw GPR/SPR register values
(L)  Show Lisp values of tagged registers
(F)  Show FPU registers
(S)  Find and describe symbol matching specified name
(B)  Show backtrace
(T)  Show info about current thread
(X)  Exit from this debugger, asserting that any exception was handled
(P)  Propagate the exception to another handler (debugger or OS)
(K)  Kill OpenMCL process
(?)  Show this help
[747] OpenMCL kernel debugger:

Let me know if I can supply any more info.

Thanks,
Chris.

On Jul 29, 2008, at 2:18 AM, mikel evins wrote:

>
> On Jul 28, 2008, at 9:40 PM, Chris Van Dusen wrote:
>
>> Hi,
>>
>> I'm going through the currency converter example, and got to the
>> point of building the application.  After hitting Enter, the Clozure
>> IDE disappears (which, even though the tutorial says, "If all goes
>> well, BUILD-APPLICATION constructs an application bundle, copies
>> 'CurrencyConverter.nib' into it, writes the application executable,
>> and quits.", I don't know that this is what was meant).
>>
>> Anyway, the CurrencyConverter.app shows up, but when I double-click
>> it "nothing happens".  I looked in Console and found the following:
>>
>> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] Error
>> during early application initialization:
>> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] value
>> #<A Dead Mac Pointer> is not of the expected type MACPTR.
>> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] ? for
>> help
>> 7/28/08 8:51:14 PM [0x0-0x8a08a].com.clozure.Clozure CL[9130] [9130]
>> OpenMCL kernel debugger:
>> 7/28/08 8:51:14 PM com.apple.launchd[73]
>> ([0x0-0x8a08a].com.clozure.Clozure CL[9130]) Exited: Killed
>>
>> Googling for the error seemed to indicate that this tends to be a
>> user error.
>>
>> Is this correct?  If so, I'll go back to triple check the code and
>> the Application Builder.  If not, would anyone know where to look
>> for possible clues?
>
> It's also possible that recent changes broke the app builder somehow.
>
> Try running the built application from the terminal. (open a terminal
> and run the executable that is in Currency Converter,app/Contents/
> MacOS/). If it enters the kernel debugger as the log seems to
> indicate, then you should be able to use kernel debugger command to
> generate some useful debugging information. Use the "?" command to get
> a printout of the available commands. A stack backtrace is often
> useful for figuring out how the lisp crashed into the kernel debugger.
>
> With any luck we can figure out why it happened and fix it, whether
> it's at your end or ours.
>
> --me
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel <at> clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

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.
> ? for help
> [747] OpenMCL kernel debugger: ?
> (G)  Set specified GPR to new value
> (R)  Show raw GPR/SPR register values
> (L)  Show Lisp values of tagged registers
> (F)  Show FPU registers
> (S)  Find and describe symbol matching specified name
> (B)  Show backtrace
> (T)  Show info about current thread
> (X)  Exit from this debugger, asserting that any exception was handled
> (P)  Propagate the exception to another handler (debugger or OS)
> (K)  Kill OpenMCL process
> (?)  Show this help
> [747] OpenMCL kernel debugger:

Try the commands at your disposal to display the backtrace and perhaps  
the registers. Let's see what we can fgure out.

--me

On Jul 30, 2008, at 2: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.
>> ? for help
>> [747] OpenMCL kernel debugger: ?
>> (G)  Set specified GPR to new value
>> (R)  Show raw GPR/SPR register values
>> (L)  Show Lisp values of tagged registers
>> (F)  Show FPU registers
>> (S)  Find and describe symbol matching specified name
>> (B)  Show backtrace
>> (T)  Show info about current thread
>> (X)  Exit from this debugger, asserting that any exception was  
>> handled
>> (P)  Propagate the exception to another handler (debugger or OS)
>> (K)  Kill OpenMCL process
>> (?)  Show this help
>> [747] OpenMCL kernel debugger:
>
> Try the commands at your disposal to display the backtrace and  
> perhaps the registers. Let's see what we can fgure out.

By the way, we should keep Gary's admonishment in mind; we may be  
better served to wait a little while before trying to fix this. With  
the changes that are currently happening, there's a fair chance it  
will just get broken again until things settle down a bit.

--me

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?

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
>
>

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

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
>>
>

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
>>>
>>

On Jul 30, 2008, at 10:23 PM, Chris Van Dusen wrote:

> 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.

Just continue from that CERROR (and any similar ones that result from  
redefining other constants) by typing :GO at the prompt.

Doing that, I was able to get it to run.

After running the application by double-clicking the icon and pressing  
CMD-O, I ran it from the terminal as Mikel suggested which gave me this:

2008-07-30 21:57:13.306 CurrencyConverter[2332:10b] Lisp exception:  
value NIL is not of the expected type MACPTR.

but the app still worked.

Chris.

On Jul 30, 2008, at 9:32 PM, R. Matthew Emerson wrote:

>
> On Jul 30, 2008, at 10:23 PM, Chris Van Dusen wrote:
>
>> 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.
>
> Just continue from that CERROR (and any similar ones that result  
> from redefining other constants) by typing :GO at the prompt.
>
>

Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter

Re: Error Running Currency Converter