[lldb-dev] Prebuilt binary for Windows

Wed Jan 11 13:19:39 PST 2017

Definitely seems CRT / Python related.  The call to fgets indicates that
it's doing something involving a FILE*.  It's probably a FILE* that refers
to a file created from within Python's copy of the CRT.  Another problem
that dynamic linking would solve.  Can you confirm that the problem does
not occur when LLDB links dynamically?

On Wed, Jan 11, 2017 at 1:14 PM Vadim Chugunov <vadimcn at gmail.com> wrote:

> 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/issues/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/9bfe9ee6/attachment-0001.html>