profile
viewpoint

vadimcn/cargo-pgo 21

Supercharge you Rust programs!

vadimcn/llvm 11

Temporary fork of LLVM for Rust

vadimcn/compiler-rt 3

Mirror of official compiler-rt git repository located at http://llvm.org/git/compiler-rt. Updated hourly.

vadimcn/rust 2

a safe, concurrent, practical language

vadimcn/awesome-rust 1

A curated list of Rust code and resources.

vadimcn/clang 0

Mirror of official clang git repository located at http://llvm.org/git/clang. Updated every five minutes.

vadimcn/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

issue commentvadimcn/vscode-lldb

[question] How to debug unit test of rust?

That link comes from your rust language extension (probably rust-analyzer), not from codelldb.

You can debug tests using codelldb's cargo integration. Alternatively, you can try using "cargo runner" method, however that will cause all cargo run/test/bench commands to execute your program under debugger.

hh9527

comment created time in an hour

issue commentvadimcn/vscode-lldb

[Rust] When stop the debugging, the plugin will not kill the program if the program is in the dead loop

Instructions are in the bug template. You'll need to add "lldb.verboseLogging": true into your workspace settings. The log will be in VSCode's "LLDB" output channel. Thanks!

w93163red

comment created time in 4 days

pull request commentswig/swig

Support stable Python ABI

@vadz: Sure, either way works for me.

vadimcn

comment created time in 5 days

issue commentvadimcn/vscode-lldb

[Rust] When stop the debugging, the plugin will not kill the program if the program is in the dead loop

Could you provide a verbose log of such a debug session?

w93163red

comment created time in 6 days

issue commentvadimcn/vscode-lldb

[Rust] When stop the debugging, the plugin will not kill the program if the program is in the dead loop

It is supposed to terminate all processes it launches. And it does that for me.
Could you please be more specific about your scenario?

w93163red

comment created time in 6 days

pull request commentrust-lang/rust

Optimize catch_unwind to match C++ try/catch

IMO, the "proper fix" would be to remove LLVM's assumption about what symbol the resume instruction resolves to.

At this point I think we are spending way too much effort on this, when the proper (and officially supported by MinGW) solution is to just link against libgcc_s_dw2-1.dll. How much of a breaking change would it be for Rust executables for the windows-gnu targets to once again start depending on libgcc_s_dw2-1.dll?

You'll need to ask users. Some people were pretty adamant about having to distribute this an dll with their programs, as I recall.

I think that in order to decide which approach should be implemented, Rust core team needs to decide how important it is for rustc toolchain to be independent from GCC.
Back when I wrote this code, I thought the desired final outcome was to have a 100% Rust toolchain, or. at least, one that depended only on LLVM libraries and tools. But now I've been out of this for a while, don't know which way the wind is blowing these days...

Mark-Simulacrum

comment created time in 7 days

pull request commentvadimcn/vscode-lldb

Add settings for default values of throw/catch/panic breakpoints

If you just want to turn them off, you can use "sourceLanguages": [].

dirondin

comment created time in 9 days

issue commentvadimcn/vscode-lldb

[rust] allow specify features in args

"cwd" is for setting working directory of the debuggee. You need something like "cargo": { "args": [ "--maniest-path=${workspaceFolder}/a/b/Cargo.toml", ... ]

w93163red

comment created time in 10 days

issue commentvadimcn/vscode-lldb

[rust] allow specify features in args

Try "--features=sdk_test,replace-by-rec,use-btree"

w93163red

comment created time in 10 days

issue commentvadimcn/vscode-lldb

FreeBSD support?

@wolfspider, did you mean to post to this thread? I'm not quite sure what regex'es have to do with FreeBSD...

davidchisnall

comment created time in 10 days

issue commentvadimcn/vscode-lldb

FreeBSD support?

Thanks for looking into it, but It's not that simple... I also build a custom version of LLDB, maximally stripped of dependencies, with Rust support and some bug fixes. Which also requires a special build of SWIG, which makes it possible to bind to different versions of Python.

But even if all that were solved, there's still the question of building and testing it. In my experience, platform ports tend to break quite often unless tested by CI.

davidchisnall

comment created time in 11 days

GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent

issue commentvadimcn/vscode-lldb

FreeBSD support?

Well, yes, it's the lack of binaries. I don't have a machine or a docker image to build them and I don't have a machine to test.

davidchisnall

comment created time in 11 days

issue commentvadimcn/vscode-lldb

Filter real Rust panic!() from those that are caught with catch_unwind()

I expect that getting this to work reliably on all platforms will be challenging... not something I want to invest my time into right now.
But since you only need this to work in your particular setup, you could probably create Python script that does what you want and attach it as a callback to a breakpoint. Have it return true if you want to stop and false otherwise.

Veetaha

comment created time in 12 days

pull request commentvadimcn/vscode-lldb

Add settings for default values of throw/catch/panic breakpoints

Sorry, but I'd rather not. I try to keep the number of config settings at a reasonable level, there's probably too many already. This feature is not an obvious must-have, IMO.

dirondin

comment created time in 12 days

issue commentvadimcn/vscode-lldb

FreeBSD support?

Sorry, I've no near-future plans for FreeBSD port.

davidchisnall

comment created time in 12 days

issue commentvadimcn/vscode-lldb

Source Path wildcard support not working

I'm sure at one point glob support was working,

That's true, however that was a hack on top of that lldb itself provides, and later it turned out that my approach created problems in other places, so I decided to drop this feature in favor of lldb's native support.
There seems to be a conceptual problem with globs in the source map, because in some circumstances the debugger needs to perform a reverse mapping.

jasonwilliams

comment created time in 12 days

pull request commentvadimcn/vscode-lldb

Add settings for default values of throw/catch/panic breakpoints

Thanks, but what's be motivation for this? VSCode already persists these settings.

dirondin

comment created time in 17 days

issue commentvadimcn/vscode-lldb

Filter real Rust panic!() from those that are caught with catch_unwind()

Do you have any ideas on how to implement it? Right now breaking on panic is implemented simply as a function breakpoint on rust_panic (which is called early during a panic). I don't know of a similarly easy way to break on "unhandled panics".
Please keep in mind that users will expect this to work with all panic unwind implementations, of which Rust currently has at least four: DWARF, SjLj, SEH, SEH64, depending on target platform.

Veetaha

comment created time in 21 days

GollumEvent

issue commentvadimcn/vscode-lldb

Step in and stop on entry debugging issues

You'll need to add this line into your launch configuration: "initCommands": ["settings set target.process.thread.step-avoid-regexp ''"]. Normally it's set to ^std:: and LLDB uses this regex to filter step-in targets.

D-Roberts

comment created time in 25 days

issue commentvadimcn/vscode-lldb

Windows errors when debugging rust program

Does c:\Users\user.vscode\extensions\vadimcn.vscode-lldb-1.4.5\lldb\bin\liblldb.dll file exist?
If not, this looks like an incomplete package download/extraction. Just uninstall/reinstall the extension.
I probably need to do more package validation....

Aorimn

comment created time in a month

issue commentvadimcn/vscode-lldb

LLDB plugin crashes when launching app without debugging (CTRL+F5)

3221226505 = 0xC0000409, which is a Windows error code for "stack overflow". Unfortunately, the error log provides no clues as to where or why :(.

rucoder

comment created time in a month

issue commentvadimcn/vscode-lldb

is it impossible to display a contents of 'self' in Rust

This is weird... The extension bundles its own version of liblldb and that's what it loads by default (with full path). Unless you overrode it via lldb.library config setting, it shouldn't be using external lldb.
I've no idea what was up with self: as far as I know, in Rust ABI it isn't different from any other function parameter.

Please note that the -msvc target uses MS PDB debug info format, not DWARF. At the moment there's no Rust-specific support for PDB whatsoever, so LLDB treats Rust binaries the same as C/C++. In practice, this works out okay for some data types, but not for others, especially Rust enums. For optimal debugging experience, I would suggest using the x86_64-pc-windows-gnu target, if possible.

rucoder

comment created time in a month

issue commentvadimcn/vscode-lldb

is it impossible to display a contents of 'self' in Rust

Which target are you building for?

rucoder

comment created time in a month

issue commentvadimcn/vscode-lldb

Feature Request: Warn on unverified breakpoints

They should also be marked hollow

Are you saying that unresolved breakpoints are not appearing hollow? They should, after the launch.

Coder-256

comment created time in a month

issue commentvadimcn/vscode-lldb

Debugger switches to disassembly when stepping into function even though debug information should be available

Deciding line number debug info is not an easy task.
You can try to have rustc emit assembly file(s) find your function and check if it has .file and .line directives in the prologue.

Which rust version are you using? Can you try upgrading/downgrading? Does this happen with all finctions?

bluenote10

comment created time in a month

issue commentvadimcn/vscode-lldb

Debugger switches to disassembly when stepping into function even though debug information should be available

Assuming you are not compiling in --release mode, there's probably some problem with debug info emitted by the compiler. For example, it might be missing line number info for some code range in the function prologue. It's also possible, though less likely, that debug info is ok, but LLDB is not interpreting it correctly. In either case, I don't think I can do much about it, sorry.

bluenote10

comment created time in a month

issue commentvadimcn/vscode-lldb

Debugger only shows dissassembly, when debugging rust

@Baardi: ah, it's a 32-bit target. 64-bit LLDB has a problem with that for some reason. Can you use the x86_64-pc-windows-msvc target instead?

Baardi

comment created time in a month

issue commentvadimcn/vscode-lldb

dylib not loaded through debugger

Does dyld print any useful info if you set DYLD_PRINT_LIBRARIES/DYLD_PRINT_WARNINGS? Otherwise, try setting DYLD_LIBRARY_PATH

SimpsonGSD

comment created time in a month

issue commentvadimcn/vscode-lldb

dylib not loaded through debugger

Are you setting the working directory for your program?
You can try to debug by setting DYLD_... environment variables as described here.

SimpsonGSD

comment created time in a month

issue commentvadimcn/vscode-lldb

Debugger only shows dissassembly, when debugging rust

@bluenote10, your case is different: the call stack shows that your test failed with a panic. You could set up a source map to be able to see the source of libstd's panic handler... but that's probably not what you want. Just click on the last call stack frame that has source file name/line number next to it.

If you are not interested in seeing disassembly at all, consider turning it off.

Baardi

comment created time in a month

PR closed vadimcn/vscode-lldb

Fix `time.clock()` for Python 3.8

time.clock() has been deprecated since Python 3.3 and removed in 3.8. It should be replaced by either time.perf_counter() or time.process_time().

+2 -2

1 comment

1 changed file

ducakar

pr closed time in a month

pull request commentvadimcn/vscode-lldb

Fix `time.clock()` for Python 3.8

Classic adapter will be retired in the next version, so there's no point in fixing it.

ducakar

comment created time in a month

PR closed vadimcn/vscode-lldb

use ManuallyDrop for enum variants

In rust nightly, the clippy directive no longer exists. ManuallyDrop should be used instead.

+4 -6

1 comment

1 changed file

vhdirk

pr closed time in a month

pull request commentvadimcn/vscode-lldb

use ManuallyDrop for enum variants

Thanks for the PR, but I've decided to go with the MaybeUninit approach.

vhdirk

comment created time in a month

issue commentvadimcn/vscode-lldb

Debugger only shows dissassembly, when debugging rust

Which Rust version and which target you are building for? Are you building with dev (i.e. non-release) profile? Can you provide a repro case?

Baardi

comment created time in a month

issue openedhtmlpreview/htmlpreview.github.com

Doesn't work for https://github.com/google/glog/blob/master/doc/glog.html

https://htmlpreview.github.io/?https://github.com/google/glog/blob/master/doc/glog.html

created time in a month

issue commentvadimcn/vscode-lldb

debugger doesn't work with native lldb adapter type

Can you please add "lldb.adapterEnv": { "RUST_BACKTRACE": "1" } to your workspace settings and post the resulting debugger log again?

However, var,[10] expression doesn't work with classic adapter.

Classic adapter does not support such formatting.

Is there any way to see the multiple elements of the array with hex or decimal format by user setting?

Not currently. However you can switch the default display format to hex (via LLDB: Display Format... command).

brayden-jo

comment created time in 2 months

issue commentvadimcn/vscode-lldb

debugger freezes and massive memory leak when debug regular c++ project.

Still not sure about the cause, but I made a speculative fix which might have fixed this in 1.4.5. Can you please check?

XNephila

comment created time in 2 months

issue commentvadimcn/vscode-lldb

How do I hide the Static, Global, Register variable dropdowns?

You can't hide them, sorry.

infixint943

comment created time in 2 months

issue commentvadimcn/vscode-lldb

The debugger exited without completing startup handshake

Can you please check the size of ~/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/lldb/lib/liblldb.dylib? It should be around 83MB. If it's smaller, try re-installing the extension.

z-x-z

comment created time in 2 months

issue commentvadimcn/vscode-lldb

VSCode does not hit breakpoints when source path contains symlinks.

@almindor, are you debugging a Rust program? The problems seems to be in the Rust compiler: it seems to normalize source file paths before encoding them in the debug info. If I add "sourceMap": {"<original path>: "<symlinked path>"} into my launch config, breakpoints do work.

Simsys

comment created time in 2 months

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha b10b06eedd9568c1c2dc2afb74f631d0f072d1fb

Fix Url handler.

view details

Vadim Chugunov

commit sha baf0ceea048879ad7ee377d533f9dc790b1b930e

Version 1.4.4

view details

Vadim Chugunov

commit sha 20d46ef6d31f8226902c0c820fe10c2d3587ca76

Python version parsing.

view details

Vadim Chugunov

commit sha 9eff046110300f334ce2fe2aea8e5b03161f44ea

Document relativePathBase.

view details

Vadim Chugunov

commit sha 05f568987270cd8393764e5c63d26768d19a61ef

Use schemafy 0.5.0

view details

Vadim Chugunov

commit sha aa5d084e34065853113c439df0560050a718a80d

Propagate log level to Python.

view details

Vadim Chugunov

commit sha 01ad03217f6eafeb1375d2bc46891e6c1c939be5

Use CMakeCache

view details

Vadim Chugunov

commit sha 03dd3ed89617886ecac3f212810cdea79e9e887c

Remove type callbacks, becasue they weren't used.

view details

Vadim Chugunov

commit sha d725bb056eccbdf6ff8b062cfde9f9024f812196

rr 5.3.0 has been released

view details

Vadim Chugunov

commit sha 54d31ae7b255b574f87473e2e6fbdf790398d8f1

Update issue template.

view details

Vadim Chugunov

commit sha 0e666a9da072d3218ec50d710afc9a7695065c8e

Use LLDB build 1152 (v9.0.1)

view details

Vadim Chugunov

commit sha 92f7f27f6371cb6f2623718c0387ac0e99275b4c

Version 1.4.5

view details

push time in 2 months

created tagvadimcn/vscode-lldb

tagv1.4.5

A native debugger extension for VSCode based on LLDB

created time in 2 months

issue commentvadimcn/vscode-lldb

debugger freezes and massive memory leak when debug regular c++ project.

I've compiled your project, but cannot reproduce the hang or the memory leak :-\

XNephila

comment created time in 2 months

PR closed vadimcn/vscode-lldb

Update issue templates
+16 -0

0 comment

1 changed file

vadimcn

pr closed time in 2 months

push eventvadimcn/vscode-lldb

vadimcn

commit sha b7139b76c1deeb05fe465adf89987c8d24645c80

Update issue templates

view details

push time in 2 months

PR opened vadimcn/vscode-lldb

Update issue templates
+16 -0

0 comment

1 changed file

pr created time in 2 months

create barnchvadimcn/vscode-lldb

branch : templates

created branch time in 2 months

Pull request review commentswig/swig

Support stable Python ABI

 <H3><a name="Python_3_stable_abi">32.12.5 Python 3 Stable ABI</a></H3>  <p> However, this compatibility comes at a performance cost: some Python API macros are not available in this mode,  so SWIG must use function versions of the same.  For example, instead of <tt>PyTuple_GET_ITEM</tt> SWIG has to use <tt>PyTuple_GetItem</tt>.-Unlike the macro, <tt>PyTuple_GetItem</tt> cannot be inlined, so it will execute slower.+Unlike the macro, <tt>PyTuple_GetItem</tt> cannot be inlined, so it will execute slower. Also, please note that <tt>-py3-stable-abi</tt> is not compatible +with some of the other SWIG Python options such as <tt>-builtin</tt> or <tt>-fastproxy</tt>. </p> -<p> -Also, please note that <tt>-py3-stable-abi</tt> is not compatible with some of the other SWIG Python options such as <tt>-builtin</tt> or <tt>-fastproxy</tt>.+<H4>Linkage</H4>+<p>+Version-independent modules have special requirements when it comes to linking: they should not depend on the versioned Python dynamic library, otherwise the dynamic +linker will refuse to load them into a different version of Python runtime.  +Here's <a href="https://www.python.org/dev/peps/pep-0384/#linkage">PEP 384 guidance on linkage</a>.  In practical terms, it mean this:+<ul>+  <li>On Windows, link to the version-independent <tt>python3.lib</tt>.</li>+  <li>On Linux, don't link to <tt>libpython</tt> at all, leaving all imported Python symbols unresolved.  Make sure that unresolved symbols are not disallowed via "<tt>-z defs</tt>" linker option.</li>+  <li>On MacOS, also don't link to <tt>libpython</tt>, but you will need to explicitly allow unresolved symbols via "<tt>-undefined dynamic_lookup</tt>" option.  +      If you re not involing linker directly, you may need to instruct your compiler to do so. For example, GCC-compatible complers will need this flag:

thanks!

vadimcn

comment created time in 2 months

push eventvadimcn/swig

Vadim Chugunov

commit sha 1a908af9eb0c724d919013e57c01f0ee00660390

Document linkage requirements.

view details

push time in 2 months

pull request commentswig/swig

Support stable Python ABI

Okay, I've added a note on linkage. I think that add_dll_directory() is a Python 3.8 issue, not something specific to stable ABI or even to SWIG.

vadimcn

comment created time in 2 months

push eventvadimcn/swig

Vadim Chugunov

commit sha d888e4a68bd8b9a287f7e0af1f5c350d2255c4c5

Check Py_LIMITED_API value, if predefined.

view details

Vadim Chugunov

commit sha 291523c440fd977af97fa4a93384b3a8bfff4fb4

Document linkage requirements.

view details

push time in 2 months

push eventvadimcn/swig

Daniel Emminizer

commit sha 9fc57f47bdf908c6f9546548acef8052c5a1bb89

Fix error in generated code for Python in MSVC 2019. Visual Studio 2019 release builds: error C4703: potentially uninitialized local pointer variable 'p' used

view details

William S Fulton

commit sha 719eea090dd48e8866efc4d32b604ff35c7e0263

Improve error handling calling PyObject_SetAttr Less obscure error when setting 'this' on the SWIG proxy object attempting to override __setattr__ in C++ (swig-user mailing list query 19 Aug 2019).

view details

William S Fulton

commit sha 4c86ed4980d0f277dc4b9194fa9178d7881a669c

Macros wrapped as constants documentation improvements. Closes #1618

view details

William S Fulton

commit sha 97a107ed256b308d690343ae633453ae18a1efb1

Merge pull request #1619 from emminizer/fix-msvc2019-python Fix error in generated code for Python in MSVC 2019.

view details

Karl Wette

commit sha e4c38f0f67a74ca146986d9e8df5efd439667139

Octave: remove use of ppa:kwwette/octaves

view details

William S Fulton

commit sha cb5d7398b562e77436e5766fb17a40bfe8c4f973

Fix bug in Python builtin support for keyword args The fix is when using kwargs feature or -keyword. The fix is in the argument error checking when wrapping zero argument constructors only. Supplied keyword args were silently ignored. Issue #1595

view details

William S Fulton

commit sha 6fb345feb26d331814ce7111682a4b3b809c6d16

'out' or 'ref' usage in a cstype typemap in directors 'out' / 'ref' was not always stripped out in parts of the director code generation. Issue #1628

view details

William S Fulton

commit sha 18b2dcd2220b13296e12bb729741542750faab31

C# 'out' or 'ref' removal improvements in director typemaps. - Add support to DOH Replace for not replacing inside C comments - Fix removing 'out' or 'ref' when these are present in C comments in cstype typemaps. Closes #1628

view details

William S Fulton

commit sha 3d98179fd3b38d86e7f689dd7e19f11b53449a2f

Temporarily remove broken Appveyor Python3 testing

view details

William S Fulton

commit sha 8122929ba95c34132b9cb9c5cbeaf4eeb7c300e0

Improve .NET docs. Add minimum .NET version required Issue #1623 [skip-ci]

view details

William S Fulton

commit sha 66752cde4858a780fecba47793f99ba49ce8b15e

Remove Travis osx java testing Removed until doxygen testing is ported to something that doesn't use com.sun.javadoc which was remoed in jdk 13

view details

William S Fulton

commit sha aa47b4c438421595b2764044b54502ad378cd7e5

Fix some C++11 identifiers with special meaning parsing problems Fix parsing of C++11 identifiers with special meaning (final and override) when they are used as part of the scope name of an identifier, such as a namespace name. Closes #1679

view details

Vadim Zeitlin

commit sha fe6968e5e2dfc365ca009e9bcd2d4ed3f6d8d6a6

Reuse existing variable in CommentParser code used in Java tests No real changes, just a tiny simplification.

view details

Vadim Zeitlin

commit sha 5a8875ca9da7046b2b3b7fea3f1e056f289c5be1

Don't crash if unexpected comment is found in Java Doxygen tests Don't pass null pointer to BufferedWriter.write(), as this results in NullPointerException.

view details

Vadim Zeitlin

commit sha 66a78261924174791a4952d05b58d52c16a36a57

Rewrite Doxygen unit tests for Java using Java 9 API In particular, do not use com.sun.javadoc deprecated since Java 9 and finally removed in Java 13, to allow the tests to run under modern JRE. They don't run under Java 8 and earlier any more, but this shouldn't be a huge problem nowadays and as SWIG output is independent from the Java version used, it's enough to test it with modern Java versions. Note that the tests themselves were changed only in the most minimal way, to adapt them to the new way of running javadoc (which is now also integrated into CommentParser itself instead of being duplicated in every test).

view details

Vadim Zeitlin

commit sha a271785f1a77a17c5c436bae4d1f9407b720db44

Revert "Remove Travis osx java testing" This reverts commit 66752cde4858a780fecba47793f99ba49ce8b15e as Doxygen tests do pass with Java 13 now.

view details

Vadim Zeitlin

commit sha b52af4039856cce3dc924d970572350b85f2652d

Disable Doxygen tests when using Java 8 or older Check Java version in configure and define SKIP_DOXYGEN_TEST_CASES if it's less than 9, which is required by the new implementation of CommentParser used in the Doxygen tests.

view details

Vadim Zeitlin

commit sha e7d0533a6feebbfce9813998f9d059a99aaed6dd

Quote JAVAC expansion in configure to deal with spaces This avoids errors about unknown Java version format when JAVAC is in a path with spaces in it (as is often the case under Windows).

view details

Vadim Chugunov

commit sha 363f8d99f0b3871bc2f420cb35276f51c6bbdd4b

Support stable Python ABI.

view details

Vadim Chugunov

commit sha cdaca1205539b482afdb2373a9902f605cb079b6

Document linkage.

view details

push time in 2 months

issue commentvadimcn/vscode-lldb

Fatal Python error: initfsencoding: unable to load the file system codec

That's good to know, thanks!

hansieodendaal

comment created time in 2 months

pull request commentswig/swig

Support stable Python ABI

so the generated module is still bound to this particular Python version. And there doesn't seem to be any libpython3.so at all, so how do you handle this?

Ah, that: you need to build the extension dylib without linking to libpython3.X (except on Windows). The dynamic linker will still be able to resolve needed symbols as long as there's any suitable Python runtime in the process.

  • On Linux make sure that unresolved symbols in the output dylib are not forbidden via -z,defs.
  • On MacOS, link with -undefined dynamic_lookup to achieve the same effect.
  • On Windows, link to python3.dll.

First of all, Py_LIMITED_API must be defined as at least 0x03040000

It is defined, here. Are you including Python.h before SWIG-generated code includes it?

vadimcn

comment created time in 2 months

push eventvadimcn/swig

William S Fulton

commit sha 6fb345feb26d331814ce7111682a4b3b809c6d16

'out' or 'ref' usage in a cstype typemap in directors 'out' / 'ref' was not always stripped out in parts of the director code generation. Issue #1628

view details

William S Fulton

commit sha 18b2dcd2220b13296e12bb729741542750faab31

C# 'out' or 'ref' removal improvements in director typemaps. - Add support to DOH Replace for not replacing inside C comments - Fix removing 'out' or 'ref' when these are present in C comments in cstype typemaps. Closes #1628

view details

William S Fulton

commit sha 3d98179fd3b38d86e7f689dd7e19f11b53449a2f

Temporarily remove broken Appveyor Python3 testing

view details

William S Fulton

commit sha 8122929ba95c34132b9cb9c5cbeaf4eeb7c300e0

Improve .NET docs. Add minimum .NET version required Issue #1623 [skip-ci]

view details

William S Fulton

commit sha 66752cde4858a780fecba47793f99ba49ce8b15e

Remove Travis osx java testing Removed until doxygen testing is ported to something that doesn't use com.sun.javadoc which was remoed in jdk 13

view details

William S Fulton

commit sha aa47b4c438421595b2764044b54502ad378cd7e5

Fix some C++11 identifiers with special meaning parsing problems Fix parsing of C++11 identifiers with special meaning (final and override) when they are used as part of the scope name of an identifier, such as a namespace name. Closes #1679

view details

Vadim Zeitlin

commit sha fe6968e5e2dfc365ca009e9bcd2d4ed3f6d8d6a6

Reuse existing variable in CommentParser code used in Java tests No real changes, just a tiny simplification.

view details

Vadim Zeitlin

commit sha 5a8875ca9da7046b2b3b7fea3f1e056f289c5be1

Don't crash if unexpected comment is found in Java Doxygen tests Don't pass null pointer to BufferedWriter.write(), as this results in NullPointerException.

view details

Vadim Zeitlin

commit sha 66a78261924174791a4952d05b58d52c16a36a57

Rewrite Doxygen unit tests for Java using Java 9 API In particular, do not use com.sun.javadoc deprecated since Java 9 and finally removed in Java 13, to allow the tests to run under modern JRE. They don't run under Java 8 and earlier any more, but this shouldn't be a huge problem nowadays and as SWIG output is independent from the Java version used, it's enough to test it with modern Java versions. Note that the tests themselves were changed only in the most minimal way, to adapt them to the new way of running javadoc (which is now also integrated into CommentParser itself instead of being duplicated in every test).

view details

Vadim Zeitlin

commit sha a271785f1a77a17c5c436bae4d1f9407b720db44

Revert "Remove Travis osx java testing" This reverts commit 66752cde4858a780fecba47793f99ba49ce8b15e as Doxygen tests do pass with Java 13 now.

view details

Vadim Zeitlin

commit sha b52af4039856cce3dc924d970572350b85f2652d

Disable Doxygen tests when using Java 8 or older Check Java version in configure and define SKIP_DOXYGEN_TEST_CASES if it's less than 9, which is required by the new implementation of CommentParser used in the Doxygen tests.

view details

Vadim Zeitlin

commit sha e7d0533a6feebbfce9813998f9d059a99aaed6dd

Quote JAVAC expansion in configure to deal with spaces This avoids errors about unknown Java version format when JAVAC is in a path with spaces in it (as is often the case under Windows).

view details

Vadim Chugunov

commit sha 363f8d99f0b3871bc2f420cb35276f51c6bbdd4b

Support stable Python ABI.

view details

push time in 2 months

startedlanza/lldb-vscode

started time in 2 months

issue commentvadimcn/vscode-lldb

Can vsmarketplace ship 1.4.4 please?

The only difference between 1.4.3 and 1.4.4 was a fix in the URL handler. There were no changes in Python detection code, so what you are seeing is likely just a coincidence.

Since each new version causes a hefty download, I don't want to do it too often.

gilescope

comment created time in 2 months

issue commentvadimcn/vscode-lldb

lldb.libpython path load error

Is that a 32 bit python installation? CodeLLDB is needs 64-bit Python.

otoomey

comment created time in 2 months

issue commentvadimcn/vscode-lldb

debugger freezes and massive memory leak when debug regular c++ project.

How did you determine that there's a memory leak?
Does this also happen if you use the regular lldb? And if not, can you please provide a repro case that demonstrates the problem?

XNephila

comment created time in 2 months

issue openedmaindotrs/cargo-fel4

Incorrect parsing of CMakeCache

cargo_config incorrectly parses CMakeCache entries where the value contains ':' or '=' For example, FOO:STRING=C:/foo/bar/baz parses as key: "FOO", value: "C"

Likely culprit: https://github.com/maindotrs/cargo-fel4/blob/e081689f3dee642a2a3d9eb8a29a429c2a5a0a1c/cmake_config/src/lib.rs#L267

created time in 2 months

issue closedvadimcn/vscode-lldb

armv7 linux (raspberry pi) releases

Vscode remote is supporting armv7 in their nightlies https://www.hanselman.com/blog/VisualStudioCodeRemoteDevelopmentOverSSHToARaspberryPiIsButter.aspx

When trying to debug though I get "Acquiring platform package for CodeLLDB" and then "Error: Current platform is not supported"

Any thoughts on supporting?

closed time in 2 months

jacobrosenthal

issue closedvadimcn/vscode-lldb

Error launching terminal agent on Windows

Which OS: Windows Which VSCode version: 1.38.1 Which extension version: 1.3.0 Which adapter type: native Which LLDB version: lldb version 8.0.1

attempt to debug a standard cargo binary on windows with powershell as the terminal.

PS C:\Users\tyler\Code\guessing_game> & '
>> ' 'c:\Users\tyler\.vscode\extensions\vadimcn.vscode-lldb-1.3.0\adapter2\codelldb.exe' 'terminal-agent' '--port=53254'
& : The term '
' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:3
+ & '
+   ~
+ CategoryInfo          : ObjectNotFound: (
:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

running the command myself properly and I get, as the window of opportunity passed evidenced by the debug console error below.

Error: Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." }

and in the Debug Console I get

Failed to redirect stdio to a terminal. (Internal debugger error: Terminal agent did not respond within the allotted time.)
Debuggee output will appear here.```


closed time in 2 months

tyler274

issue commentvadimcn/vscode-lldb

debugger freezes and massive memory leak when debug regular c++ project.

Can you please explain in more detail the problem you are seeing?

XNephila

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Breakpoints skipped in Rust tests, but not main

It works for me... Can you please enable verbose log? ("lldb.verboseLogging": true)

rapodaca

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Breakpoints skipped in Rust tests, but not main

The output you provided says you were launching "Debug unit tests in executable 'hello'" configuration. In which case main() is not be invoked, so the breakpoint will not be hit, as expected.

Please note that launch configurations are not automatically re-generated when you add new targets, you'll need to run "Generate Launch Configurations from Cargo.toml" and copy-paste the ones you want, manually.

rapodaca

comment created time in 3 months

push eventvadimcn/schemafy

Anthony Deschamps

commit sha e40d4322b84eb2a54e699f317de4f0df911647a3

Update itertools and Inflector dependencies.

view details

Markus Westerlind

commit sha af988fca502d4375b3f40027eccd32a23fbaafdd

Merge pull request #19 from adeschamps/dependencies Update itertools and Inflector dependencies.

view details

Markus Westerlind

commit sha 1d0ae918a0e781e82a5d7768f63a05880228534f

chore: Update the snapshot

view details

Markus Westerlind

commit sha b76e10a12e6cc9a720161af9aec6cedfb66bac3e

Improve publish.sh

view details

Markus Westerlind

commit sha 533971ebad4da42f041983aa3ef15f50ac4c9e5f

bump version

view details

Markus Westerlind

commit sha e8dfb9739a41840ad39fcbf9031b04adf35d7c94

(cargo-release) version 0.4.5

view details

Ryan Roberts

commit sha fae0f67a7dc3632c43102410109ab0cbd6a45161

Fix: All current and reserved keywords

view details

Markus Westerlind

commit sha 4eb49a3387866c965ba08679007ddf3bf8d4b1a5

feat: Use a procedural macro to generate the types

view details

Markus Westerlind

commit sha d1dce358b342972f335045bafd1eb4c9fe41e5f5

feat: Remove the snapshot crate and rely on manual updating of the schema

view details

Markus Westerlind

commit sha c32ba74a256fa694e0ee66d79e7314ca33921149

doc: Link to docs

view details

Markus Westerlind

commit sha 4db5071aaea5a24d3eb9e6554504b460d8f8d131

cargo fix --edition

view details

Markus Westerlind

commit sha 0c4785be438a54931d580fe69d37cabaf2ab0e47

cargo fix --edition-idioms

view details

Markus Westerlind

commit sha b09242e1411754e9b571e69d1b1837f6690d463c

schemafy_core

view details

Markus Westerlind

commit sha b7cc437354065f4695afc769b1cd428fc1bc88b1

Don't regenerated the schema every time

view details

Markus Westerlind

commit sha 7821561bdcc0cfdc33574962bf450795eb43d140

Merge pull request #22 from Marwes/proc_macro feat: Use a procedural macro to generate the types

view details

Markus Westerlind

commit sha 9212de34f310f2a91a2790b05beae874bacab9d0

Merge branch 'master' into master

view details

Markus Westerlind

commit sha f96dad38513c899f383eb2f65e35abb5443dccbe

Update lib.rs

view details

Markus Westerlind

commit sha 939cb806546bfc9dd1998fdb015b25445ecd23fc

Merge pull request #21 from presciense/master Fix: All current and reserved keywords

view details

Markus Westerlind

commit sha 76c9c91724e9f34a2a823be484642152dc01dbec

Version 0.5.0

view details

Markus Westerlind

commit sha e41c207f8df8b7fedb136c87d361cf5286fa537e

Update Cargo.toml with links

view details

push time in 3 months

issue openedMarwes/schemafy

Input file path is interpreted relative to Cargo workspace root

The documentation does not state this explicitly, but it looks like the intention was for schemafy!'s path parameter to be relative to the crate root? Unfortunately, in the current incarnation, this path is actually relative to Cargo workspace root, which is pretty confusing when macro fails with "No such file or directory" error.
I think it would be better if the path were relative to the current file, like std::include_str! does.

created time in 3 months

issue commentvadimcn/vscode-lldb

v1.4.3 Unable use attach snippet from my applications

This was fallout from updating npm dependencies. :(

The number of affected users seems to be small (1?), so there won't be an official release for now, but you can install updated version from here. (Use "Install from VSIX...")

nate-onesignal

comment created time in 3 months

PR closed vadimcn/vscode-lldb

Fix parsing of python versions

The python version scheme (https://www.python.org/dev/peps/pep-0440/) follows the scheme [N!]N(.N)*[{a|b|rc}N][.postN][.devN], disagreeing with the semantic versioning specification (https://semver.org/spec/v2.0.0.html) in some important details. Notably, pre-release affixes (alpha, beta, rc) are expressed differently. For example, the fourth release candidate of version 1.2.3 is denoted as follows:

Python: 1.2.3rc4 SemVer: 1.2.3-rc.4

The parsing code separates the version string obtained from Py_GetVersion by a space in order to strip off any ancillary information. This commit extends this to strip off any alpha, beta, or rc indicator present in the actual version.

+4 -1

2 comments

1 changed file

cburger-scheidlin

pr closed time in 3 months

pull request commentvadimcn/vscode-lldb

Fix parsing of python versions

Thanks!

cburger-scheidlin

comment created time in 3 months

created tagvadimcn/vscode-lldb

tagv1.4.4

A native debugger extension for VSCode based on LLDB

created time in 3 months

issue closedvadimcn/vscode-lldb

Can't get Electron to launch correctly

Attaching works, but it requires to modify the ptrace_scope and manually selecting the process which is both annoying.

My problem with launching is that electron won't find its own module and so it crashes.

{
 "type": "lldb",
 "request": "launch",
 "name": "Debug DC Desktop",
 "program": "${workspaceFolder:Desktop (electron)}/node_modules/electron/dist/electron",
 "args": ["${workspaceFolder:Desktop (electron)}"],
 "stopOnEntry": true,
 "sourceLanguages": ["rust", "c"]
}
require('electron') /home/simon/Documents/Projects/dcd-debug-env/deltachat-desktop/node_modules/electron/dist/electron
/home/simon/Documents/Projects/dcd-debug-env/deltachat-desktop/src/main/index.js:6
const rc = app.rc = require('../rc')
                  ^

TypeError: Cannot set property 'rc' of undefined

When starting normally in LLDB it works fine.

lldb ./deltachat-desktop/node_modules/electron/dist/electron -- ./deltachat-desktop/
lldb ./deltachat-desktop/node_modules/electron/dist/electron -- ./deltachat-desktop/
(lldb) target create "./deltachat-desktop/node_modules/electron/dist/electron"
Current executable set to './deltachat-desktop/node_modules/electron/dist/electron' (x86_64).
(lldb) settings set -- target.run-args  "./deltachat-desktop/"
(lldb) run
Process 28220 launched: '/home/simon/Projects/dcd-debug-env/deltachat-desktop/node_modules/electron/dist/electron' (x86_64)
require('electron') { clipboard: [Getter],
  nativeImage: [Getter],
  shell: [Getter],
  app: [Getter],
  autoUpdater: [Getter],
  BrowserView: [Getter],
  BrowserWindow: [Getter],
  contentTracing: [Getter],
  crashReporter: [Getter],
  dialog: [Getter],
  globalShortcut: [Getter],
  ipcMain: [Getter],
  inAppPurchase: [Getter],
  Menu: [Getter],
  MenuItem: [Getter],
  net: [Getter],
  netLog: [Getter],
  Notification: [Getter],
  powerMonitor: [Getter],
  powerSaveBlocker: [Getter],
  protocol: [Getter],
  screen: [Getter],
  session: [Getter],
  systemPreferences: [Getter],
  TopLevelWindow: [Getter],
  TouchBar: [Getter],
  Tray: [Getter],
  View: [Getter],
  webContents: [Getter],
  WebContentsView: [Getter] }
Logfile: /home/simon/.config/DeltaChat/logs/2019-10-01-17-48-48.log.tsv
init: 1974.321ms

It looks like some thing that codelldb does lets electron to require the electron node module instead of the internal electron module that has all methods. The node module just outputs the path of the electron binary and electron seems to overwrite that require('electron') call to instead return the internal electron functions when the file is started with electron.

I need native debugging for a native node module not for electron itself.

Any ideas how I can solve this?

closed time in 3 months

Simon-Laux

issue closedvadimcn/vscode-lldb

v1.4.1 freezes program

Which OS: Arch Linux Which VSCode version: 1.40.1 Which extension version: 1.4.1 Which adapter type: classic

What is the problem and how did you get there:

Debugger freezes program and debug session (VS Code stays up tho). Confirmed working with 1.4.0 but broken with 1.4.1. I use attach with program name approach, attach works, but hitting a breakpoint completely freezes debugged application (kill -9 required).

Program is written in Rust, breakpoint position seems irrelevant.

closed time in 3 months

almindor

issue closedvadimcn/vscode-lldb

v1.4.2 no longer hitting breakpoints when debugging rust

Which OS: both win10 and kubuntu 19.04 Which VSCode version: 1.40.1 Which extension version: 1.4.2 Which adapter type: <!-- See lldb.adapterType. Default is "classic" --> Which LLDB version: <!-- Only if using "classic" debug adapter. Run 'lldb -version' in VSCode terminal. -->

What is the problem and how did you get there: If I set a breakpoint and hit f5, nothing really happens. Neither expected output nor hitting the breakpoint. The program just pauses with no errors or messages.

This is what it looks like. https://i.imgur.com/fqNyKNW.png

Hitting f5 without any breakpoints set prints the message as expected. Same behavior when debugging tests.

reverting to v1.4.1 gives me #229 reverting to v1.4.0 works fine.

launch.json (default):

// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
	{
		"type": "lldb",
		"request": "launch",
		"name": "Debug executable '2016'",
		"cargo": {
			"args": [
				"build",
				"--bin=2016",
				"--package=2016"
			],
			"filter": {
				"name": "2016",
				"kind": "bin"
			}
		},
		"args": [],
		"cwd": "${workspaceFolder}"
	},
	{
		"type": "lldb",
		"request": "launch",
		"name": "Debug unit tests in executable '2016'",
		"cargo": {
			"args": [
				"test",
				"--no-run",
				"--bin=2016",
				"--package=2016"
			],
			"filter": {
				"name": "2016",
				"kind": "bin"
			}
		},
		"args": [],
		"cwd": "${workspaceFolder}"
	}
]

Verbose log:

Running `cargo build --bin=2016 --package=2016 --message-format=json`...
	Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Raw artifacts:
{
fileName: '/home/peter/src/aoc/2016/target/debug/2016',
name: '2016',
kind: 'bin'
}
Filtered artifacts: 
{
fileName: '/home/peter/src/aoc/2016/target/debug/2016',
name: '2016',
kind: 'bin'
}
configuration: {
type: 'lldb',
request: 'launch',
name: "Debug executable '2016'",
args: [],
cwd: '${workspaceFolder}',
relativePathBase: '/home/peter/src/aoc/2016',
program: '/home/peter/src/aoc/2016/target/debug/2016',
sourceLanguages: [ 'rust' ]
}
liblldb: /home/peter/.vscode/extensions/vadimcn.vscode-lldb-1.4.2/lldb/lib/liblldb.so
libpython: libpython3.7m.so.1.0
environment: {}
params: { sourceLanguages: [ 'rust' ] }
Listening on port 46823
[2019-11-29T15:27:17Z DEBUG codelldb] New debug session
INFO(Python) 16:27:17 rust: Initializing, module name=rust
DEBUG(Python) 16:27:17 rust: attaching summary get_tuple_summary to "^\(.*\)$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic SliceSynthProvider to "^slice<.+>.*$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^slice<.+>.*$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 16:27:17 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching synthetic StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
DEBUG(Python) 16:27:17 rust: attaching summary _get_synth_summary_StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"},"type":"request","seq":1}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug executable '2016'","args":[],"cwd":"/home/peter/src/aoc/2016","relativePathBase":"/home/peter/src/aoc/2016","program":"/home/peter/src/aoc/2016/target/debug/2016","sourceLanguages":["rust"],"_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null},"__sessionId":"d4c01045-d8b6-49a5-b390-70548fbb4a1f"},"type":"request","seq":2}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":1,"event":"initialized"}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"24.rs","path":"/home/peter/src/aoc/2016/24.rs"},"lines":[232,282,286],"breakpoints":[{"line":232},{"line":282},{"line":286}],"sourceModified":false},"type":"request","seq":3}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":232,"message":"Locations: 1","source":{"name":"24.rs","path":"/home/peter/src/aoc/2016/24.rs"},"verified":true},{"id":2,"message":"Locations: 0","verified":false},{"id":3,"message":"Locations: 0","verified":false}]}}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"setExceptionBreakpoints","arguments":{"filters":[]},"type":"request","seq":6}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] --> {"command":"configurationDone","type":"request","seq":7}
[2019-11-29T15:27:17Z DEBUG codelldb::wire_protocol] <-- {"type":"request","seq":2,"command":"runInTerminal","arguments":{"args":["/home/peter/.vscode/extensions/vadimcn.vscode-lldb-1.4.2/adapter2/codelldb","terminal-agent","--port=38483"],"cwd":"","kind":"integrated","title":"Debug executable '2016'"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] --> {"type":"response","seq":8,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":19487}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":3,"event":"output","body":{"output":"Launching: /home/peter/src/aoc/2016/target/debug/2016\n"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf98104890 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-2.29.so}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf98104860 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fd1000)}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf98407730 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":4,"event":"module","body":{"module":{"addressRange":"7FFFF7FD2000","id":"7FFFF7FD2000","name":"ld-2.29.so","path":"/usr/lib/x86_64-linux-gnu/ld-2.29.so","symbolFilePath":"/usr/lib/x86_64-linux-gnu/ld-2.29.so","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":5,"event":"module","body":{"module":{"addressRange":"7FFFF7FD1000","id":"7FFFF7FD1000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf980022a0 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {2016}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf983d04a0 Event: broadcaster = 0x7fdf98369668 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fdf98369630 (pid = 19507), state = running}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":6,"event":"module","body":{"module":{"addressRange":"555555554000","id":"555555554000","name":"2016","path":"/home/peter/src/aoc/2016/target/debug/2016","symbolFilePath":"/home/peter/src/aoc/2016/target/debug/2016","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":7,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":9}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[{"id":19507,"name":"1: tid=19507 \"2016\""}]}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf8000d5e0 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdl.so.2}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":8,"event":"module","body":{"module":{"addressRange":"7FFFF7FA7000","id":"7FFFF7FA7000","name":"libdl.so.2","path":"/lib/x86_64-linux-gnu/libdl.so.2","symbolFilePath":"/lib/x86_64-linux-gnu/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf80022760 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {librt.so.1}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":9,"event":"module","body":{"module":{"addressRange":"7FFFF7F9C000","id":"7FFFF7F9C000","name":"librt.so.1","path":"/lib/x86_64-linux-gnu/librt.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf80312330 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {libpthread.so.0}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":10,"event":"module","body":{"module":{"addressRange":"7FFFF7F7B000","id":"7FFFF7F7B000","name":"libpthread.so.0","path":"/lib/x86_64-linux-gnu/libpthread.so.0","symbolFilePath":"/usr/lib/debug/.build-id/d4/82f46b32cdaedf951b4e59b1d7b2e71b1645aa.debug","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf803192d0 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgcc_s.so.1}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFFF7F61000","id":"7FFFF7F61000","name":"libgcc_s.so.1","path":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf80341340 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {libc.so.6}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFFF7D76000","id":"7FFFF7D76000","name":"libc.so.6","path":"/lib/x86_64-linux-gnu/libc.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf80010120 Event: broadcaster = 0x7fdf98009500 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdl.so.2, librt.so.1, libpthread.so.0, libgcc_s.so.1, libc.so.6}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFFF7FA7000","id":"7FFFF7FA7000","name":"libdl.so.2","path":"/lib/x86_64-linux-gnu/libdl.so.2","symbolFilePath":"/lib/x86_64-linux-gnu/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFFF7F9C000","id":"7FFFF7F9C000","name":"librt.so.1","path":"/lib/x86_64-linux-gnu/librt.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFFF7F7B000","id":"7FFFF7F7B000","name":"libpthread.so.0","path":"/lib/x86_64-linux-gnu/libpthread.so.0","symbolFilePath":"/usr/lib/debug/.build-id/d4/82f46b32cdaedf951b4e59b1d7b2e71b1645aa.debug","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFFF7F61000","id":"7FFFF7F61000","name":"libgcc_s.so.1","path":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFFF7D76000","id":"7FFFF7D76000","name":"libc.so.6","path":"/lib/x86_64-linux-gnu/libc.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Callback for breakpoint location 1.1: where = 2016`main + 150 at 24.rs:232:15, address = 0x0000555555588c46, resolved, hit count = 1 

[2019-11-29T15:27:18Z DEBUG codelldb::debug_session] Debug event: 0x7fdf80001340 Event: broadcaster = 0x7fdf98369668 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fdf98369630 (pid = 19507), state = stopped}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":18,"event":"stopped","body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":19507}}
[2019-11-29T15:27:18Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":10}

closed time in 3 months

Zazcallabah

issue commentvadimcn/vscode-lldb

v1.4.2 no longer hitting breakpoints when debugging rust

Thanks for checking!

Zazcallabah

comment created time in 3 months

GollumEvent

issue commentvadimcn/vscode-lldb

Python3.7 not found because INSTSONAME does not contain the full path

Wondering if you are still having this problem in 1.4.3?

thomaskrause

comment created time in 3 months

GollumEvent
GollumEvent
GollumEvent
GollumEvent

issue closedvadimcn/vscode-lldb

Debug swift error in my VSCode

Which OS: Which VSCode version: 1.37 Which extension version: lldb Which adapter type: classic Which LLDB version: 7.0

What is the problem and how did you get there:

configuration: { type: 'lldb', request: 'launch', name: 'Run your Executable', program: '${workspaceFolder}/.build/debug/HelloApp', args: [], cwd: '${workspaceFolder}', preLaunchTask: 'swift-build', sourceLanguages: [ 'swift' ], relativePathBase: '/home/lokinfey/dev/swiftapp/HelloApp' } Error: Command failed: /usr/share/swift/usr/bin/lldb -b -O script print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeLLDBShlibDir).fullpath + '!>');print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeSupportExecutableDir).fullpath + '!>');print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypePythonDir).fullpath + '!>') bind: Invalid command `enable-meta-key'. /usr/share/swift/usr/bin/lldb[0x41f9c4] /usr/share/swift/usr/bin/lldb[0x41da0c] /usr/share/swift/usr/bin/lldb[0x41ff58] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fe3312dc890] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyModule_GetState+0xb)[0x7fe327f4593b] /usr/lib/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so(+0x412e)[0x7fe31dd5212e] /usr/lib/x86_64-linux-gnu/libedit.so.2(rl_initialize+0x4e1)[0x7fe327be6441] /usr/lib/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so(PyInit_readline+0x159)[0x7fe31dd51fd9] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyImport_LoadDynamicModuleWithSpec+0x18c)[0x7fe327f84dcc] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x186bd5)[0x7fe327f86bd5] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyCFunction_Call+0xc1)[0x7fe327f480d1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7a50)[0x7fe327fea450] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7fe32801bbab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c29e)[0x7fe32801c29e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x2c3)[0x7fe32801bfb3] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x131)[0x7fe328035ec1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe6)[0x7fe3280366b6] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyImport_ImportModuleLevelObject+0x47c)[0x7fe32807585c] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7bca)[0x7fe327fea5ca] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7fe32801bbab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7fe32801c67e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7fe327fe280b] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x1ee17d)[0x7fe327fee17d] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyCFunction_Call+0xc1)[0x7fe327f480d1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7a50)[0x7fe327fea450] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7fe32801bbab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c29e)[0x7fe32801c29e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7fe32801c472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7fe327fe7b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7fe32801a953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x2c3)[0x7fe32801bfb3] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x131)[0x7fe328035ec1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe6)[0x7fe3280366b6] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyImport_ImportModuleLevelObject+0x47c)[0x7fe32807585c] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7bca)[0x7fe327fea5ca] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7fe32801bbab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7fe32801c67e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7fe327fe280b] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyRun_StringFlags+0x8f)[0x7fe327f1a28f] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyRun_SimpleStringFlags+0x3b)[0x7fe327f1b32b] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf202c0)[0x7fe32a9552c0] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf1fe83)[0x7fe32a954e83] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf21443)[0x7fe32a956443] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xa17dce)[0x7fe32a44cdce] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9d3b80)[0x7fe32a408b80] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab740a)[0x7fe32a4ec40a] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab5d1e)[0x7fe32a4ead1e] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xaacc85)[0x7fe32a4e1c85] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab07eb)[0x7fe32a4e57eb] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9eff81)[0x7fe32a424f81] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9d4516)[0x7fe32a409516] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab1696)[0x7fe32a4e6696] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(ZN4lldb10SBDebugger21RunCommandInterpreterEbbRNS_30SBCommandInterpreterRunOptionsERiRbS4+0x115)[0x7fe32a198075] /usr/share/swift/usr/bin/lldb[0x409e79] /usr/share/swift/usr/bin/lldb[0x40b307] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fe3284d3b97] /usr/share/swift/usr/bin/lldb[0x40670a] Stack dump: 0. Program arguments: /usr/share/swift/usr/bin/lldb -b -O script print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeLLDBShlibDir).fullpath + '!>');print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeSupportExecutableDir).fullpath + '!>');print('<!' + lldb.SBHostOS.GetLLDBPath(lldb.ePathTypePythonDir).fullpath + '!>')

--- Checking version --- lldb version 7.0.0 (https://github.com/apple/swift-lldb.git revision c7b00758779e906f8efa371ba0467cf7d014cdab) Swift version 5.1-dev (LLVM af1f73e9e9, Swift 7d157f346b) --- Checking Python --- --- Done --- (lldb) script import sys, io, lldb bind: Invalid command `enable-meta-key'. /usr/share/swift/usr/bin/lldb[0x41f9c4] /usr/share/swift/usr/bin/lldb[0x41da0c] /usr/share/swift/usr/bin/lldb[0x41ff58] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f4f2e759890] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyModule_GetState+0xb)[0x7f4f253c293b] /usr/lib/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so(+0x412e)[0x7f4f1b10d12e] /usr/lib/x86_64-linux-gnu/libedit.so.2(rl_initialize+0x4e1)[0x7f4f25063441] /usr/lib/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so(PyInit_readline+0x159)[0x7f4f1b10cfd9] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyImport_LoadDynamicModuleWithSpec+0x18c)[0x7f4f25401dcc] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x186bd5)[0x7f4f25403bd5] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyCFunction_Call+0xc1)[0x7f4f253c50d1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7a50)[0x7f4f25467450] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7f4f25498bab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c29e)[0x7f4f2549929e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x2c3)[0x7f4f25498fb3] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x131)[0x7f4f254b2ec1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe6)[0x7f4f254b36b6] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyImport_ImportModuleLevelObject+0x47c)[0x7f4f254f285c] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7bca)[0x7f4f254675ca] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7f4f25498bab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f4f2549967e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f4f2545f80b] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x1ee17d)[0x7f4f2546b17d] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyCFunction_Call+0xc1)[0x7f4f253c50d1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7a50)[0x7f4f25467450] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7f4f25498bab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c29e)[0x7f4f2549929e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c472)[0x7f4f25499472] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170)[0x7f4f25464b70] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21a953)[0x7f4f25497953] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x2c3)[0x7f4f25498fb3] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x131)[0x7f4f254b2ec1] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe6)[0x7f4f254b36b6] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyImport_ImportModuleLevelObject+0x47c)[0x7f4f254f285c] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x7bca)[0x7f4f254675ca] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21bbab)[0x7f4f25498bab] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f4f2549967e] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f4f2545f80b] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyRun_StringFlags+0x8f)[0x7f4f2539728f] /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyRun_SimpleStringFlags+0x3b)[0x7f4f2539832b] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf202c0)[0x7f4f27dd22c0] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf1fe83)[0x7f4f27dd1e83] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xf21443)[0x7f4f27dd3443] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xa17dce)[0x7f4f278c9dce] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9d3b80)[0x7f4f27885b80] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab740a)[0x7f4f2796940a] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab5d1e)[0x7f4f27967d1e] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xaacc85)[0x7f4f2795ec85] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab07eb)[0x7f4f279627eb] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9eff81)[0x7f4f278a1f81] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0x9d4516)[0x7f4f27886516] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(+0xab1696)[0x7f4f27963696] /usr/share/swift/usr/bin/../lib/liblldb.so.7svn(ZN4lldb10SBDebugger21RunCommandInterpreterEbbRNS_30SBCommandInterpreterRunOptionsERiRbS4+0x115)[0x7f4f27615075] /usr/share/swift/usr/bin/lldb[0x409e79] /usr/share/swift/usr/bin/lldb[0x40b307] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f4f25950b97] /usr/share/swift/usr/bin/lldb[0x40670a] Stack dump: 0. Program arguments: /usr/share/swift/usr/bin/lldb -b -O script import sys, io, lldb -O script print(lldb.SBDebugger.Create().IsValid()) -O script print("OK")

closed time in 3 months

lokinfey

issue closedvadimcn/vscode-lldb

Add option for cargo path

vscode-lldb currently assumes that cargo is in path, which is not always the case.

I personally manage a project's dependencies with Nix for complete reproducibility, and as a result I have no development tools in my normal PATH but instead load an environment for each project. Visual Studio Code however is a single-instance application and as such does not support being started with a different PATH for each project if multiple projects are open concurrently.

Specifying the path of the cargo executable would sidestep this problem because a script could run the correct version of cargo for each development environment.

closed time in 3 months

hyperfekt

issue commentvadimcn/vscode-lldb

Error launching terminal agent on Windows

Fixed in 1.4.1 actually.

tyler274

comment created time in 3 months

issue closedvadimcn/vscode-lldb

exitCommands not executed when remote debugging?

Which OS: macOS Catalina Which VSCode version: 1.39.2 Which extension version: 1.4.0 Which adapter type: native

What is the problem and how did you get there:

Following on from #216, I was able to attach to an lldb-server running inside a Docker container on my Mac, using this configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Remote Debug",
            "type": "lldb",
            "request": "custom",
            "initCommands": [
                "platform select remote-linux",
                "platform connect connect://localhost:1234",
                "env LD_LIBRARY_PATH=/project/user-app/.build/debug"
            ],
            "targetCreateCommands": [
                "file .build/x86_64-unknown-linux/debug/server"
            ],
            "processCreateCommands": [
                "run"
            ],
            "sourceMap": { "/project/user-app" : "${workspaceFolder}" },
            "exitCommands": [
                "process kill"
            ]
        }
    ]
}

This works fine - it will launch the process, and upon hitting a breakpoint, I can see the stack in VSCode. However when I stop or restart the debugging session, the exitCommands do not appear to get run. This leaves an orphaned instance of my executable running inside the container, which prevents another debug session from starting:

Executing script: targetCreateCommands
Current executable set to '.build/x86_64-unknown-linux/debug/server' (x86_64).

Executing script: processCreateCommands
error: process launch failed: Text file busy

Essentially, I expected that when pressing stop (or restart) in VSCode, the exit commands (in this case, process stop) would get issued before the session ends, and this would clean up that lingering process.

I had a look at where exitCommands is consumed (https://github.com/vadimcn/vscode-lldb/blob/70e5a20e4af6d55a1cb5adbe75788233f03db8e1/adapter/debugsession.py#L1277):

            self.exec_commands(self.launch_args.get('exitCommands'))

Should this be using just args instead (similar to processCreateCommands), or maybe I've misunderstood the code here?

<!-- If reporting debugger crash or an internal error, please consider providing verbose log:

  1. Add "lldb.verboseLogging":true to your workspace configuration,
  2. Reproduce the problem,
  3. Paste debug output from Output/LLDB panel below. -->

closed time in 3 months

djones6

issue commentvadimcn/vscode-lldb

exitCommands not executed when remote debugging?

Should be fixed in 1.4.3

djones6

comment created time in 3 months

issue closedvadimcn/vscode-lldb

Cargo invocation has failed: Error: spawn ENOMEM

Which OS: windows10 Which VSCode version: 1.40.1 Which extension version: 1.4.1 Which adapter type: native

What is the problem and how did you get there:

It works fine in 1.4.0. But when i upgraded to 1.4.1 and debugged, vscode reported an error:

Cargo invocation has failed: Error: spawn ENOMEM' .

There is no useful message in output even if i turns on the lldb.verboseLogging, just Running `cargo run --message-format=json`... . Cargo works fine too in terminal. launch.json

    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Cargo launch",
            "cargo": {
                "args": [
                    "run",
                ]
            },
            "program": "${cargo:program}",
            "args": []
        }
    ]
}

