[lldb-dev] Prebuilt binary for Windows

Wed Jan 11 13:14:32 PST 2017

BTW, here's the call stack at the point of failure.   I don't see anything
Python-related in it, so maybe it's some other CRT interaction.

liblldb!_invoke_watson(wchar_t * expression = 0x00000000 "", wchar_t *
function_name = 0x00000000 "", wchar_t * file_name = 0x00000000 "",
unsigned int line_number = 0, unsigned int reserved = 0)+0xe
liblldb!_invalid_parameter(wchar_t * expression = <Value unavailable
error>, wchar_t * function_name = <Value unavailable error>, wchar_t *
file_name = <Value unavailable error>, unsigned int line_number = <Value
unavailable error>, unsigned int reserved = <Value unavailable error>)+0x7a
liblldb!_invalid_parameter_noinfo(void)+0xc
liblldb!_read(int fh = 0n0, void * buffer = 0x05afbb50, unsigned int
buffer_size = 0x1000)+0x10a
liblldb!common_refill_and_read_nolock<char>(class __crt_stdio_stream stream
= class __crt_stdio_stream)+0x9f
liblldb!_fgetc_nolock(struct _iobuf * public_stream = 0x05af9c58)+0x2d
liblldb!__crt_char_traits<char>::getc_nolock+0x8
liblldb!common_fgets<char>(char * string = 0x019cf41c "b", int count =
0n256, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x81
liblldb!lldb_private::IOHandlerEditline::GetLine(class
std::basic_string<char,std::char_traits<char>,std::allocator<char> > * line
= 0x019cf548 "", bool * interrupted = 0x019cf537)+0xd6
liblldb!lldb_private::IOHandlerEditline::Run(void)+0x11a
liblldb!lldb_private::Debugger::ExecuteIOHandlers(void)+0x35
liblldb!lldb_private::CommandInterpreter::RunCommandInterpreter(bool
auto_handle_events = true, bool spawn_thread = false, class
lldb_private::CommandInterpreterRunOptions * options = 0x05af9ca8)+0x7e
liblldb!lldb::SBDebugger::RunCommandInterpreter(bool auto_handle_events =
true, bool spawn_thread = false, class lldb::SBCommandInterpreterRunOptions
* options = 0x019cf604, int * num_errors = 0x019cf630, bool *
quit_requested = 0x019cf603, bool * stopped_for_crash = 0x019cf60a)+0x43
lldb!Driver::MainLoop(void)+0x639
lldb!wmain(int argc = 0n3, wchar_t ** wargv = 0x01b28c90)+0x249
lldb!invoke_main+0x1d
lldb!__scrt_common_main_seh(void)+0xff
KERNEL32!BaseThreadInitThunk+0x24
ntdll_76f30000!__RtlUserThreadStart+0x2f
ntdll_76f30000!_RtlUserThreadStart+0x1b

On Wed, Jan 11, 2017 at 1:10 PM, Adrian McCarthy via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> I agree that linking to them dynamically is safer, but then you get into
> the deployment problem.  You do have to redistribute the DLLs for users
> using anything less than Windows 10.
>
> There are several options for doing that:  VCRedist, MSMs, MSUs, and
> app-local deployment.  They each have drawbacks.
>
> On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> If we do that though, we still get 2 copies of the CRT.  One for python
>> and one for LLDB.  While I *think* there is a strong enough API boundary in
>> how the application and Python access each others' data structures that it
>> doesn't matter, I'm not 100% sure without further research.  It seems safer
>> to link dynamically unless there is a strong reason not to.
>>
>> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy <amccarth at google.com>
>> wrote:
>>
>>> I was just reading up on this the other day.  Statically linking to the
>>> Universal CRT (and related libraries) *is* supported though it's not
>>> Microsoft's top recommendation.
>>>
>>> Initially, they said they weren't going to support app-local deployment,
>>> but they backed off on that, and it, too, is now supported.
>>>
>>> Some details here:  https://blogs.msdn.microsoft.
>>> com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>>>
>>>
>>> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
>>> lldb-dev at lists.llvm.org> wrote:
>>>
>>> The purpose of linking the CRT statically was to ensure that clang can
>>> run on systems that don't have the CRT already installed from some other
>>> app or by VS itself. As long as that is preserved, feel free to do whatever
>>> you need.
>>>
>>> I think we still want to link vcruntime140 statically and the C++
>>> runtime statically, for example.
>>>
>>> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
>>> lldb-dev at lists.llvm.org> wrote:
>>>
>>> Is static CRT even still supported / recommended when using the new
>>> Universal CRT?  My understanding is the new UCRT is considered a core
>>> windows component, so we don't ahve to distribute redistributables
>>> anymore.  Maybe I'm wrong about this.
>>>
>>> That said, I think we want dynamic regardless, otherwise we're back in
>>> the same boat of user having to compile Python, which is the exact thing
>>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>>> doesn't have to do anything and it just works.
>>>
>>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov <vadimcn at gmail.com>
>>> wrote:
>>>
>>> Sorry, just found another problem: the installed lldb crashes when given
>>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>>> exception 0xC0000409.
>>>
>>> It didn't happen with the one I've build locally, so I started
>>> digging... The difference seems to be that build_llvm_build_package.bat
>>> links CRT statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the
>>> dynamic CRT.
>>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>>> so LLDB ends up with two copies of it in the process, which is known to
>>> cause all sorts of trouble.
>>>
>>> Not sure what to do about this one, - you probably wanted static CRT to
>>> avoid having to install MSVC redistributable?
>>>
>>>
>>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov <vadimcn at gmail.com>
>>> wrote:
>>>
>>> Yes, the new build works!
>>>
>>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg <hans at chromium.org>
>>> wrote:
>>>
>>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>>> Please let me know if that works.
>>>
>>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner <zturner at google.com>
>>> wrote:
>>> > It sounds like the solution to the problem is to downgrade SWIG on the
>>> build
>>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>>> last
>>> > version before that is.  3.0.8, for example.
>>> >
>>> > At least there's a good workaround in the interim (i.e. setting
>>> PYTHONPATH)
>>> >
>>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg <hans at chromium.org>
>>> wrote:
>>> >>
>>> >> I'll do another snapshot maybe next week or the week after. You can
>>> >> also ping me if you want it sooner or later.
>>> >>
>>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>>> >> fully understand the problem here, but if there's some way to work
>>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>>> >> would be great.
>>> >>
>>> >> Thanks,
>>> >> Hans
>>> >>
>>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov <vadimcn at gmail.com>
>>> wrote:
>>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/i
>>> ssues/769
>>> >> >
>>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov <vadimcn at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> It worked!
>>> >> >>
>>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>>> >> >> (x86)\LLVM\lib\site-packages\lldb
>>> >> >> Without that, it couldn't find the _lldb module, so we are not
>>> quite
>>> >> >> out
>>> >> >> of the woods yet.
>>> >> >>
>>> >> >> When are you planning to make the next snapshot build?
>>> >> >> Thanks!
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg <hans at chromium.org>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Vadim, it looks like your change was committed in r291291, and
>>> I've
>>> >> >>> built a new snapshot today which includes it. Can you give it a
>>> try
>>> >> >>> and see if everything works?
>>> >> >>>
>>> >> >>> Cheers,
>>> >> >>> Hans
>>> >> >>>
>>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>>> zturner at google.com>
>>> >> >>> wrote:
>>> >> >>> > I will commit it, in the meantime can you request commit access
>>> so
>>> >> >>> > that
>>> >> >>> > any
>>> >> >>> > future patches you can commit?
>>> >> >>> >
>>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov <
>>> vadimcn at gmail.com>
>>> >> >>> > wrote:
>>> >> >>> >>
>>> >> >>> >> Thanks!
>>> >> >>> >>
>>> >> >>> >> Would anyone be so kind to commit that?
>>> >> >>> >>
>>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>>> >> >>> >> <zturner at google.com>
>>> >> >>> >> wrote:
>>> >> >>> >>>
>>> >> >>> >>> Sorry, a combination of national holidays and extended
>>> vacations
>>> >> >>> >>> happened
>>> >> >>> >>> and this fell off my radar.  lgtm
>>> >> >>> >>>
>>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>>> vadimcn at gmail.com>
>>> >> >>> >>> wrote:
>>> >> >>> >>>>
>>> >> >>> >>>> Zachary,
>>> >> >>> >>>> Can you please take a look at that change?
>>> >> >>> >>>> (https://reviews.llvm.org/D27476)
>>> >> >>> >>>>
>>> >> >>> >>>> It'll be sad if another snapshot build gets published with
>>> broken
>>> >> >>> >>>> lldb.
>>> >> >>> >>>> :(
>>> >> >>> >>>>
>>> >> >>> >>>>
>>> >> >>> >>>> On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>>> >> >>> >>>> <vadimcn at gmail.com>
>>> >> >>> >>>> wrote:
>>> >> >>> >>>>>
>>> >> >>> >>>>> This seems to work: https://reviews.llvm.org/D27476
>>> >> >>> >>>>>
>>> >> >>> >>>>> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>>> >> >>> >>>>> <hans at chromium.org>
>>> >> >>> >>>>> wrote:
>>> >> >>> >>>>>>
>>> >> >>> >>>>>> The only thing needed to build the installer should be
>>> having
>>> >> >>> >>>>>> NSIS
>>> >> >>> >>>>>> installed and building the "package" target generated by
>>> CMake.
>>> >> >>> >>>>>> The
>>> >> >>> >>>>>> other prerequisites are mostly for building the visual
>>> studio
>>> >> >>> >>>>>> clang-format plugin.
>>> >> >>> >>>>>>
>>> >> >>> >>>>>> Having said that, you don't even have to build the
>>> installer to
>>> >> >>> >>>>>> see
>>> >> >>> >>>>>> what goes in it. Just building the "install" target
>>> generated
>>> >> >>> >>>>>> by
>>> >> >>> >>>>>> CMake
>>> >> >>> >>>>>> will install the same set of files.
>>> >> >>> >>>>>>
>>> >> >>> >>>>>> I'm not sure how LLDB's cmake files are organized, but in
>>> the
>>> >> >>> >>>>>> end
>>> >> >>> >>>>>> what's required is invoking the install() command:
>>> >> >>> >>>>>> https://cmake.org/cmake/help/v3.0/command/install.html  In
>>> >> >>> >>>>>> LLVM,
>>> >> >>> >>>>>> this
>>> >> >>> >>>>>> is done automatically by macros such as add_llvm_executale,
>>> >> >>> >>>>>> etc.
>>> >> >>> >>>>>>
>>> >> >>> >>>>>> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>>> >> >>> >>>>>> <vadimcn at gmail.com>
>>> >> >>> >>>>>> wrote:
>>> >> >>> >>>>>> > Hi Hans,
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> > I'd love to help, but I don't have half the tools that
>>> >> >>> >>>>>> > build_llvm_package.bat requires installed on my
>>> machine.  My
>>> >> >>> >>>>>> > setup
>>> >> >>> >>>>>> > is to
>>> >> >>> >>>>>> > build llvm with msbuild.   Is it possible to build the
>>> >> >>> >>>>>> > installer
>>> >> >>> >>>>>> > this way
>>> >> >>> >>>>>> > too?
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> > Can you point me to the specific CMake source that
>>> determines
>>> >> >>> >>>>>> > what's
>>> >> >>> >>>>>> > included in the package?   At a glance, everything from
>>> >> >>> >>>>>> > %LLVM%/lib/site-packages is missing.
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> > Vadim
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg
>>> >> >>> >>>>>> > <hans at chromium.org>
>>> >> >>> >>>>>> > wrote:
>>> >> >>> >>>>>> >>
>>> >> >>> >>>>>> >> Is anyone working on this?
>>> >> >>> >>>>>> >>
>>> >> >>> >>>>>> >> I'm happy to include LLDB in the installer, but I'm
>>> really
>>> >> >>> >>>>>> >> not
>>> >> >>> >>>>>> >> the
>>> >> >>> >>>>>> >> best person to be debugging it.
>>> >> >>> >>>>>> >>
>>> >> >>> >>>>>> >> If more files need to be included in the install, that's
>>> >> >>> >>>>>> >> configured
>>> >> >>> >>>>>> >> in
>>> >> >>> >>>>>> >> the CMake files (what's installed by the 'install' build
>>> >> >>> >>>>>> >> target
>>> >> >>> >>>>>> >> is
>>> >> >>> >>>>>> >> also what ends up going into the installer). If it needs
>>> >> >>> >>>>>> >> more
>>> >> >>> >>>>>> >> build
>>> >> >>> >>>>>> >> flags, patches to build_llvm_package.bat are welsome.
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>> >
>>> >> >>> >>>>>
>>> >> >>> >>>>>
>>> >> >>> >>>>
>>> >> >>> >>
>>> >> >>> >
>>> >> >>
>>> >> >>
>>> >> >
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170111/fc54e32d/attachment-0001.html>