techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.6K
active users

#lldb

0 posts0 participants0 posts today

Something that surprised me is that 'po' in lldb might try to interpret a String unexpectedly. I just noticed it now where I had some HTML in a String and when I did 'po' to dump it out, lldb omitted part of the string on the output! Very strange.

I was playing around and found that if you do `po "abc\n\n\nhello./def"`, lldb won't print anything, but as soon as you delete one of the newlines, it does print out properly! #xcode #lldb

Continued thread

For two days straight, I just can't reproduce #swad #crashing with *anything* in place (#clang #sanitizer instrumentation, attached #debugger like #lldb) that could give me the slightest hint what's going wrong. 😡

But it *does* crash when "unobserved". And it looks like this is happening a lot sooner (or, more often?) when using #LibreSSL ... but I also suspect this could be a red herring in the end.

Situation reminds me of my physics teacher back at school, who used to say something in german I just can't ever forget:

"Wer misst, misst Mist."

Feeble attempt in english would be "the one who measures measures crap", it was his humorous way to bring one consequence of #Heisenberg's indeterminacy principle to the point. And indeed, #debugging computer programs always suffers from similar problems...

We released new Pwndbg: github.com/pwndbg/pwndbg/relea !

Among others it brings:
- New & improved kernel debugging commands (buddydump, msr, slab) and more x64 regs in context
- New command for dealing with armcm exceptions: dump-register-frame
- Disasm now shows an ✘ marker for emulated branches we know won't be taken
- Improved disasm for ARM, MIPS and LoongArch64 architectures
- Initial support for the IBM s390x architecture
- IDA sync integration fixes

And also cool portable one-liner installers:
$ curl -qsL 'install.pwndbg.re' | sh -s -- -t pwndbg-gdb
$ curl -qsL 'install.pwndbg.re' | sh -s -- -t pwndbg-lldb

Want to support us? Sponsor us at github.com/sponsors/pwndbg !

#pwning#gdb#ctfs

🎉 Behold, yet another attempt to make #debugging "fun" by ditching the decades-old, well-established #GDB and #LLDB for a shiny terminal interface. Because who needs reliable tools when you can have a hipster debugger that promises to revolutionize... absolutely nothing? 🙃
github.com/al13n321/nnd #fun #terminalinterface #hipsterdebugger #HackerNews #ngated

A debugger for Linux. Contribute to al13n321/nnd development by creating an account on GitHub.
GitHubGitHub - al13n321/nnd: A debugger for LinuxA debugger for Linux. Contribute to al13n321/nnd development by creating an account on GitHub.

We really want to take automation in Swift Package and Xcode projects into a better place:

1. You should be able to build and test your projects in the most optimal way and get telemetry to improve things.
2. You should be able to extend automation with your own workflows in Swift and be able to debug them with #LLDB
3. You should be able to virtualise the execution of the workflows locally.
4. You should be able to run workflows virtualised in a remote environment like you did locally.

Continued thread

If I was on gdb, that print would have done:
```
(gdb) print &a
$1 = (struct a *) 0x7fffffffe4f8
```

which means that I can then use $1 in later expressions to use that value, so then I can do:
```
(gdb) watch $1->a
Watchpoint 2: $1->a
```
and it just works.

None of that happens w/ lldb.

And none of the guides that talk about how to convert gdb to lldb mention how to deal w/ these deficiencies.

Continued thread

Ok, I just found out that when you print stuff, lldb doesn't actually print things properly.
```
(lldb) run
[...]
-> 10 struct a a = (struct a){};
[...]
Target 0: (t) stopped.
(lldb) print &a
(a *) 0x000000016fdff1b8
(lldb) print ((a *) 0x000000016fdff1b8)->a
error: <user expression 1>:1:6: expected expression
((a *) 0x000000016fdff1b8)->a
^
(lldb) print ((struct a *) 0x000000016fdff1b8)->a
(int) 4266848
```

I also just realized that lldb doesn't keep a history of values printed.

LLDB does not support reverse debugging yet. As far as I know, there are two ways to implement reverse debugging: one is record and replay, such as the rr tool, which can be considered as read-only; the other is "true" reverse, which can "roll back->modify the state->run again". The latter is not necessarily more useful than the former. For example, some nondeterministic bugs can be reproduced 100% using record and replay, but may not be reproduced by running it again with "true" reverse.

Про контейнеризацию в разработке софта.
Порой имеется несколько разных #linux (и дистрибутивов и версий) под которые надо разрабатывать приложения (собирая, отлаживая). Либо локально на машине разработчика или же на серверах каких-то.

Как вариант, берётся #VSCode с предлагаемым подходом и даже есть более-менее подробная информация для освоения процесса.

Берётся вот это расширение Dev Containers.
И в контейнер ходит не через #SSH, а производит установку внутрь контейнера такой вещи как «VSCode Server». Выполняется установка прозрачно для пользователя, в процессе «подключения» к заданному контейнеру (на локальной машине). #VSCode берёт идентификатор своей версии (commit id) и по нему скачивает «VSCode Server» со специального сайта #Microsoft.

А само окно #VSCode становится чем-то вроде удалённого GUI для того сервера, что теперь запущен в контейнере. Это вполне работает и с #rootless контейнерами, для чего надо в:
~/.config/Code/User/settings.json
прописать параметры вида:
"dev.containers.dockerSocketPath": "unix:///run/user/100500/docker.sock",
"docker.environment": {
    "DOCKER_HOST": "unix:///run/user/100500/docker.sock"
},
Подсмотреть unix-socket можно через:
$ systemctl status --user docker.socket
...
     Listen: /run/user/100500/docker.sock (Stream)

Приколов несколько:
  • В таком открывшемся окне #VSCode на вкладке расширений придётся включить уже имеющиеся/установленные расширения, чтобы они скопировались внутрь контейнера. Т.е. работают он реально там на сервере, а не тут локально.
  • Некоторым расширениям нужны всякие вещи, вроде #LSP сервера, #lldb / #gdb, иногда [urr=https://github.com/lldb-tools/lldb-mi]lldb-mi[/url]. Всё это внутрь контейнера придётся устанавливать самостоятельно, ручками.
  • Использовать расширение Dev Containers получится лишь на официальной Visual Studio Code — в таких вариантах как #Code-OSS, #VSCodium и #Uncoded оно просто не доступно. А если его установить через скаченный #VSIX, то работать не будет.


Хорошо или плохо?
Официальный #VSCode конечно же шлёт телеметрию в #Microsoft «со страшной силой» да и вообще, является проприетарным вариантом дистрибьюции #Code-OSS, который тоже, в свою очередь, страдает телеметрией (из-за чего и появились #VSCodium да #Uncoded ).

Однако, именно в силу проприетарности #VSCode и позволяет из галереи устанавливать проприетарное же расширение Dev Containers. А в галереи у #Code-OSS этого расширения нет и понятно почему — не сможет скачать серверную часть, которую нужно устанавливать внутри контейнера (в качестве агента) и которая тоже проприетарная.

В целом:
  • Работать с кодом получается, равно как и обычным образом, как если бы тулчейн и библиотеки не находились внутри контейнера.
  • Поддерживаются обычные #Docker и #rootless варианты #Docker и так же #Podman, которые априори #rootless.
  • Не обязательно заморачиваться с .devcontainer/devcontainer.json в проекте, можно подключаться из #VSCode к любому контейнеру — запустит новое окно.


Нормальный проприетарный продукт, охватывает разные сценарии. В том числе и для любителей сидеть на #Windows и вести разработку через #WSL (Windows Subsystem for Linux v2).

#containerization #containers #softwaredevelopment #software #lang_ru @Russia
hub.hubzilla.deHubzilla.de
Continued thread

@matuzalem here's a release to test 😉 I'm pretty sure it won't crash, but can't guarantee. It's been examined a lot, also with #lldb and #valgrind, but doesn't have any automated tests so far. I'm still undecided about investing the time and effort to change that, would need to pick a library/framework first (C doesn't offer any testing capabilities in the language) and then, while a few modules like the unicode string functions are perfectly unit-testable, the whole project is a large "event processor" (like any GUI application) and depends on these external events, so a *lot* of tedious mocking would be required for better test coverage ...

edit: btw, fixed a weird bug before releasing this, it was possible to enter a state where processing X11 events stopped (requesting to minimize with the WM ignoring the request). Not a crash, but a bug 😅