> Is lldb hanging, or is your program hanging? If lldb is hanging, can you file a bug with the backtrace of lldb (and a sample program if you can easily whip one up...)
You're right, it wasn't lldb's fault. I attached lldb to the simulator from the command-line, and everything worked as expected. The problem must lie somewhere in the bowels of Xcode. -Heath Borders [email protected] Twitter: heathborders http://heath-tech.blogspot.com On Mon, Oct 21, 2013 at 11:42 AM, <[email protected]> wrote: > > On Oct 19, 2013, at 11:11 PM, Heath Borders <[email protected]> > wrote: > > > (Sorry, I just discovered this list, and I don't know how to properly > jump into a thread I didn't receive in email. I tried to replicate quoting > one-level deep.) > > > > > > I want to be notified when a __weak reference in one of my objects is > about to be nil-ed. I accomplish this by allocating the object into a > specific VM page and then marking the page as read-only. When ARC nils the > __weak reference, I get an EXC_BAD_ACCESS, and I can mark the VM page as > read-write, run my tear-down code while the object is still valid, and then > return KERN_SUCCESS, which will allow ARC to continue on. However, as > Richard described earlier, LLDB hangs when I set a breakpoint inside any > code that isn't my exception handler when I use task_set_exception_ports. > > If you were watching all the exception types on the task exception port, > then it would make sense to me that we would hang trying to continue, since > lldb uses EXC_BREAKPOINT for its own purposes and if it is not seeing that, > it won't be able to run its execution logic. But if you are only watching > for the EXC_BAD_ACCESS exception then lldb it shouldn't care about this > (besides that lldb won't ever see real crashes.) > > Anyway, check that you really are only registering for the EXC_BAD_ACCESS > exception when you do the {task,thread}_set_exception_ports. Or, see > below, maybe this is happening because you aren't replying to the exception > message? > > > > > You suggested using thread_set_exception_ports to fix this issue. I > assume that thread_set_exception_ports only takes over exceptions that > occur on the thread given to thread_set_exception_ports, and not for the > whole task, like task_set_exception_ports does. Thus, I would need to call > thread_set_exception_ports on every thread since I care about getting an > EXC_BAD_ACCESS exception that occurs on any thread, right? My handler isn't > called if I register for exceptions with a different thread. > > > > Is there a way to be notified when a thread is created so I can > subscribe to its messages? > > Not that I am aware of. There's no very good way to to watch for > exceptions on threads you didn't create using the thread exception port, at > least not one I know about. > > > > > Also, I still see LLDB hanging when a use thread_set_exception_ports. Am > I doing something wrong? My code is below: > > Is lldb hanging, or is your program hanging? If lldb is hanging, can you > file a bug with the backtrace of lldb (and a sample program if you can > easily whip one up...) > > If it is your program that is hanging make sure you are sending on the > reply message that you get when your catch_exception_raise returns > KERN_SUCCESS. Maybe that is what mach_msg_server does, I've never used > that function so I don't know. In lldb we call mach_exc_server to trigger > the call to catch_exception_raise and that returns a reply right that you > have to send on to the appropriate exception port for the process to > continue. If you don't do that your program won't make progress. As I > said, that may be already handled in mach_msg_server, I don't know, not > having done it that way, but that's the only thing I can think of that > might hang you up. You can check out how lldb does this here: > > > http://llvm.org/svn/llvm-project/lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp > > Jim > > > > > > kern_return_t catch_exception_raise(mach_port_t exception_port, > > > > mach_port_t thread, > > > > mach_port_t task, > > exception_type_t exception, > > exception_data_t code_vector, > > mach_msg_type_number_t code_count) { > > > > x86_exception_state32_t x86_exception_state32; > > > > mach_msg_type_number_t sc = x86_EXCEPTION_STATE32_COUNT; > > > > thread_get_state(thread, > > x86_EXCEPTION_STATE32, > > (thread_state_t)&x86_exception_state32, > > > > &sc); > > > > > > // pull fault address from x86_exception_state32 > > // check that it is an expected address > > // make the page read-write > > // do cleanup > > > > return KERN_SUCCESS; > > } > > > > void *exception_handler(void *arg) { > > > > extern boolean_t exc_server(); > > mach_port_t port = (mach_port_t) arg; > > mach_msg_server(exc_server, 2048, port, 0); > > abort(); // without this GCC complains (it doesn't know that > mach_msg_server never returns) > > > > } > > > > // Does this need to be called on every thread? > > // I assume exception_port can be reused. Is this true? > > void setup_mach_exception_port() { > > > > static mach_port_t exception_port = MACH_PORT_NULL; > > mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, > &exception_port); > > mach_port_insert_right(mach_task_self(), exception_port, > exception_port, MACH_MSG_TYPE_MAKE_SEND); > > > > // using task_set_exception_ports causes LLDB to hang... > > // ...whenever it hits breakpoint outside of catch_exception_raise > > > > // > > task_set_exception_ports(mach_task_self(), EXC_MASK_BAD_ACCESS, > exception_port, EXCEPTION_DEFAULT, MACHINE_THREAD_STATE); > > thread_set_exception_ports(mach_thread_self(), EXC_MASK_BAD_ACCESS, > exception_port, EXCEPTION_DEFAULT, MACHINE_THREAD_STATE); > > pthread_t returned_thread; > > > > pthread_create(&returned_thread, NULL, exception_handler, (void*) > exception_port); > > } > > > > On Jul 8, 2013, at 12:41 PM, Greg Clayton <gclayton at apple.com> wrote: > > Not many people actually take over their own mach exception ports, so > this isn't something that hits a lot of people. It mainly hits the GC folks > and the Runtime (Java) folks that need to intercept NULL derefs. > > We do know about the issue and have plans to address this in the future. > > The solution that works right now is to take over EXC_BAD_ACCESS on the > _thread_ mach port. GDB and LLDB take over the task exception ports but we > leave the thread exception ports alone. The thread mach ports will get the > exception first, and if not handled, will pass it along to the task > exception ports. Depending on your architecture, you might easily be able > to do this, or it might be difficult. > > Greg Clayton > > > > > > -Heath Borders > > [email protected] > > Twitter: heathborders > > http://heath-tech.blogspot.com > > _______________________________________________ > > lldb-dev mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
