Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix data types for CUTime and CSTime stat fields #403 #404

Merged
merged 4 commits into from Aug 30, 2021
Merged

Fix data types for CUTime and CSTime stat fields #403 #404

merged 4 commits into from Aug 30, 2021

Conversation

vykulakov
Copy link
Contributor

@vykulakov vykulakov commented Jul 29, 2021

To @SuperQ @discordianfish

These two stat fields (CUTime and CSTime) in the /proc/[pid]/stat file should have the signed long data type according to the documentation. But currently, in the code, their data type is just unsigned int. This commit fixes it and adds more tests.

See for details:

Signed-off-by: Vyacheslav Kulakov kulakov.home@gmail.com

These two stat fields (CUTime and CSTime) in the /proc/[pid]/stat file should have the signed long data type according to the documentation. But currently in the code their data type is just unsigned int. This commit fixes it and adds more tests.

See for details:
* https://man7.org/linux/man-pages/man5/proc.5.html
* https://man7.org/linux/man-pages/man3/scanf.3.html

Signed-off-by: Vyacheslav Kulakov <kulakov.home@gmail.com>
Signed-off-by: Vyacheslav Kulakov <kulakov.home@gmail.com>
Signed-off-by: Vyacheslav Kulakov kulakov.home@gmail.com
Signed-off-by: Vyacheslav Kulakov <kulakov.home@gmail.com>
Copy link
Member

@discordianfish discordianfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM!

@vykulakov
Copy link
Contributor Author

It seems I cannot merge this PR. Do we need to wait for yet another approvement?

@discordianfish
Copy link
Member

Yeah we usually need 2 LGTMs. @SuperQ can you have a look?

@SuperQ
Copy link
Member

SuperQ commented Aug 9, 2021

Hrm, we just recently changed these from int to int64 intentionally. We had issues like prometheus/node_exporter#2110.

@vykulakov
Copy link
Contributor Author

Hrm, we just recently changed these from int to int64 intentionally. We had issues like prometheus/node_exporter#2110.

@SuperQ yep, It was me who changed it to int64. But this was too much for the ignored field as they should be just unsigned, that's it. I reread the docs and found that we may be a bit more accurate with specifying data types for the fields. Also, there are tests for cases like in the issue you mentioned. So all should be fine.

Or I may just revert those types for the ignored fields to int64. But it affects nothings.

@vykulakov
Copy link
Contributor Author

@SuperQ Actually, the most important thing in the previous PR #402 was replacing int with uint for most of the ignored fields instead of replacing int with int64. I used the 64-bit versions of types because didn't know some C data types aspects that I know now. Sorry for that.

@SuperQ
Copy link
Member

SuperQ commented Aug 16, 2021

@vykulakov Ok, the only thing I'm worried about is that even tho it says one thing in the procfs docs, I did some digging into the code in the kernel. I'm not so good at C, but it seems like some of the data types are "long long", hard-coding some of these values as 64-bit. But, again, I'm no kernel expert.

@vykulakov
Copy link
Contributor Author

vykulakov commented Aug 17, 2021

@SuperQ could you point me to this place in the kernel, please? It'll save some time for me.

@SuperQ
Copy link
Member

SuperQ commented Aug 18, 2021

I think the actual print definition is https://github.com/torvalds/linux/blob/614cb2751d3150850d459bee596c397f344a7936/fs/proc/array.c#L571-L610.

Everything there is marked long long, or 64-bit. It seems like the man page is out of date compared to the kernel. Maybe the underlying data type is just a long, but it's now unconditionally printed as a long long.

This seems to be the commit that changed the output.

proc_stat.go Outdated Show resolved Hide resolved
Signed-off-by: Vyacheslav Kulakov kulakov.home@gmail.com
Signed-off-by: Vyacheslav Kulakov <kulakov.home@gmail.com>
@vykulakov
Copy link
Contributor Author

I think the actual print definition is https://github.com/torvalds/linux/blob/614cb2751d3150850d459bee596c397f344a7936/fs/proc/array.c#L571-L610.

Everything there is marked long long, or 64-bit. It seems like the man page is out of date compared to the kernel. Maybe the underlying data type is just a long, but it's now unconditionally printed as a long long.

This seems to be the commit that changed the output.

That means that all other fields get affected again. I mean on 32-bit systems most of the fields will take 4 bytes instead of 8 bytes as in that kernel change.

So this PR doesn't make much sense now as it should change all the fields instead just CUTime and CSTime.

Copy link
Member

@SuperQ SuperQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thanks!

@SuperQ SuperQ merged commit 21d221e into prometheus:master Aug 30, 2021
Comment on lines +97 to +98
{name: "waited for children user time", want: math.MinInt64, have: s.CUTime},
{name: "waited for children system time", want: math.MaxInt64, have: s.CSTime},
Copy link
Contributor

@dswarbrick dswarbrick Sep 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using MinInt64 / MaxInt64 here causes tests to fail on 32-bit archs, since these are untyped constants, being assigned to machine-native ints (in struct a few lines up).

Additionally, the supplied test data will simply overflow the ProcStat.CUTime and ProcStat.CSTime members, since they are also declared as machine-native ints. Either the struct needs to explicitly use int64 types, or you need to use 32-bit safe test data.

Incidentally, this is not the first time that there has been a test regression for 32-bit arch in this package. It would be nice if the CI pipeline would also test on 32-bit archs, as I presume they are still officially supported.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, do you want to open an issue for testing on 32 bit archs? We need to see how to make that possible (let alone who has time to work on it) but agreed that we should track that at least.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to reproduce the 32-bit test failure simply by exporting GOARCH=386 before running the tests.

remijouannet pushed a commit to remijouannet/procfs that referenced this pull request Oct 20, 2022
…etheus#404)

* Fix data types for CUTime and CSTime stat fields prometheus#403

These two stat fields (CUTime and CSTime) in the /proc/[pid]/stat file should have the signed long data type according to the documentation. But currently in the code their data type is just unsigned int. This commit fixes it and adds more tests.

See for details:
* https://man7.org/linux/man-pages/man5/proc.5.html
* https://man7.org/linux/man-pages/man3/scanf.3.html

Signed-off-by: Vyacheslav Kulakov <kulakov.home@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants