mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

8.1K
active users

#debugger

0 posts0 participants0 posts today
Continued thread

Ah, and also, forgot to mention this change:

Improved:

• Debugging your Kitten app is now easier when you run it using `INSPECT=true kitten …` as the Node runtime is launched using the `--inspect-brk` tag instead of the `--inspect` tag. This means that execution will wait for your debugger (e.g., Chromium’s DevTools at `chrome://inspect`, etc.) to connect before starting the server. This makes it possible to hit breakpoints that might previously have been impossible to reach as they occured before you had a chance to run the debugger.

Full change log:
codeberg.org/kitten/app/src/br

Summary card of repository kitten/app
Codeberg.orgapp/CHANGELOG.md at mainapp - A web development kit that’s small, purrs, and loves you.

Chapter 7, "Software Breakpoints" of "Building a Debugger" by Sy Brand is done (in Rust)!

github.com/drmorr0/drbug

This chapter was reasonably straightforward. The hardest part was figuring out the right type for my breakpoint sites and convincing the borrow checker it was OK. In the C++ version of this code, Sy just returns a pointer to the breakpoint site and everything is fine.

I tried to do it this way at first but ran into a point in the code where I had to hold an immutable borrow across a mutable borrow. In the C++ code this is fine because they're clearly touching different parts of the code and won't interact, but there's no way to tell the Rust borrow checker that, and there was no way to restructure the code to make it work.

I ended up making the breakpoint sites Clone-able, and then just wrapped the "important"/"shared" bits in Rc<Cell<...>>, which works pretty well aside from a couple dumb mistakes which took me too long to debug.

I also, instead of shelling out to `readelf` in the tests, just used the `elf` crate which already exists for Rust. I expect to rip this out in Chapter 11 when we implement our own ELF support in the debugger, but for now it feels less gross than readelf regex parsing.

Next up, Chapter 8, is Memory and Disassembly! I did a quick sneak peak ahead and discovered that the book relies on an external C++ lib for disassembly; fortunately, the `iced` crate for Rust seems to provide the functionality that we need here:

github.com/icedland/iced

Якщо хтось не знав, у #buildkit є вбудований #debugger для білдів
```
% docker buildx debug --on=error --invoke bash build ...
...
--------------------
ERROR: process "..." did not complete successfully: exit code: 1
Interactive container was restarted with process "v3dc7heu3nd4jnrsbkd7ngon6". Press Ctrl-a-c to switch to the new container
(buildx) Switched IO
root@buildkitsandbox:/# це шел в контейнері рівно на тому місці, де впав білд
root@buildkitsandbox:/# Switched IO
(buildx) exit
%
```
buildkit - це збиральник #docker контейнерів, за допомогою якого можна збирати образи під потрібну платформу #ARM або #amd64

The long awaited Black Magic Debug V2.0.0 release is finally here! It is a big update with a lot of improvements and newly supported targets. It pairs very well with bmputil, make sure to give it a try! See release notes for more details. Thanks to everyone who contributed! 🙂 github.com/blackmagic-debug/bl Discuss: github.com/blackmagic-debug/bl #opensource #debugger #electronics #jtag #swd #arm #riscv

This took surprisingly long given that "all" I was doing was writing some tests, but I'm done with Chapter 6, "Testing Registers with x86 Assembly" of "Building a Debugger" in Rust!

This chapter tests the register-writing code that we wrote in the last chapter, and it also adds an interface to the CLI for reading and writing registers for an attached process.

github.com/drmorr0/drbug

x86 debugger written in Rust. Contribute to drmorr0/drbug development by creating an account on GitHub.
GitHubGitHub - drmorr0/drbug: x86 debugger written in Rustx86 debugger written in Rust. Contribute to drmorr0/drbug development by creating an account on GitHub.

Is there a kind of how-did-i-end-up-here-debugger?

Example usage:
Website sends signed requests. You want to know how the signature is build.

Set a breakpoint on XMLHttpRequest.send().
Start recording the huge this-depends-on-that-tree.
Perform actions that trigger send.
Select a variable that holds the signature.

The output should be runnable code.
It would set up required state first.
After that (only) the code that had influence on the signature would be printed.

OK I finished up Chapter 5: Registers from "Building a Debugger". This one was a bit of a doozy.

The book uses number of C++-specific tricks that don't have easy analogues into Rust, so I had to figure out how to convert those in a sensible way. I also forgot (and then was reminded again) about my love/hate relationship with the Rust macro ecosystem.

Also, there are just a LOT OF FREAKING REGISTERS in x86. We'll be implementing support for (checks notes) one hundred and twenty four of them, and that's not all of them.

Anyways I have literally no idea if any of this code works, but that's what chapter 6 is about, supposedly. Sy does include a helpful note at the end of Chapter 5: "The tests will take us down something of a rabbit hole, however, so now would be a great time to take a break." 😂

github.com/drmorr0/drbug

x86 debugger written in Rust. Contribute to drmorr0/drbug development by creating an account on GitHub.
GitHubGitHub - drmorr0/drbug: x86 debugger written in Rustx86 debugger written in Rust. Contribute to drmorr0/drbug development by creating an account on GitHub.

Notorious debugger #x64dbg made a new release. The blog post about this release includes very good details:

* Bitfield support
* Anon types
* Half-float support
* AVX-512 support

These will boost inspection and performance for large structures and will make reverse engineers happy while wasting time on debugging

x64dbg.com/blog/2025/06/30/rel

CC: @mrexodia
#debugger #debugging #avx512 #newrelease

x64dbg.comType System and Modernization · x64dbgOfficial x64dbg blog!
Nach rund acht Monaten in der Entwicklung steht ab sofort allen Zed-Nutzern ein eingebauter Debugger zur Verfügung.#Debugger #Editor #Zed
Zed bietet eingebauten Debugger - LinuxCommunity
LinuxCommunity · Zed bietet eingebauten Debugger - LinuxCommunityNach rund acht Monaten in der Entwicklung steht ab sofort allen Zed-Nutzern ein eingebauter Debugger zur Verfügung. Der wiederum bietet einen von anderen IDEs bekannten Funktionsumfang und unterstützt zahlreiche Programmiersprachen über das Debug Adapter Protocol (DAP). Der Debugger beobachtet wahlweise eine neue Instanz des Programms oder klinkt sich alternativ in einen laufenden Prozess ein. Während der Ausführung informiert Zed in einem eigenen Panel unter anderem über die jeweiligen Variableninhalte, die laufenden Threads und den Zustand des Call Stacks. Breakpoints setzt man wie von anderen IDEs gewohnt schnell per Mausklick vor die betroffenen Zeilen. Wer die Finger nicht von der Tastatur nehmen möchte, darf den Debugger komplett mit Tastenkürzeln steuern. Zed entwanzt den Quellcode von zahlreichen Programmiersprachen. Unter die Lupe nehmen lassen sich im Auslieferungszustand C, C++, JavaScript, Python, Objective-C, Swift, Go, Rust, PHP und Ruby. Die eigentliche Arbeit delegiert Zed im Hintergrund an passende externe Debugger wie den GDB. Diese Helfer müssen folglich installiert sein. Die Kommunikation erfolgt zudem über das Debug Adapter Protocol (DAP). Dabei spricht Zed via DAP zunächst mit einem sogenannten Debug Adapter, der dann wiederum den eigentlichen Debugger steuert. Der Editor unterstützt dabei von Haus aus Adapter für GDB, LLDB, Debugpy, Delve, XDebug, Rdbg und vscode-js-debug. Über Extensions lassen sich weitere Debug Adapter mit Zed bekannt machen. Wer sich nicht auf die Standardeinstellungen verlassen möchte, kann den Debugger detailliert in der Konfigurationsdatei „.zed/debug.json“ anpassen. Um die Konfiguration zu vereinfachen, haben die Zed-Entwickler sogenannte Locators eingeführt. Dank ihrer Hilfe kann man in der „debug.json“ auf die Build Tasks in „tasks.json“ verweisen.
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...

Pet-проект: игра Дебаггер на Python с графическим интерфейсом на Tkinter

Всем привет! В статье расскажу, как я написал игру Дебаггер на Python и добавил к ней графический интерфейс на Tkinter. Мне хотелось сделать простую игру на IT тематику, поэтому я скопировал игровую механику из игры Сапер и теперь нам нужно отметить все баги на игровом поле или наш код сломается. Статья может быть интересна начинающим разработчикам для изучения чужого опыта и наработки своего или же опытным программистам, которые просто хотят поиграть в игру, а может даже предложить, как еще улучшить архитектуру проекта. Нажми, если не боишься багов!

habr.com/ru/articles/917382/

ХабрPet-проект: игра Дебаггер на Python с графическим интерфейсом на TkinterИгра Дебаггер на Python Всем привет! В статье расскажу, как я написал игру Дебаггер на Python и добавил к ней графический интерфейс на Tkinter. Мне хотелось сделать простую...