Samuel Thibault, le dim. 27 oct. 2019 17:39:26 +0100, a ecrit: > Almudena Garcia, le dim. 27 oct. 2019 17:36:55 +0100, a ecrit: > > > And as I mentioned, cope with caller passing either the old or the new > > > value of THREAD_SCHED_INFO_COUNT in *thread_info_count > > > > > There, for backward compatibility with existing > > > binaries, you have to handle both the case where the application > > > passes the old count (built with the old GNU Mach header defining > > > THREAD_SCHED_INFO_COUNT), and the case where the application passes the > > > new count (built with the new header). > > > > I don't understand very well. Where is this? In gnumach or Hurd? > > In gnumach. > > Really, grep is an extremely powerful tool.
Actually you had already found the place since you patched it. I mean: thread_info() is passed a pointer to a buffer that it fills. The caller passes the number of items of the buffer it allocated. GNU Mach mustn't fill more than that. And it must set into *thread_info_count the actual amount being filled. Think about an old program built with the old header, running with the new GNU Mach. And then conversely a program rebuilt with the new header, running with the old GNU Mach. The first case really needs to be fixed. The second case is less of a concern, it'll just require people to make sure to upgrade mach to get procfs working correctly. That's inconvenient so ideally it should be fixed in procfs by checking that the *thread_info_count count includes the last_processor field, and if not set it to 0. Samuel
