Viktor, I will apply this part of the patch and make sure it doesn't cause any problems in our test suite (I don't think it will) and I will check it in if nothing goes wrong!
Greg On Mar 30, 2012, at 3:36 PM, Viktor Kutuzov wrote: > Thank you, Greg! I got it. I'll continue working on this problem. > What do you think about the second part of the proposed patch, which is > >> The second problem is a misbehavior after an unsuccessful process connect >> command >> has been involved. The process connect leaves an 'undefined' process object >> if the command has >> been finished with an error. >> freebsd1# ./lldb /bin/ls >> Current executable set to '/bin/ls' (x86_64). >> (lldb) platform select remote-freebsd >> Host: FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC >> 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC >> (lldb) process connect localhost >> error: remote connections are not supported >> (lldb) process connect connect://localhost >> error: Process 0 is currently being debugged, kill the process before >> connecting. >> (lldb) exit >> The second error should not appear as far as I understood. This patch fixes >> it by deleting a process object. > > Does it provide a correct behaviour? > > Thanks. > Viktor. > > -----Original Message----- > From: Greg Clayton [mailto:[email protected]] > Sent: Friday, March 30, 2012 2:13 PM > To: Viktor Kutuzov > Cc: Lldb-dev > Subject: Re: [lldb-dev] [patch] segfault and misbehavior on the process > connect command. > Importance: High > > This patch is not what we want. You might be connecting to something that has > no executable. You don't need to specify an executable in order to connect to > something. Anything that is expecting an executable to be there should be > changed to be able to deal with no executable module. > > For example, on darwin we can do this: > > % > /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/debugserver > localhost:12345 -- /bin/ls > debugserver-185 for x86_64. > Listening to port 12345... > > > % lldb > (lldb) process connect --plugin gdb-remote connect://localhost:12345 Process > 40230 stopped > * thread #1: tid = 0x1e03, 0x00007fff694b9028 dyld _dyld_start, stop reason = > signal SIGSTOP > frame #0: 0x00007fff694b9028 dyld _dyld_start > dyld`_dyld_start: > -> 0x7fff694b9028: pushq $0 > 0x7fff694b902a: movq %rsp, %rbp > 0x7fff694b902d: andq $-16, %rsp > 0x7fff694b9031: movq 8(%rbp), %rdi > > > > So in this case, there was never an executable file that was specified. The > DynamicLoaderMacOSX figure things out and loaded the right executable and > dependent shared libraries. Which we can see if we resume the /bin/cat > process and then interrupt it since there are not shared libraries loaded > when sitting at the entry point: > > (lldb) c > Process 40230 resuming > (lldb) proc interrupt > Process 40230 stopped > * thread #1: tid = 0x1e03, 0x00007fff8cf39af2 libsystem_kernel.dylib read + > 10, stop reason = signal SIGSTOP, queue = com.apple.main-thread > frame #0: 0x00007fff8cf39af2 libsystem_kernel.dylib read + 10 > libsystem_kernel.dylib`read + 10: > -> 0x7fff8cf39af2: jae 0x7fff8cf39af9 ; read + 17 > 0x7fff8cf39af4: jmpq 1283 > 0x7fff8cf39af9: ret > 0x7fff8cf39afa: nop > (lldb) image list > [ 0] 920656A9-2536-33E4-A6DA-797978368A93 0x00000001098b8000 /bin/cat [ 1] > 7BEBB139-50BB-3112-947A-F4AA168F991C 0x00007fff90c86000 > /usr/lib/libSystem.B.dylib [ 2] B7757E2E-5A7D-362E-AB71-785FE79E1527 > 0x00007fff92f28000 /usr/lib/system/libcache.dylib [ 3] > A5B9778E-11C3-3F61-B740-1F2114E967FB 0x00007fff9202e000 > /usr/lib/system/libcommonCrypto.dylib > [ 4] 98ECD5F6-E85C-32A5-98CD-8911230CB66A 0x00007fff919d8000 > /usr/lib/system/libcompiler_rt.dylib > [ 5] 172B1985-F24A-34E9-8D8B-A2403C9A0399 0x00007fff93b7a000 > /usr/lib/system/libcopyfile.dylib [ 6] 712AAEAC-AD90-37F7-B71F-293FF8AE8723 > 0x00007fff87bfc000 /usr/lib/system/libdispatch.dylib [ 7] > 718A135F-6349-354A-85D5-430B128EFD57 0x00007fff8e8a1000 > /usr/lib/system/libdnsinfo.dylib [ 8] F1903B7A-D3FF-3390-909A-B24E09BAD1A5 > 0x00007fff92f30000 /usr/lib/system/libdyld.dylib [ 9] > 61EFED6A-A407-301E-B454-CD18314F0075 0x00007fff8e8a0000 > /usr/lib/system/libkeymgr.dylib [ 10] 39EF04F2-7F0C-3435-B785-BF283727FFBD > 0x00007fff8d752000 /usr/lib/system/liblaunch.dylib [ 11] > D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC 0x00007fff91d48000 > /usr/lib/system/libmacho.dylib [ 12] FF83AFF7-42B2-306E-90AF-D539C51A4542 > 0x00007fff923ed000 /usr/lib/system/libmathCommon.A.dylib > [ 13] 48656562-FF20-3B55-9F93-407ACA7341C0 0x00007fff8c601000 > /usr/lib/system/libquarantine.dylib > [ 14] 739E6C83-AA52-3C6C-A680-B37FE2888A04 0x00007fff93bc6000 > /usr/lib/system/libremovefile.dylib > [ 15] 8BCA214A-8992-34B2-A8B9-B74DEACA1869 0x00007fff89802000 > /usr/lib/system/libsystem_blocks.dylib > [ 16] FF69F06E-0904-3C08-A5EF-536FAFFFDC22 0x00007fff8b9c4000 > /usr/lib/system/libsystem_c.dylib [ 17] 7749128E-D0C5-3832-861C-BC9913F774FA > 0x00007fff8a6bf000 /usr/lib/system/libsystem_dnssd.dylib > [ 18] 35F90252-2AE1-32C5-8D34-782C614D9639 0x00007fff945c7000 > /usr/lib/system/libsystem_info.dylib > [ 19] 69F2F501-72D8-3B3B-8357-F4418B3E1348 0x00007fff8cf22000 > /usr/lib/system/libsystem_kernel.dylib > [ 20] 5DE7024E-1D2D-34A2-80F4-08326331A75B 0x00007fff90393000 > /usr/lib/system/libsystem_network.dylib > [ 21] A4D651E3-D1C6-3934-AD49-7A104FD14596 0x00007fff89bae000 > /usr/lib/system/libsystem_notify.dylib > [ 22] 5087ADAD-D34D-3844-9D04-AFF93CED3D92 0x00007fff93a38000 > /usr/lib/system/libsystem_sandbox.dylib > [ 23] C67B3B14-866C-314F-87FF-8025BEC2CAAC 0x00007fff90c44000 > /usr/lib/system/libunc.dylib [ 24] 1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231 > 0x00007fff93193000 /usr/lib/system/libunwind.dylib [ 25] > 26C05F31-E809-3B47-AF42-1460971E3AC3 0x00007fff8cee2000 > /usr/lib/system/libxpc.dylib > > > > I know the Linux and probably your FreeBSD plug-ins need to be modified to be > able to deal with not having an executable and then figuring out the > executable in the dynamic loader. > > Greg Clayton > > > On Mar 30, 2012, at 1:19 PM, Viktor Kutuzov wrote: > >> Hi everyone, >> >> here is a patch, which should fix two problems in lldb. >> >> The first problem is a segmentation fault on the 'process connect' command. >> The segfault occurs in lldb_private::Module::GetObjectFile in case no >> executable module was specified and/or loaded. There is a log to reproduce: >> >> freebsd1# ./lldb >> (lldb) platform select remote-freebsd >> Host: FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC >> 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC >> Hostname: localhost >> (lldb) process connect localhost >> Segmentation fault (core dumped) >> >> >> This is a stack trace for this case: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000008042c5344 in pthread_mutex_lock () from /lib/libthr.so.3 >> (gdb) bt >> #0 0x00000008042c5344 in pthread_mutex_lock () from /lib/libthr.so.3 >> #1 0x000000080149c7c5 in lldb_private::Mutex::Lock (mutex_ptr=0x18) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Host/common/Mutex.cpp:2 >> 12 >> #2 0x000000080149c791 in lldb_private::Mutex::Locker::Locker () at >> SmallPtrSet.h:159 >> #3 0x00000008013b0c40 in lldb_private::Module::GetObjectFile >> (this=0x0) at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Core/Module.cpp:945 >> #4 0x00000008023b5b1c in ProcessPOSIX::ProcessPOSIX (this=0x805f4b800, >> target=@0x808b8d100, listener=@0x805c94d90) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Plugins/Process/POSIX/P >> rocessPOSIX.cpp:76 >> #5 0x00000008023bd00a in ProcessFreeBSD::ProcessFreeBSD (this=0x805f4b800, >> target=@0x808b8d100, listener=@0x805c94d90) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Plugins/Process/FreeBSD >> /ProcessFreeBSD.cpp:122 >> #6 0x00000008023bcdb1 in ProcessFreeBSD::CreateInstance >> (target=@0x808b8d100, listener=@0x805c94d90, crash_file_path=0x0) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Plugins/Process/FreeBSD >> /ProcessFreeBSD.cpp:41 >> #7 0x0000000801702cb3 in lldb_private::Process::FindPlugin >> (target=@0x808b8d100, plugin_name=0x0, listener=@0x805c94d90, >> crash_file_path=0x0) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Target/Process.cpp:735 >> #8 0x000000080172a27e in lldb_private::Target::CreateProcess >> (this=0x808b8d100, listener=@0x805c94d90, plugin_name=0x0, crash_file=0x0) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Target/Target.cpp:154 >> #9 0x00000008012fde09 in CommandObjectProcessConnect::Execute >> (this=0x805c2fc00, command=@0x7fffffffbf10, result=@0x805d48140) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Commands/CommandObjectP >> rocess.cpp:873 #10 0x00000008014bdf20 in >> lldb_private::CommandObject::ExecuteWithOptions (this=0x805c2fc00, >> args=@0x7fffffffbf10, result=@0x805d48140) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Interpreter/CommandObje >> ct.cpp:281 >> #11 0x00000008014b2263 in lldb_private::CommandInterpreter::HandleCommand >> (this=0x805ca4200, command_line=0x80a41f198 "process connect localhost", >> add_to_history=true, result=@0x805d48140, >> override_context=0x0, repeat_on_empty_command=true, >> no_context_switching=false) at >> /usr/home/projects/llvm-lldb/tools/lldb/source/Interpreter/CommandInte >> rpreter.cpp:1540 >> #12 0x000000080124a7b5 in lldb::SBCommandInterpreter::HandleCommand >> (this=0x7fffffffc2f0, command_line=0x80a41f198 "process connect localhost", >> result=@0x7fffffffc2f8, add_to_history=true) >> at >> /usr/home/projects/llvm-lldb/tools/lldb/source/API/SBCommandInterprete >> r.cpp:97 >> #13 0x000000000040b666 in Driver::HandleIOEvent (this=0x7fffffffd718, >> event=@0x7fffffffc560) at >> /usr/home/projects/llvm-lldb/tools/lldb/tools/driver/Driver.cpp:980 >> #14 0x000000000040cc3e in Driver::MainLoop (this=0x7fffffffd718) at >> /usr/home/projects/llvm-lldb/tools/lldb/tools/driver/Driver.cpp:1406 >> #15 0x000000000040d28b in main (argc=1, argv=0x7fffffffd888, >> envp=0x7fffffffd898) at >> /usr/home/projects/llvm-lldb/tools/lldb/tools/driver/Driver.cpp:1540 >> >> The second problem is a misbehavior after an unseccessful process connect >> commend has been involved. The process connect leaves an 'undefined' process >> object if the command has been finished with an error. There is a log to >> reproduce: >> >> freebsd1# ./lldb /bin/ls >> Current executable set to '/bin/ls' (x86_64). >> (lldb) platform select remote-freebsd >> Host: FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC >> 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC >> (lldb) process connect localhost >> error: remote connections are not supported >> (lldb) process connect connect://localhost >> error: Process 0 is currently being debugged, kill the process before >> connecting. >> (lldb) exit >> The second error should not appear as far as I understood. This patch fixes >> it by deleting a process object. >> >> >> Would somebody review and apply this patch if it looks ok? >> Thanks. >> Viktor. >> <lldb-commandobjectprocess-crash.patch>_______________________________ >> ________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > <lldb-commandobjectprocess-misbehavior.patch> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
