Re: [lldb-dev] [llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

2016-08-01 Thread Michael Kuperstein via lldb-dev 
The crash dump looks like it's probably PR27071.
The bug was introduced in r261387 (which was merged into 3.8) and fixed in
r264465 (which apparently wasn't).

On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer <
llvm-...@lists.llvm.org> wrote:

> Hi,
> On the OpenMandriva side, x86_64 passes all checks. We're having some
> problems with other architectures though (see below):
>
> x86_64 succeeded, packages are here:
> https://abf.openmandriva.org/build_lists/76792
>
> i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
> using to build 3.9):
>
> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support 
> -Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security 
> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  
> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables 
> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 
> -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
> -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections 
> -fdata-sections -Os  -pipe -Wformat -Werror=format-security 
> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  
> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables 
> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 
> -D_FILE_OFFSET_BITS=64 -MD -MT 
> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF 
> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o 
> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c 
> ../lib/Support/PrettyStackTrace.cpp
> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t 
> llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong 
> MachineOperand accessor"' failed.
> #0 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
> (/usr/lib/libLLVMSupport.so.3.8+0x95075)
> #1 0xf4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
> #2 0xf4abbbf1 llvm::sys::RunSignalHandlers() 
> (/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
> #3 0xf4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
> #4 0xf7714d20  0xd20 __GI_raise
> #5 0xf7714d20
> #6 0xf7714d20 __GI_abort (+0xd20)
> #7 0xf4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
> #8 0xf46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
> #9 0xf464b126 (/lib/libc.so.6+0x21126)
> #10 0xf464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr 
> const*) const (/lib/libc.so.6+0x21162)
> #11 0xf65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
> #12 0xf667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
> #13 0xf61029dc 
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&) 
> (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
> #14 0xf6105002 llvm::FPPassManager::runOnFunction(llvm::Function&) 
> (/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
> #15 0xf60ab337 llvm::FPPassManager::runOnModule(llvm::Module&) 
> (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
> #16 0xf50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&) 
> (/usr/lib/libLLVMCore.so.3.8+0x19de6f)
> #17 0xf50d816b llvm::legacy::PassManager::run(llvm::Module&) 
> (/usr/lib/libLLVMCore.so.3.8+0x19e16b)
> #18 0xf50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions 
> const&, llvm::StringRef, llvm::Module*, clang::BackendAction, 
> llvm::raw_pwrite_stream*) (/usr/lib/libLLVMCore.so.3.8+0x19e57f)
> #19 0xf50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
> #20 0xf59fc72c clang::ParseAST(clang::Sema&, bool, bool) 
> (/usr/lib/libclangCodeGen.so.3.8+0x6972c)
> #21 0xf5b2cd85 clang::ASTFrontendAction::ExecuteAction() 
> (/usr/lib/libclangCodeGen.so.3.8+0x199d85)
> #22 0xf3b2b294 clang::CodeGenAction::ExecuteAction() 
> (/usr/lib/libclangParse.so.3.8+0x24294)
> #23 0xf582583e clang::FrontendAction::Execute() 
> (/usr/lib/libclangFrontend.so.3.8+0x8783e)
> #24 0xf5b2d3e1 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
> (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
> #25 0xf5826660 
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
> (/usr/lib/libclangFrontend.so.3.8+0x88660)
> #26 0xf58029e1 cc1_main(llvm::ArrayRef, char const*, 
> void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
> #27 0xf579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead)
> #28 0x08057178 __libc_start_main (/usr/bin/clang-3.8+0x8057178)
> #29 0x08052a9b _start (/usr/bin/clang-3.8+0x8052a9b)
> 0  libLLVMSupport.so.3.8   0xf4abd075 
> llvm::sys::PrintStackTrace(llvm::ra

Re: [lldb-dev] [Release-testers] [llvm-dev] [3.9 Release] Release Candidate 1 has been tagged

2016-08-01 Thread Diana Picus via lldb-dev 
We're having some failures on AArch64, filed
https://llvm.org/bugs/show_bug.cgi?id=28797 and investigating.

Diana

On 1 August 2016 at 10:18, Michael Kuperstein via Release-testers
 wrote:
> The crash dump looks like it's probably PR27071.
> The bug was introduced in r261387 (which was merged into 3.8) and fixed in
> r264465 (which apparently wasn't).
>
> On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer
>  wrote:
>>
>> Hi,
>> On the OpenMandriva side, x86_64 passes all checks. We're having some
>> problems with other architectures though (see below):
>>
>> x86_64 succeeded, packages are here:
>> https://abf.openmandriva.org/build_lists/76792
>>
>> i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
>> using to build 3.9):
>>
>> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support
>> -Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>> -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections
>> -fdata-sections -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -MD -MT
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
>> ../lib/Support/PrettyStackTrace.cpp
>> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
>> llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
>> MachineOperand accessor"' failed.
>> #0 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (/usr/lib/libLLVMSupport.so.3.8+0x95075)
>> #1 0xf4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
>> #2 0xf4abbbf1 llvm::sys::RunSignalHandlers()
>> (/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
>> #3 0xf4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
>> #4 0xf7714d20  0xd20 __GI_raise
>> #5 0xf7714d20
>> #6 0xf7714d20 __GI_abort (+0xd20)
>> #7 0xf4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
>> #8 0xf46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
>> #9 0xf464b126 (/lib/libc.so.6+0x21126)
>> #10 0xf464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr
>> const*) const (/lib/libc.so.6+0x21162)
>> #11 0xf65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
>> #12 0xf667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
>> #13 0xf61029dc
>> llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
>> #14 0xf6105002 llvm::FPPassManager::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
>> #15 0xf60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
>> #16 0xf50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19de6f)
>> #17 0xf50d816b llvm::legacy::PassManager::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e16b)
>> #18 0xf50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
>> clang::CodeGenOptions const&, clang::TargetOptions const&,
>> clang::LangOptions const&, llvm::StringRef, llvm::Module*,
>> clang::BackendAction, llvm::raw_pwrite_stream*)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e57f)
>> #19 0xf50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
>> #20 0xf59fc72c clang::ParseAST(clang::Sema&, bool, bool)
>> (/usr/lib/libclangCodeGen.so.3.8+0x6972c)
>> #21 0xf5b2cd85 clang::ASTFrontendAction::ExecuteAction()
>> (/usr/lib/libclangCodeGen.so.3.8+0x199d85)
>> #22 0xf3b2b294 clang::CodeGenAction::ExecuteAction()
>> (/usr/lib/libclangParse.so.3.8+0x24294)
>> #23 0xf582583e clang::FrontendAction::Execute()
>> (/usr/lib/libclangFrontend.so.3.8+0x8783e)
>> #24 0xf5b2d3e1
>> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
>> (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
>> #25 0xf5826660
>> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
>> (/usr/lib/libclangFrontend.so.3.8+0x88660)
>> #26 0xf58029e1 cc1_main(llvm::ArrayRef, char const*,
>> void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
>> #27 0xf579aead main (/usr/lib/libclangFrontendTool.

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

2016-08-01 Thread Hans Wennborg via lldb-dev 
On Sun, Jul 31, 2016 at 12:38 PM, Renato Golin  wrote:
> On 29 July 2016 at 23:57, Hans Wennborg via Release-testers
>  wrote:
>> There are still open merge requests and bugs, but I'd like to get the
>> real testing started to see where we're at.
>
> First wave of testing pass on ARM. Uploaded to the FTP server.
>
> Is it time to do the back-ports planned? I only have a very minor bug fix.

Sure!

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

2016-08-01 Thread Hans Wennborg via lldb-dev 
Ouch :-(

Well, if we ever do a 3.8.2, that should be included. +Tom in case
he's maintaining a list.

On Mon, Aug 1, 2016 at 12:18 AM, Michael Kuperstein  wrote:
> The crash dump looks like it's probably PR27071.
> The bug was introduced in r261387 (which was merged into 3.8) and fixed in
> r264465 (which apparently wasn't).
>
> On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer
>  wrote:
>>
>> Hi,
>> On the OpenMandriva side, x86_64 passes all checks. We're having some
>> problems with other architectures though (see below):
>>
>> x86_64 succeeded, packages are here:
>> https://abf.openmandriva.org/build_lists/76792
>>
>> i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
>> using to build 3.9):
>>
>> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support
>> -Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>> -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections
>> -fdata-sections -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -MD -MT
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
>> ../lib/Support/PrettyStackTrace.cpp
>> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
>> llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
>> MachineOperand accessor"' failed.
>> #0 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (/usr/lib/libLLVMSupport.so.3.8+0x95075)
>> #1 0xf4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
>> #2 0xf4abbbf1 llvm::sys::RunSignalHandlers()
>> (/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
>> #3 0xf4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
>> #4 0xf7714d20  0xd20 __GI_raise
>> #5 0xf7714d20
>> #6 0xf7714d20 __GI_abort (+0xd20)
>> #7 0xf4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
>> #8 0xf46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
>> #9 0xf464b126 (/lib/libc.so.6+0x21126)
>> #10 0xf464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr
>> const*) const (/lib/libc.so.6+0x21162)
>> #11 0xf65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
>> #12 0xf667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
>> #13 0xf61029dc
>> llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
>> #14 0xf6105002 llvm::FPPassManager::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
>> #15 0xf60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
>> #16 0xf50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19de6f)
>> #17 0xf50d816b llvm::legacy::PassManager::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e16b)
>> #18 0xf50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
>> clang::CodeGenOptions const&, clang::TargetOptions const&,
>> clang::LangOptions const&, llvm::StringRef, llvm::Module*,
>> clang::BackendAction, llvm::raw_pwrite_stream*)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e57f)
>> #19 0xf50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
>> #20 0xf59fc72c clang::ParseAST(clang::Sema&, bool, bool)
>> (/usr/lib/libclangCodeGen.so.3.8+0x6972c)
>> #21 0xf5b2cd85 clang::ASTFrontendAction::ExecuteAction()
>> (/usr/lib/libclangCodeGen.so.3.8+0x199d85)
>> #22 0xf3b2b294 clang::CodeGenAction::ExecuteAction()
>> (/usr/lib/libclangParse.so.3.8+0x24294)
>> #23 0xf582583e clang::FrontendAction::Execute()
>> (/usr/lib/libclangFrontend.so.3.8+0x8783e)
>> #24 0xf5b2d3e1
>> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
>> (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
>> #25 0xf5826660
>> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
>> (/usr/lib/libclangFrontend.so.3.8+0x88660)
>> #26 0xf58029e1 cc1_main(llvm::ArrayRef, char const*,
>> void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
>> #27 0xf579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead)
>> #28 0x080

Re: [lldb-dev] [3.9 Release] Release Candidate 1 has been tagged

2016-08-01 Thread Hans Wennborg via lldb-dev 
On Fri, Jul 29, 2016 at 3:57 PM, Hans Wennborg  wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.

Windows looked good. Binaries (sha1):
7f350f8a4903965ea9f3800f6d30a782ce86b0df  LLVM-3.9.0-rc1-win32.exe
0b40f11a8d6c1f1fb69dcf213916cf439bb326c0  LLVM-3.9.0-rc1-win64.exe
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Leaks from static variables

2016-08-01 Thread Vedant Kumar via lldb-dev 
Hi lldb-dev,

It looks like the debugger initializes static variables in llvm (see:
SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.

Does this cause memory leaks? I'd assumed that it's necessary to call
llvm_shutdown() somewhere to avoid this kind of leak.

Is there a buildbot I can check that tests an address-sanitized version of
lldb?

thanks,
vedant
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Leaks from static variables

2016-08-01 Thread Kate Stone via lldb-dev 
Greg Clayton will almost certainly want to weigh in here when he returns next 
week.  Generally speaking, we’ve had a long tail of issues that only show up 
during teardown that we’re avoiding.  Leaking resources that will be reclaimed 
by the OS when the process terminates is a non-issue.  If there are specific 
scenarios where a long-lived process leaks significant content that isn’t an 
effective cache for subsequent use, please outline how that manifests.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> It looks like the debugger initializes static variables in llvm (see:
> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
> 
> Does this cause memory leaks? I'd assumed that it's necessary to call
> llvm_shutdown() somewhere to avoid this kind of leak.
> 
> Is there a buildbot I can check that tests an address-sanitized version of
> lldb?
> 
> thanks,
> vedant
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Leaks from static variables

2016-08-01 Thread Zachary Turner via lldb-dev 
If you're linking against liblldb you can't rely on the os cleaning up
because you could unload liblldb before shutting down the process.

Also it's good practice to do explicit cleanup since its not always just a
simple matter of releasing resources, sometimes actual shutdown code needs
to be interspersed with the cleanup
On Mon, Aug 1, 2016 at 3:15 PM Kate Stone via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Greg Clayton will almost certainly want to weigh in here when he returns
> next week.  Generally speaking, we’ve had a long tail of issues that only
> show up during teardown that we’re avoiding.  Leaking resources that will
> be reclaimed by the OS when the process terminates is a non-issue.  If
> there are specific scenarios where a long-lived process leaks significant
> content that isn’t an effective cache for subsequent use, please outline
> how that manifests.
>
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools
>
> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> It looks like the debugger initializes static variables in llvm (see:
> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
>
> Does this cause memory leaks? I'd assumed that it's necessary to call
> llvm_shutdown() somewhere to avoid this kind of leak.
>
> Is there a buildbot I can check that tests an address-sanitized version of
> lldb?
>
> thanks,
> vedant
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Leaks from static variables

2016-08-01 Thread Kate Stone via lldb-dev 
Agreed that it’s a defect and should be addressed.  It mostly a question of 
prioritization relative to other work, so knowing about a specific scenario 
where this is a pressing issue would be valuable.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Aug 1, 2016, at 3:25 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> If you're linking against liblldb you can't rely on the os cleaning up 
> because you could unload liblldb before shutting down the process.
> 
> Also it's good practice to do explicit cleanup since its not always just a 
> simple matter of releasing resources, sometimes actual shutdown code needs to 
> be interspersed with the cleanup 
> On Mon, Aug 1, 2016 at 3:15 PM Kate Stone via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> Greg Clayton will almost certainly want to weigh in here when he returns next 
> week.  Generally speaking, we’ve had a long tail of issues that only show up 
> during teardown that we’re avoiding.  Leaking resources that will be 
> reclaimed by the OS when the process terminates is a non-issue.  If there are 
> specific scenarios where a long-lived process leaks significant content that 
> isn’t an effective cache for subsequent use, please outline how that 
> manifests.
> 
> Kate Stone k8st...@apple.com 
>  Xcode Low Level Tools
> 
> 
>> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
> 
>> Hi lldb-dev,
>> 
>> It looks like the debugger initializes static variables in llvm (see:
>> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
>> 
>> Does this cause memory leaks? I'd assumed that it's necessary to call
>> llvm_shutdown() somewhere to avoid this kind of leak.
>> 
>> Is there a buildbot I can check that tests an address-sanitized version of
>> lldb?
>> 
>> thanks,
>> vedant
> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev