All right, Alexander Heikova is going to talk about the using the world grind arrow
for my nature of our file descriptor tracking.
Hi, I'm Alexander, I work in Red Hat and I want to talk about file descriptors tracking
is well-grained and how we improved file descriptors tracking him again recently.
So what we are going to talk about is what you can do when you see an error.
And recently we implemented a very cool thing.
You can read well-grained from inside gdb, which makes well-grained actually interactive.
And I want to talk about file descriptors a bit and how well-grained can help you to detect
misusing them.
Next.
Okay, so what's well-grained?
I hope everyone knows that.
It's a tool which instruments your code and tracks all the Cisco's and after your program
exits, it will tell you what errors that you did.
So a main and default, well-grained tool is manchacked and detects the unacceptable or
identified memory, but we have also other tools like cash green, massive algorithm.
And there is also none to which used to do nothing, but we used it to actually report
file descriptor errors.
Next.
So what Vulcan error manager is, it creates events when there is a Cisco, we track where and what is happening, so we can tell you.
Vulcan doesn't only report in a human readable form, but we can actually report in an XML format.
And I know that eclipse is using that.
I don't know if other tools may use that.
So when we was working on file descriptor tracking, we also can report that in XML format.
So there is an option for this.
So if you want XML format, you can use that and it will report in XML format.
Also when it has suppressions.
So there is a way, so you can have a suppression file, you run it as well-grained.
And in a suppression file, you will record known issues.
Well, we can actually sometimes even give false positive.
I hope it doesn't happen often, but if this is an issue, you can use suppression file.
Also, if Vulcan is well-grained for a long time, it can be used with GDB.
But before you had to have two terminals set up.
In the one terminal, you would run GDB.
In other terminal, you would run Vulcan.
But now, you can run away from inside GDB.
The next slide, please.
So I have an example, how you would do that.
So you can run GDB.
You set some things.
And then you will start the Vulcan using target extended remote command.
You can see Vulcan there, but the GDB, the GDB is intermediary tool.
And we need that to negotiate the connection.
After you do that, you will run your program under GDB and Vulcan at the same time.
And so what you can use, you can start or run as you are used to.
You can set breakpoints.
You can do whatever you are used to with GDB.
But when you run and Vulcan spots any kind of error, it will send signal to GDB.
You will start your program.
And at this point, you can run the variable or structure or you can ask for better
backtrace.
But not only that, you can communicate with Vulcan using monitor commands.
So you can actually ask Vulcan about if the flag is defined.
You can ask all of it about how many file descriptors are open.
You can take that.
I wrote an article about this, so you can read it if you are interested.
So file descriptors are like other resources.
They are a bit like memory from or point of view.
So you have to open file descriptor or you can inherit it.
And you have to allocate your memory.
After you are done with your file descriptor, you should close it.
And the same way, like you should free your memory.
Also, you can try to read from the descriptor you never inherited.
Like you can try to read from the memory, which is not yours.
So Vulcan is not tracking the file descriptors by default.
If you want to track them, you need to use this track.
If this yes option.
Also, I wanted to emphasize that me myself, I always think about the descriptor like about file.
But it's not just the file.
Of course, it can be signal, it can be socket.
And other things.
So when you open the file descriptor, Vulcan will record where you opened it.
And we will tell you after.
Thanks.
So one of these things you can do is try to double close your file descriptor.
Why is that problem?
It's a really problem when there is multi-thread program.
So your web thread closes it.
Another thread opens another file descriptor.
Which actually has the same number.
And first thread closes it.
And the other thread wants to read from it or write from it.
So if you use file descriptors,
I have the track, if it is yes.
At the end, or if you are using it with GDB, you will tell you immediately.
So it will tell you file descriptor number.
I will tell you where you close it originally.
And where it was opened.
Thanks.
You can try to use file descriptor after a close.
And it's the same so you closed it.
And then you try to write there.
You can also try to read from there.
And again, what we will give you the back trace.
Also, you can try to use completely invalid file descriptor,
which is too big or even negative.
And we will worry about that.
Next.
So this is the example if you are trying to use a file descriptor you never created.
So now I'm working on a new option.
And it's working in progress.
It's not very yet.
And it's called modify file descriptors.
No high or strict option.
So if you are a close in file descriptor.
And right after that, you will open it another one.
Posing requires it to be the lowest possible number.
So you closed file descriptor 4.
You are asking for another one, the new one is 4.
And it can lead to some bugs.
So you open file descriptor, you closed it, you open the new one.
But actually the new one actually has the same number with this one,
which may lead to bugs.
And if you use this option, modify of these high.
Instead of getting the lowest one, you'll get the highest file descriptor's possible.
So it might be interesting.
Also we are considering, so if you say no, it will happen.
If you say high, you'll get the highest one.
But also we are considering, including strict option.
And that it will be that it's only, that this option only worked for file descriptor,
which are not 012.
Because some programs rely on that standard input out a direction.
So you would be prevented to use that option if we didn't have this.
Okay, thanks.
So you can look memory, you can leak file descriptor.
If you won't close file descriptors, you will leak them.
And if you'll use this track of this, yes.
Volgrins will tell you at the end what you leak.
But Volgrins won't warn you about 012 extended in out an error,
because you're usually not closing them.
But if you want to know, you can use track of these all,
and then you'll be worn.
Okay, so here I have the example how it looks like.
There is a new Cisco, or I think it's not a bad idea.
I think it's five years or something.
It's called close range.
And this Cisco allows you to close a white range.
It allows you to close everything.
So we decided that in the case of this, if you use close range for a white range of
file descriptors, Volgrins won't warn you about the double close.
So I wanted to include an example that will show how you will ask Volgrins about
file descriptors.
So you will run Volgrins with GDB server with GDB.
Volgrins can act as a GDB server.
Volgrins has a GDB server embedded.
So you can run Volgrins from GDB this way.
And when GDB stops, you can ask Volgrins about open file descriptors using monitor comment.
Monitor comments are not specific to Volgrins.
It's a way how to communicate with various kinds of GDB servers.
And I also have an article about that.
Anybody interested?
Next.
Another work in progress.
I'm working at is adding track of these bad option.
And now, when you are using track of these, yes, we will warn you about all kinds of
misusing file descriptors, double leagues, double close, use after close.
You might not be interested in leaks.
So if you would use track of these bad,
you will be only warned about double close, use after close.
If you used invalid file descriptor, if you used file descriptor, that was never
created by you.
But you only warned about leaks.
And we both think that if we should be enabling this option by default.
And we are not sure we would like to have some feedback.
So you'll just run Volgrins with any program.
And we will automatically warn you about file descriptors, but not about leaks.
Because I think leaks are very often and it may create a lot of errors.
It's not necessarily bad to close something that's already closed.
Distended says what should be done then, namely nothing.
So that's one example we've had.
So if by default, it would report that I'm not necessarily bad.
It's not that good.
Okay.
So we will be happy for feedback.
Okay.
So I just want to summarize.
But I was looking here about.
So file descriptors is a resource.
We are interested in tracking.
And there are.
So file descriptors, yes, option.
It was in Volgrins.
But it wasn't a proper error.
We made a proper error using a non-tool.
And now it gives proper back traces for all kinds of problems.
And also there are two important things.
What if I have these high?
Which is, I hope.
I hope it's interesting.
And also we are considering enabling track every these bad.
I hope it will be in the next Volgrins version.
Well, Volgrins will track file descriptors,
but it won't warn you about leaks.
Also, please use Volgrins and GDP together.
I think it's like, I think it's very cool.
Next.
Thank you for your attention.
I'd.
So I have a list of articles I wrote.
If anybody's interested.
It's about Volgrins and GDP.
I have a question.
Go.
So the file descriptors are per process.
Yes.
And so basically those opening file descriptors close in them.
And so on.
It's a dynamic event.
And I assume the background is actually following the execution and recording the execution.
Yes.
The system calls, involved by all and every thread in the process.
Yes.
So how does that work along with GDP when it's not working in a non-stop mode, for example?
Yeah.
I haven't tried.
No, but.
I mean.
So because can ball grind integrated in GDP work in a stop mode,
sorry, now.
Or you have to run GDP in a stop mode.
I don't know.
I have a choice.
No.
I don't know.
Yeah.
Stop.
I don't know.
No.
It's not a big problem.
It doesn't even support it, I think.
Yeah.
We would have to try.
Maybe I'll try tomorrow.
Or today.
No.
That's right.
I do.
The other word would have support the non stop,
bearing of the fold of all.
I think it does.
No.
Not.
Doesn't it work?
Does it always?
Does it, does it make sense for it to work,eyone thinks so?
What is it?
I don't know.
OK.
Another question.
There should people address questions upon butches.
Why is this developed on the Balt supervisor on the GDP side?
On bombs side.
On Douggrimer employees list.
Yeah, so you can use a well-great user's list.
Yes?
Fine.
If you do that?
Yeah.
It will take time, yes.
Hi, yeah.
So we're at the end of this call.
And yes, well-grained.
If you have many calls that are opening
for all the scriptures and you will enable this option,
then yes, it will go slow down.
And you know, I'm not talking about
run, I'm talking about the delay
until a news is called
and of being supported by
Linux ads and users.
I mean, I mean, do you Prefer,
consider the BPM scan in the sana or the
chip interface, sign up Translate.
My assumption was previously vibrant in the app and now that.
Okay, so it's possible that there aren't
useless calls, I'm not aware about it and
that I haven't picked Adept yet.
It's possible, yes.
There are a lot of things, but it is in front of me,
but I don't want to remove that out.
So almost every system,
things, memory, or it gets memory back then,
it gets to affect that.
So we have to support all systems.
There's nothing making the work.
Yeah.
The option that you use to specify which kind of,
in the track, yes.
So that's the local variant.
So the option can combine.
What can you get?
Can you use high and bad at the same time?
Not yet.
But logically, it should be possible.
Yeah, but we want to use bad with all, right?
Yeah.
The modifying.
You're too kind to be making a track in there.
So you can't, you can't, you can't
mix modify with track.
And when you're using track, every bad,
you don't want to use all because bad prevents you from
showing me leaks.
And all is about showing you that you have leaked
standard in out and error.
So it doesn't make sense.
Yeah, but the high is modify of these,
which is a different option.
Sorry.
Yes?
Yes.
I forgot.
So this is nice to have been bothering,
but I think in principle, you could implement
these even with B-trace.
Do you want to hear?
Yes.
By the way, not.
It's just implemented with B-trace.
You don't get the tight integrated B-trace.
And I think that's the bigger one.
It's of this approach.
Yeah.
Thank you.
Hey, I think that's all.
Thank you for your attention.