Okay. Hello, everyone. Thanks for coming. Thanks for having me. So my name is David Petera.
And I will talk about the process of buggy reporting today. So quick words about me.
I study software engineering at Faculty of Maths and Physics at Prague.
And I do support and testing in the birth internet that I think demon in,
see that make, let me find the scene. So we have all been there.
We worked tirelessly on a new version of software, adding new features,
making things faster, making things better. We are on our tests. Everything is green. We hit release.
Finally, we can rest for a bit. But then, our mailbox looks something like this.
Correct reports. So yeah, we may not like it, especially in this bedroom.
But we try to stop it as much as possible. With our choice of run times, automatic testing and
like other elaborate infrastructure. But it is inevitable, basically.
So, when it does happen, we need to get information about the crash.
We need to get information, crucially about the crash from the users themselves.
And it can be quite a messy process.
It can look something like this. Basically, a bird or any other like program running directly on
the system when they crash, they generate a corfile.
So, users tend to send us corfile and the configuration of bird.
Which, as you might know, like without the exact binary, which it was running,
is not really that useful. So we have to ask for the binary.
Then, they send us the corfile, the config, the binary.
And that works most of the time. But sometimes, we need information about, like additional information about
the system, like distribution, kernel version, and stuff like that. So, we have to ask for that.
So, we get corfile, config, binary info, system info, or sorry, binary.
And system info, but sometimes, bird crashes inside one of the dependencies.
We need the dependencies as well. If we have different versions, we basically like in GDP.
We don't see the stack frames clearly, and we need the binaries of the libraries as well.
So, then, we have to ask again, sometimes, when we get the corfile config binary system info, dependencies.
And that works most of the time. But, if the dependencies don't have the debux symbols,
we have to get them manually, or use utilities, like debux info, D to find them.
So, all of this, finally, we have everything, the corfile config binary system info, dependencies, debux symbols,
and we can start debugging. But, all of this waste a lot of time potentially, this can be like,
worth of emails and can be kind of a hell. So, what to do with it? What is the solution?
Sorry, that's not what I wanted.
So, let's reiterate what kind of, we need from a tool or something to solve our problem.
We would ideally need to automate the process. So, like, yeah, we don't have to do this manually again.
We would ideally ask, sorry, let me just check if, yeah, yeah.
We would ideally just, like, tell the users, one command, run this with this, like, run that,
and it will just bundle everything that we need for the debugging.
Also, we need for the tool to work on, like, the variety of systems, and ideally, of course, it should be open source.
So, we were asking ourselves, like, are we alone in this? Of course, like, other developers have the same issue.
But, we tried to look at existing solutions, like, abort, system decode dump, or, like, abort, which, like, work, but they have to be running at the, like, time that program crashes.
And also, they are, kind of, like, system-specific, like, the system-d1, and appartists for, you want to, so, we decided to make our own tool.
The tool is called the Backpack, and, let me try to, like, say, tell you what it is really.
So, it is a command line tool, written first in Bash, but quickly, that was, it was written to Python for obvious reasons.
The Python version is 3.6, which is quite old.
It is quite old deliberately, because some of our customers may or may not be running end-of-life systems, like, eight years old, or something, without support.
But, the 3.6 should be, like, should be a quite good for that.
It also has minimal dependencies to work.
It just needs, like, for now, to utilize the LED, for getting the dynamic little inc libraries, but this will be removed also, quite soon.
Yeah, and it's developed under GPLV-free.
From the user point of view, you basically call one command, which is the Backpack Pack.
You provide a core file, optionally the binary.
The Backpack can detect the binary from the core file if it's possible.
It works most of the time.
The reflect is there just to, like, see what is being done by the program and what is copied and to see a cute picture of a cat.
Yeah, and if the user wants to provide additional files like configurations and anything that would help the developers, it can do so.
This, basically, when a user runs this command, the Backpack will create, like, tar archive and bundle everything, like, together, the information, like the core pack, the, sorry, the core file, the binary.
Everything, basically, that is needed, the system info, the libraries in the structure, the, in the direct, direct structure that it was on the system,
which then can be later used in GDP.
So, from just to show how, like, the structure of the tar archive, it's quite simple.
If I'm able to move, yeah, basically, like I said, we have some, like, config JSON, but for the most part, it's, like, just what I said.
The system in a system info that we safe is just the profiles, the main ones that are usable, and yeah, that's the additional files.
The advantage of this is that it's like any other tar ball, which can just be examined manually if needed.
Yeah, yeah, this is the cat.
If, if you run this, and it should be, it's smaller, but basically you see that it copies all the libraries, then the, the stuff,
and just tells you where, where it's, where it, that it, like, copied to.
So, now from the developer point of view, it, you have, like, two main commands.
One is debug, which, just, you know, if you, if you use the bindels, this, this tar archive sends it to the developer, then the developer will use it in this process.
And basically, this command will open GDP for you.
It sets everything up like the sisterhood with the, it will download the bug info, the bug symbols, and run GDP, and you can basically start the bugging right away.
The browser command is there just to examine the system info and additional files.
So, the benefits of this is that there is no backend forward.
The developer has all the information they need right away at all times.
Also, if you, like, manage to convince your users to use this tool, the bug reporting can be, like, normalized, it's always the same.
The user don't have to think about, like, what information should I provide, it will just be in the bundle.
So, overall, like, better experience for users and deaths also.
Some future work, this setup was mainly used for, like, in house purposes for us.
We managed to publish it because why not.
But I can imagine that, like, other developers have their specific needs that what they need from the bugging tool or, like, reporting tool.
And so, it would be nice to support, like, plugins or other, like, modifications to the code, without, you know, like, rewriting the whole software.
It would be also cool if we have the system info.
We can possibly, like, spin up, like, Docker container or something like that that would have the user system on it.
And we can, for example, like, replicate the crash or the bug or debug it directly in the container.
Yeah, if, if it is, like, needed, it could also be changed to a demon bundle.
Yeah, if you have any ideas, let me know.
It would be nice to collaborate.
So, that's basically it for my presentation.
Do you have a couple more minutes you can think of questions if you want?
Okay, does anybody have questions or such as questions?
Yes.
So, you are dependent on white command type.
So, yes.
Do you consider this as a robot-like indentations?
Like, you just must have the title.
Okay.
I will try to repeat the question that we depend on the Python runtime that is true.
Yeah, I don't, like, we would need to kind of, like, have the, have it as a binary, which is possible.
But, I don't see it as a big limitation.
Like, I think people using our software also have Python runtime on their systems.
Any other questions?
So, you can see the QR code that's the good-lop page.
And, you can meet us at the Birdstand in the Q-Building.
Thank you.