WEBVTT 00:00.000 --> 00:10.240 All right, Alexander Heikova is going to talk about the using the world grind arrow 00:10.240 --> 00:25.240 for my nature of our file descriptor tracking. 00:25.240 --> 00:33.520 Hi, I'm Alexander, I work in Red Hat and I want to talk about file descriptors tracking 00:33.520 --> 00:40.520 is well-grained and how we improved file descriptors tracking him again recently. 00:40.520 --> 00:49.520 So what we are going to talk about is what you can do when you see an error. 00:49.520 --> 00:52.520 And recently we implemented a very cool thing. 00:52.520 --> 00:59.520 You can read well-grained from inside gdb, which makes well-grained actually interactive. 00:59.520 --> 01:07.520 And I want to talk about file descriptors a bit and how well-grained can help you to detect 01:07.520 --> 01:09.520 misusing them. 01:09.520 --> 01:10.520 Next. 01:10.520 --> 01:13.520 Okay, so what's well-grained? 01:13.520 --> 01:16.520 I hope everyone knows that. 01:16.520 --> 01:31.520 It's a tool which instruments your code and tracks all the Cisco's and after your program 01:31.520 --> 01:37.520 exits, it will tell you what errors that you did. 01:37.520 --> 01:45.520 So a main and default, well-grained tool is manchacked and detects the unacceptable or 01:45.520 --> 01:50.520 identified memory, but we have also other tools like cash green, massive algorithm. 01:50.520 --> 01:57.520 And there is also none to which used to do nothing, but we used it to actually report 01:57.520 --> 02:00.520 file descriptor errors. 02:00.520 --> 02:04.520 Next. 02:04.520 --> 02:24.520 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. 02:24.520 --> 02:32.520 Vulcan doesn't only report in a human readable form, but we can actually report in an XML format. 02:32.520 --> 02:34.520 And I know that eclipse is using that. 02:34.520 --> 02:37.520 I don't know if other tools may use that. 02:37.520 --> 02:44.520 So when we was working on file descriptor tracking, we also can report that in XML format. 02:44.520 --> 02:46.520 So there is an option for this. 02:46.520 --> 02:52.520 So if you want XML format, you can use that and it will report in XML format. 02:52.520 --> 02:56.520 Also when it has suppressions. 02:56.520 --> 03:00.520 So there is a way, so you can have a suppression file, you run it as well-grained. 03:00.520 --> 03:05.520 And in a suppression file, you will record known issues. 03:05.520 --> 03:09.520 Well, we can actually sometimes even give false positive. 03:09.520 --> 03:17.520 I hope it doesn't happen often, but if this is an issue, you can use suppression file. 03:17.520 --> 03:26.520 Also, if Vulcan is well-grained for a long time, it can be used with GDB. 03:26.520 --> 03:31.520 But before you had to have two terminals set up. 03:31.520 --> 03:34.520 In the one terminal, you would run GDB. 03:34.520 --> 03:36.520 In other terminal, you would run Vulcan. 03:36.520 --> 03:40.520 But now, you can run away from inside GDB. 03:41.520 --> 03:43.520 The next slide, please. 03:43.520 --> 03:46.520 So I have an example, how you would do that. 03:46.520 --> 03:48.520 So you can run GDB. 03:48.520 --> 03:50.520 You set some things. 03:50.520 --> 03:56.520 And then you will start the Vulcan using target extended remote command. 03:56.520 --> 04:01.520 You can see Vulcan there, but the GDB, the GDB is intermediary tool. 04:01.520 --> 04:05.520 And we need that to negotiate the connection. 04:05.520 --> 04:12.520 After you do that, you will run your program under GDB and Vulcan at the same time. 04:12.520 --> 04:17.520 And so what you can use, you can start or run as you are used to. 04:17.520 --> 04:18.520 You can set breakpoints. 04:18.520 --> 04:22.520 You can do whatever you are used to with GDB. 04:22.520 --> 04:31.520 But when you run and Vulcan spots any kind of error, it will send signal to GDB. 04:31.520 --> 04:32.520 You will start your program. 04:32.520 --> 04:39.520 And at this point, you can run the variable or structure or you can ask for better 04:39.520 --> 04:40.520 backtrace. 04:40.520 --> 04:46.520 But not only that, you can communicate with Vulcan using monitor commands. 04:46.520 --> 04:51.520 So you can actually ask Vulcan about if the flag is defined. 04:51.520 --> 04:55.520 You can ask all of it about how many file descriptors are open. 04:55.520 --> 04:57.520 You can take that. 04:57.520 --> 05:04.520 I wrote an article about this, so you can read it if you are interested. 05:04.520 --> 05:10.520 So file descriptors are like other resources. 05:10.520 --> 05:13.520 They are a bit like memory from or point of view. 05:13.520 --> 05:20.520 So you have to open file descriptor or you can inherit it. 05:20.520 --> 05:22.520 And you have to allocate your memory. 05:22.520 --> 05:27.520 After you are done with your file descriptor, you should close it. 05:27.520 --> 05:30.520 And the same way, like you should free your memory. 05:30.520 --> 05:35.520 Also, you can try to read from the descriptor you never inherited. 05:35.520 --> 05:43.520 Like you can try to read from the memory, which is not yours. 05:43.520 --> 05:48.520 So Vulcan is not tracking the file descriptors by default. 05:48.520 --> 05:51.520 If you want to track them, you need to use this track. 05:51.520 --> 05:55.520 If this yes option. 05:55.520 --> 06:04.520 Also, I wanted to emphasize that me myself, I always think about the descriptor like about file. 06:04.520 --> 06:05.520 But it's not just the file. 06:05.520 --> 06:10.520 Of course, it can be signal, it can be socket. 06:10.520 --> 06:13.520 And other things. 06:13.520 --> 06:21.520 So when you open the file descriptor, Vulcan will record where you opened it. 06:21.520 --> 06:25.520 And we will tell you after. 06:25.520 --> 06:27.520 Thanks. 06:27.520 --> 06:35.520 So one of these things you can do is try to double close your file descriptor. 06:35.520 --> 06:37.520 Why is that problem? 06:37.520 --> 06:41.520 It's a really problem when there is multi-thread program. 06:41.520 --> 06:44.520 So your web thread closes it. 06:44.520 --> 06:47.520 Another thread opens another file descriptor. 06:47.520 --> 06:50.520 Which actually has the same number. 06:50.520 --> 06:52.520 And first thread closes it. 06:52.520 --> 06:57.520 And the other thread wants to read from it or write from it. 06:57.520 --> 07:00.520 So if you use file descriptors, 07:00.520 --> 07:03.520 I have the track, if it is yes. 07:03.520 --> 07:08.520 At the end, or if you are using it with GDB, you will tell you immediately. 07:08.520 --> 07:13.520 So it will tell you file descriptor number. 07:13.520 --> 07:17.520 I will tell you where you close it originally. 07:17.520 --> 07:20.520 And where it was opened. 07:20.520 --> 07:23.520 Thanks. 07:23.520 --> 07:28.520 You can try to use file descriptor after a close. 07:28.520 --> 07:31.520 And it's the same so you closed it. 07:31.520 --> 07:33.520 And then you try to write there. 07:33.520 --> 07:35.520 You can also try to read from there. 07:35.520 --> 07:42.520 And again, what we will give you the back trace. 07:42.520 --> 07:46.520 Also, you can try to use completely invalid file descriptor, 07:46.520 --> 07:49.520 which is too big or even negative. 07:49.520 --> 07:52.520 And we will worry about that. 07:52.520 --> 07:56.520 Next. 07:56.520 --> 08:04.520 So this is the example if you are trying to use a file descriptor you never created. 08:05.520 --> 08:08.520 So now I'm working on a new option. 08:08.520 --> 08:10.520 And it's working in progress. 08:10.520 --> 08:11.520 It's not very yet. 08:11.520 --> 08:14.520 And it's called modify file descriptors. 08:14.520 --> 08:16.520 No high or strict option. 08:16.520 --> 08:19.520 So if you are a close in file descriptor. 08:19.520 --> 08:22.520 And right after that, you will open it another one. 08:22.520 --> 08:25.520 Posing requires it to be the lowest possible number. 08:25.520 --> 08:28.520 So you closed file descriptor 4. 08:28.520 --> 08:31.520 You are asking for another one, the new one is 4. 08:31.520 --> 08:33.520 And it can lead to some bugs. 08:33.520 --> 08:38.520 So you open file descriptor, you closed it, you open the new one. 08:38.520 --> 08:42.520 But actually the new one actually has the same number with this one, 08:42.520 --> 08:44.520 which may lead to bugs. 08:44.520 --> 08:48.520 And if you use this option, modify of these high. 08:48.520 --> 08:57.520 Instead of getting the lowest one, you'll get the highest file descriptor's possible. 08:57.520 --> 09:00.520 So it might be interesting. 09:00.520 --> 09:05.520 Also we are considering, so if you say no, it will happen. 09:05.520 --> 09:08.520 If you say high, you'll get the highest one. 09:08.520 --> 09:12.520 But also we are considering, including strict option. 09:12.520 --> 09:19.520 And that it will be that it's only, that this option only worked for file descriptor, 09:19.520 --> 09:22.520 which are not 012. 09:22.520 --> 09:29.520 Because some programs rely on that standard input out a direction. 09:29.520 --> 09:34.520 So you would be prevented to use that option if we didn't have this. 09:34.520 --> 09:36.520 Okay, thanks. 09:36.520 --> 09:39.520 So you can look memory, you can leak file descriptor. 09:39.520 --> 09:44.520 If you won't close file descriptors, you will leak them. 09:44.520 --> 09:48.520 And if you'll use this track of this, yes. 09:48.520 --> 09:53.520 Volgrins will tell you at the end what you leak. 09:53.520 --> 09:59.520 But Volgrins won't warn you about 012 extended in out an error, 09:59.520 --> 10:01.520 because you're usually not closing them. 10:01.520 --> 10:06.520 But if you want to know, you can use track of these all, 10:06.520 --> 10:10.520 and then you'll be worn. 10:10.520 --> 10:17.520 Okay, so here I have the example how it looks like. 10:17.520 --> 10:22.520 There is a new Cisco, or I think it's not a bad idea. 10:22.520 --> 10:24.520 I think it's five years or something. 10:24.520 --> 10:27.520 It's called close range. 10:27.520 --> 10:32.520 And this Cisco allows you to close a white range. 10:32.520 --> 10:35.520 It allows you to close everything. 10:35.520 --> 10:42.520 So we decided that in the case of this, if you use close range for a white range of 10:42.520 --> 10:50.520 file descriptors, Volgrins won't warn you about the double close. 10:50.520 --> 10:59.520 So I wanted to include an example that will show how you will ask Volgrins about 10:59.520 --> 11:00.520 file descriptors. 11:00.520 --> 11:05.520 So you will run Volgrins with GDB server with GDB. 11:06.520 --> 11:08.520 Volgrins can act as a GDB server. 11:08.520 --> 11:10.520 Volgrins has a GDB server embedded. 11:10.520 --> 11:15.520 So you can run Volgrins from GDB this way. 11:15.520 --> 11:23.520 And when GDB stops, you can ask Volgrins about open file descriptors using monitor comment. 11:23.520 --> 11:26.520 Monitor comments are not specific to Volgrins. 11:26.520 --> 11:33.520 It's a way how to communicate with various kinds of GDB servers. 11:33.520 --> 11:36.520 And I also have an article about that. 11:36.520 --> 11:38.520 Anybody interested? 11:38.520 --> 11:41.520 Next. 11:41.520 --> 11:43.520 Another work in progress. 11:43.520 --> 11:48.520 I'm working at is adding track of these bad option. 11:48.520 --> 11:54.520 And now, when you are using track of these, yes, we will warn you about all kinds of 11:54.520 --> 12:00.520 misusing file descriptors, double leagues, double close, use after close. 12:01.520 --> 12:03.520 You might not be interested in leaks. 12:03.520 --> 12:06.520 So if you would use track of these bad, 12:06.520 --> 12:11.520 you will be only warned about double close, use after close. 12:11.520 --> 12:17.520 If you used invalid file descriptor, if you used file descriptor, that was never 12:17.520 --> 12:18.520 created by you. 12:18.520 --> 12:20.520 But you only warned about leaks. 12:20.520 --> 12:26.520 And we both think that if we should be enabling this option by default. 12:26.520 --> 12:30.520 And we are not sure we would like to have some feedback. 12:30.520 --> 12:35.520 So you'll just run Volgrins with any program. 12:35.520 --> 12:39.520 And we will automatically warn you about file descriptors, but not about leaks. 12:39.520 --> 12:47.520 Because I think leaks are very often and it may create a lot of errors. 12:47.520 --> 12:51.520 It's not necessarily bad to close something that's already closed. 12:51.520 --> 12:55.520 Distended says what should be done then, namely nothing. 12:55.520 --> 12:57.520 So that's one example we've had. 12:57.520 --> 13:02.520 So if by default, it would report that I'm not necessarily bad. 13:02.520 --> 13:05.520 It's not that good. 13:05.520 --> 13:06.520 Okay. 13:06.520 --> 13:10.520 So we will be happy for feedback. 13:10.520 --> 13:12.520 Okay. 13:12.520 --> 13:13.520 Okay. 13:13.520 --> 13:15.520 So I just want to summarize. 13:15.520 --> 13:17.520 But I was looking here about. 13:17.520 --> 13:20.520 So file descriptors is a resource. 13:20.520 --> 13:22.520 We are interested in tracking. 13:22.520 --> 13:23.520 And there are. 13:23.520 --> 13:25.520 So file descriptors, yes, option. 13:25.520 --> 13:27.520 It was in Volgrins. 13:27.520 --> 13:29.520 But it wasn't a proper error. 13:29.520 --> 13:32.520 We made a proper error using a non-tool. 13:32.520 --> 13:37.520 And now it gives proper back traces for all kinds of problems. 13:37.520 --> 13:41.520 And also there are two important things. 13:41.520 --> 13:44.520 What if I have these high? 13:44.520 --> 13:48.520 Which is, I hope. 13:48.520 --> 13:50.520 I hope it's interesting. 13:50.520 --> 13:54.520 And also we are considering enabling track every these bad. 13:54.520 --> 13:57.520 I hope it will be in the next Volgrins version. 13:57.520 --> 14:00.520 Well, Volgrins will track file descriptors, 14:00.520 --> 14:03.520 but it won't warn you about leaks. 14:03.520 --> 14:06.520 Also, please use Volgrins and GDP together. 14:06.520 --> 14:10.520 I think it's like, I think it's very cool. 14:11.520 --> 14:12.520 Next. 14:12.520 --> 14:15.520 Thank you for your attention. 14:15.520 --> 14:16.520 I'd. 14:24.520 --> 14:27.520 So I have a list of articles I wrote. 14:27.520 --> 14:29.520 If anybody's interested. 14:29.520 --> 14:31.520 It's about Volgrins and GDP. 14:34.520 --> 14:36.520 I have a question. 14:36.520 --> 14:38.520 Go. 14:39.520 --> 14:42.520 So the file descriptors are per process. 14:42.520 --> 14:43.520 Yes. 14:43.520 --> 14:47.520 And so basically those opening file descriptors close in them. 14:47.520 --> 14:48.520 And so on. 14:48.520 --> 14:50.520 It's a dynamic event. 14:50.520 --> 14:55.520 And I assume the background is actually following the execution and recording the execution. 14:55.520 --> 14:56.520 Yes. 14:56.520 --> 15:00.520 The system calls, involved by all and every thread in the process. 15:00.520 --> 15:01.520 Yes. 15:01.520 --> 15:07.520 So how does that work along with GDP when it's not working in a non-stop mode, for example? 15:07.520 --> 15:08.520 Yeah. 15:08.520 --> 15:09.520 I haven't tried. 15:09.520 --> 15:11.520 No, but. 15:11.520 --> 15:12.520 I mean. 15:12.520 --> 15:16.520 So because can ball grind integrated in GDP work in a stop mode, 15:16.520 --> 15:17.520 sorry, now. 15:17.520 --> 15:20.520 Or you have to run GDP in a stop mode. 15:20.520 --> 15:21.520 I don't know. 15:21.520 --> 15:23.520 I have a choice. 15:23.520 --> 15:24.520 No. 15:24.520 --> 15:25.520 I don't know. 15:25.520 --> 15:27.520 I don't know. 15:27.520 --> 15:28.520 Yeah. 15:28.520 --> 15:29.520 Stop. 15:29.520 --> 15:31.520 I don't know. 15:31.520 --> 15:32.520 No. 15:32.520 --> 15:33.520 No. 15:33.520 --> 15:34.520 It's not a big problem. 15:34.520 --> 15:36.520 It doesn't even support it, I think. 15:37.520 --> 15:38.520 Yeah. 15:38.520 --> 15:40.520 We would have to try. 15:40.520 --> 15:42.520 Maybe I'll try tomorrow. 15:42.520 --> 15:43.520 Or today. 15:43.520 --> 15:44.520 No. 15:44.520 --> 15:45.520 That's right. 15:45.520 --> 15:46.520 I do. 15:46.520 --> 15:47.520 I do. 15:47.520 --> 15:48.520 I do. 15:48.520 --> 15:49.520 I do. 15:49.520 --> 15:50.520 I do. 15:50.520 --> 15:51.520 I do. 15:51.520 --> 15:52.520 I do. 15:52.520 --> 15:53.520 I do. 15:53.520 --> 15:54.520 I do. 15:54.520 --> 15:55.520 I do. 15:55.520 --> 15:56.520 I do. 15:56.520 --> 15:57.520 I do. 15:57.520 --> 15:58.520 I do. 15:58.520 --> 15:59.520 I do. 15:59.520 --> 16:00.520 I do. 16:00.520 --> 16:01.520 I do. 16:01.520 --> 16:02.520 I do. 16:02.520 --> 16:03.520 I do. 16:03.520 --> 16:06.560 The other word would have support the non stop, 16:06.560 --> 16:08.520 bearing of the fold of all. 16:08.520 --> 16:09.520 I think it does. 16:09.520 --> 16:10.520 No. 16:10.520 --> 16:11.520 Not. 16:11.520 --> 16:12.520 Doesn't it work? 16:12.520 --> 16:13.520 Does it always? 16:13.520 --> 16:18.520 Does it, does it make sense for it to work,eyone thinks so? 16:18.520 --> 16:19.520 What is it? 16:19.520 --> 16:20.520 I don't know. 16:20.520 --> 16:21.520 OK. 16:21.520 --> 16:23.520 Another question. 16:23.520 --> 16:26.520 There should people address questions upon butches. 16:26.520 --> 16:30.520 Why is this developed on the Balt supervisor on the GDP side? 16:30.520 --> 16:31.520 On bombs side. 16:31.520 --> 16:32.520 On Douggrimer employees list. 16:32.520 --> 16:36.520 Yeah, so you can use a well-great user's list. 16:36.520 --> 16:37.520 Yes? 16:46.520 --> 16:47.520 Fine. 16:49.520 --> 16:51.520 If you do that? 17:02.520 --> 17:03.520 Yeah. 17:27.520 --> 17:29.520 It will take time, yes. 17:30.520 --> 17:31.520 Hi, yeah. 17:31.520 --> 17:33.520 So we're at the end of this call. 17:33.520 --> 17:35.520 And yes, well-grained. 17:35.520 --> 17:37.520 If you have many calls that are opening 17:37.520 --> 17:40.520 for all the scriptures and you will enable this option, 17:40.520 --> 17:43.520 then yes, it will go slow down. 17:43.520 --> 17:45.520 And you know, I'm not talking about 17:45.520 --> 17:49.520 run, I'm talking about the delay 17:49.520 --> 17:52.520 until a news is called 17:52.520 --> 17:56.520 and of being supported by 17:56.520 --> 17:58.520 Linux ads and users. 17:58.520 --> 18:03.520 I mean, I mean, do you Prefer, 18:03.520 --> 18:09.800 consider the BPM scan in the sana or the 18:09.800 --> 18:13.160 chip interface, sign up Translate. 18:13.160 --> 18:16.520 My assumption was previously vibrant in the app and now that. 18:16.520 --> 18:18.680 Okay, so it's possible that there aren't 18:18.680 --> 18:22.080 useless calls, I'm not aware about it and 18:22.080 --> 18:25.120 that I haven't picked Adept yet. 18:25.120 --> 18:26.120 It's possible, yes. 18:26.120 --> 18:31.120 There are a lot of things, but it is in front of me, 18:31.120 --> 18:34.120 but I don't want to remove that out. 18:34.120 --> 18:38.120 So almost every system, 18:38.120 --> 18:42.120 things, memory, or it gets memory back then, 18:42.120 --> 18:44.120 it gets to affect that. 18:44.120 --> 18:47.120 So we have to support all systems. 18:47.120 --> 18:50.120 There's nothing making the work. 18:50.120 --> 19:00.120 Yeah. 19:00.120 --> 19:06.120 The option that you use to specify which kind of, 19:06.120 --> 19:08.120 in the track, yes. 19:08.120 --> 19:10.120 So that's the local variant. 19:10.120 --> 19:12.120 So the option can combine. 19:12.120 --> 19:13.120 What can you get? 19:13.120 --> 19:15.120 Can you use high and bad at the same time? 19:15.120 --> 19:16.120 Not yet. 19:16.120 --> 19:19.120 But logically, it should be possible. 19:19.120 --> 19:33.120 Yeah, but we want to use bad with all, right? 19:33.120 --> 19:34.120 Yeah. 19:34.120 --> 19:36.120 The modifying. 19:36.120 --> 19:41.120 You're too kind to be making a track in there. 19:41.120 --> 19:45.120 So you can't, you can't, you can't 19:45.120 --> 19:47.120 mix modify with track. 19:47.120 --> 19:49.120 And when you're using track, every bad, 19:49.120 --> 19:53.120 you don't want to use all because bad prevents you from 19:53.120 --> 19:55.120 showing me leaks. 19:55.120 --> 19:59.120 And all is about showing you that you have leaked 19:59.120 --> 20:02.120 standard in out and error. 20:02.120 --> 20:04.120 So it doesn't make sense. 20:04.120 --> 20:09.120 Yeah, but the high is modify of these, 20:09.120 --> 20:11.120 which is a different option. 20:11.120 --> 20:12.120 Sorry. 20:16.120 --> 20:18.120 Yes? 20:18.120 --> 20:19.120 Yes. 20:19.120 --> 20:20.120 I forgot. 20:20.120 --> 20:22.120 So this is nice to have been bothering, 20:22.120 --> 20:24.120 but I think in principle, you could implement 20:24.120 --> 20:26.120 these even with B-trace. 20:26.120 --> 20:27.120 Do you want to hear? 20:27.120 --> 20:28.120 Yes. 20:28.120 --> 20:29.120 By the way, not. 20:29.120 --> 20:32.120 It's just implemented with B-trace. 20:32.120 --> 20:35.120 You don't get the tight integrated B-trace. 20:35.120 --> 20:37.120 And I think that's the bigger one. 20:37.120 --> 20:39.120 It's of this approach. 20:39.120 --> 20:40.120 Yeah. 20:41.120 --> 20:42.120 Thank you. 20:44.120 --> 20:46.120 Hey, I think that's all. 20:46.120 --> 20:48.120 Thank you for your attention.