The libunwind code isn't really set up to handle invalid stacks, since that's 
not it's main job.  If you're getting these asserts on normal healthy stacks it 
would be mildly interesting to follow up on why, but really we haven't dealt 
with this further because we are in the process of replacing the libunwind 
unwinder with one native to lldb that we can customize more to our liking.  
That shouldn't be too long showing up now. 

Jim

On Oct 5, 2010, at 4:01 AM, [email protected] wrote:

> The gdb  plugin does indeed get more info, when it works. Here's one of the 
> crashes i get:
> 
> Assertion failed: (Invalid memory access in the target), function get64, file 
> /Users/aep/lldb/source/Plugins/Process/Utility/libunwind/src/RemoteProcInfo.hpp,
>  line 531.
> 
> Program received signal SIGABRT, Aborted.
> 0x00000001018ff3d6 in __kill ()
> (gdb) bt
> #0  0x00000001018ff3d6 in __kill ()
> #1  0x000000010199f972 in abort ()
> #2  0x000000010198c9b4 in __assert_rtn ()
> #3  0x000000012e8ede1b in lldb_private::RemoteProcInfo::get64 
> (this=0x13ab3f840, addr=5076114402, arg=0x13b98f6a0) at RemoteProcInfo.hpp:531
> #4  0x000000012e8eeb78 in lldb_private::RemoteProcInfo::getP 
> (this=0x13ab3f840, addr=5076114402, arg=0x13b98f6a0) at RemoteProcInfo.hpp:672
> #5  0x000000012e8eec0f in 
> lldb_private::OtherAddressSpace<Pointer64<LittleEndian> >::getP 
> (this=0x138bd6780, addr=5076114402) at AddressSpace.hpp:303
> #6  0x000000012e8ff4e9 in 
> lldb_private::stepWithAssembly<lldb_private::OtherAddressSpace<Pointer64<LittleEndian>
>  >, lldb_private::Registers_x86_64> (addressspa...@0x138bd6780, 
> pc=4311875242, profile=0x138be5930, registe...@0x7fff5fbfc830) at 
> AssemblyInstructions.hpp:136
> #7  0x000000012e902eaf in 
> lldb_private::RemoteUnwindCursor<lldb_private::OtherAddressSpace<Pointer64<LittleEndian>
>  >, lldb_private::Registers_x86_64>::step (this=0x7fff5fbfc7e0) at 
> UnwindCursor.hpp:1209
> #8  0x000000012e8ded96 in unw_step (cursor=0x7fff5fbfc7e0) at 
> /Users/aep/lldb/source/Plugins/Process/Utility/libunwind/src/libuwind.cxx:69
> #9  0x000000012e8c5879 in UnwindLibUnwind::GetFrameCount (this=0x13b9903e0) 
> at /Users/aep/lldb/source/Plugins/Process/Utility/UnwindLibUnwind.cpp:42
> #10 0x000000012e7908d4 in lldb_private::StackFrameList::GetNumFrames 
> (this=0x138be58b0, can_create=true) at 
> /Users/aep/lldb/source/Target/StackFrameList.cpp:76
> #11 0x000000012e79f180 in lldb_private::Thread::GetStackFrameCount 
> (this=0x13b98f6a0) at /Users/aep/lldb/source/Target/Thread.cpp:835
> #12 0x000000012e8c88ff in lldb::SBThread::GetNumFrames (this=0x7fff5fbfd090) 
> at /Users/aep/lldb/source/API/SBThread.cpp:355
> #13 0x000000012e32cc6c in Debugger::Internal::LLDBEngine::updateThreads 
> (this=0x137a402f0) at lldb/lldbengine.cpp:250
> 
> 
> where updateThreads is:
> 
> SBThread thr = process->GetThreadAtIndex(0);
> thr.GetNumFrames();
> 
> process is currently stopped ( Stop() was called, then  a ProcessEvent has 
> been fired through the EventListener and GetState() returns eStateStopped )
> 
> 
> 
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Jim Ingham
Apple Developer Tools




_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to