[lldb-dev] [patch] segfault and misbehavior on the process connect command.
Greg Clayton
gclayton at apple.com
Fri Mar 30 15:40:46 PDT 2012
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 root at farrell.cse.buffalo.edu:/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:gclayton at apple.com]
> 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 root at farrell.cse.buffalo.edu:/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 root at farrell.cse.buffalo.edu:/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
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> <lldb-commandobjectprocess-misbehavior.patch>
More information about the lldb-dev
mailing list