closed time in 3 months

Monvvv

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha 7eef5e290813ea8d85dfdb6c5e329e62b1c68c1f

Execute exitComands after custom launch.

view details

Vadim Chugunov

commit sha a571ac20cee2f174349f88f59dc9cf02557d447a

Fix cargo run.

view details

Vadim Chugunov

commit sha eb31e1e6797863bffd08193658ff7bc3d790d69e

Don't simulate start/stop on display settings change unless the debuggee is stopped.

view details

Vadim Chugunov

commit sha aebc0c87f8d15b6d73e8bca06bfbe2af0b758076

SBDebugger::get_variable()

view details

Vadim Chugunov

commit sha f2d26c584d79fabec373e01dfc8d9c2c993976ed

Don't show void* as <invalid address>.

view details

Vadim Chugunov

commit sha 5c25667027f44da9014bc4bb32e41c41e967440c

Float expression results.

view details

Vadim Chugunov

commit sha 779493dfe2b38d25cad5e30bd2d31756a0c47ec2

Version 1.4.2

view details

Ales Katona

commit sha 8e20f13dbdc64002175cf44cc9043c7bcda59408

Fix deprecated list of breakpoint supported langs.

view details

Vadim Chugunov

commit sha caba80c051d09348610f605ac700fdcb2c98c6ee

Correct num_buckets.

view details

Vadim Chugunov

commit sha 1cd0a2540690378e7538b97042cd5abd5ff2d18a

Fix Python deadlocks.

view details

Vadim Chugunov

commit sha 08a6f812a9e9e87fb1e087c998bf2a143cfc9dee

Replace #[allow(unions_with_drop_fields)] with MaybeUninit.

view details

Vadim Chugunov

commit sha 30eb21cee960031c95a10340266ce03a6ae4b75b

Version 1.4.3

view details

push time in 3 months

more