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 <vadi...@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@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/issues/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