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@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 <ztur...@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 <amcca...@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@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@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 <vadi...@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 <vadi...@gmail.com> >>> wrote: >>> >>> Yes, the new build works! >>> >>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg <h...@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 <ztur...@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 <h...@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 <vadi...@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 <vadi...@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 <h...@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 < >>> ztur...@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 < >>> vadi...@gmail.com> >>> >> >>> > wrote: >>> >> >>> >> >>> >> >>> >> Thanks! >>> >> >>> >> >>> >> >>> >> Would anyone be so kind to commit that? >>> >> >>> >> >>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner >>> >> >>> >> <ztur...@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 < >>> vadi...@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 >>> >> >>> >>>> <vadi...@gmail.com> >>> >> >>> >>>> wrote: >>> >> >>> >>>>> >>> >> >>> >>>>> This seems to work: https://reviews.llvm.org/D27476 >>> >> >>> >>>>> >>> >> >>> >>>>> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg >>> >> >>> >>>>> <h...@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 >>> >> >>> >>>>>> <vadi...@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 >>> >> >>> >>>>>> > <h...@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@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
