[Openmcl-devel] Weird bug

[Gary Byers]

The backtrace suggests that the main thread is indeed running its
event loop.

If an error (a lisp error or an NSException) occurs in that thread,
the lisp tries to write an error message and a stack backtrace to
*terminal-io*; when the IDE is running as a standalone application,
the output side of that process's *terminal-io* is a sytem logging
device; under Leopard at least, that output goes (reliably) to
/var/log/system.log ; it can be viewed with Apple's "Console" program
(/Applications/Utilities/Console.app.)

There may or may or may not be any output in your case; if there is,
it might shed some light on what the problem is.

On Mon, 5 Nov 2007, Ron Garret wrote:

> The IDE occasionally gets itself into a weird state where it seems to
> still respond to events as far as the OS is concerned but it doesn't
> actually do anything, i.e. I can select items from the IDE menus but
> nothing actually happens (including when I try to quit).  The only way
> I've found to get out of this state is to open a terminal window and
> kill the process.  This seems to happen randomly.  I have not been
> able to figure out how to reliably reproduce it.  Here's my amateurish
> attempt to debug this:
>
> [ron at mickey:~]$ ps -axwwww 1930
>   PID TTY           TIME CMD
>  1930 ??         0:13.01 /Users/ron/Desktop/ccl/Clozure CL.app/
> Contents/MacOS/dx86cl64 -psn_0_786624
> [ron at mickey:~]$ gdb
> GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct  2 04:07:49
> UTC 2007)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-apple-darwin".
> (gdb) attach 1930
> Attaching to process 1930.
> Reading symbols for shared libraries . done
> Reading symbols for shared
> libraries
>  ................................................................................. done
> 0x00007fff80cf7816 in mach_msg_trap ()
> (gdb) bt
> #0  0x00007fff80cf7816 in mach_msg_trap ()
> #1  0x00007fff80cfee4b in mach_msg ()
> #2  0x00007fff80fd1d7f in CFRunLoopRunSpecific ()
> #3  0x00007fff8034f9cd in RunCurrentEventLoopInMode ()
> #4  0x00007fff8034f804 in ReceiveNextEventCommon ()
> #5  0x00007fff8034f6af in BlockUntilNextEventMatchingListInMode ()
> #6  0x00007fff81584ff3 in _DPSNextEvent ()
> #7  0x00007fff815849fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #8  0x00007fff8157e796 in -[NSApplication run] ()
> #9  0x000000000000bea7 in SPffcall () at ../x86-spentry64.s:3957
> #10 0x000000000000ca1d in start_lisp () at ../x86-subprims64.s:109
> #11 0x000000000000e3fc in main (argc=21763, argv=0x0, envp=0x0,
> aux=0x7fff5fbfec18) at ../pmcl-kernel.c:1589
> (gdb)
>
> Is there anything else I can do to collect useful information about
> this before I file a bug report?  (Has anyone else seen this behavior?)
>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>