A DESCRIPTION OF THE PROBLEM :
If nsenter -a -t <pid> is used in a sidecar container, it can cause a mismatch between /proc/self/cgroup and /proc/self/mountinfo (with the latter's path becoming that of the main application container). This mismatch results in a failure to parse the cgroup configuration. Got:

:/test$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintContainerInfo Test
OSContainer::init: Initializing Container Support
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
OSContainer::active_processor_count: 128
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
OSContainer::active_processor_count: 128
subsystem_file_contents: subsystem path is NULL
container memory limit failed: -2, using host value
subsystem_file_contents: subsystem path is NULL
container memory limit failed: -2, using host value
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
OSContainer::active_processor_count: 128
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
OSContainer::active_processor_count: 128
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
subsystem_file_contents: subsystem path is NULL
OSContainer::active_processor_count: 128

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
exec `nsenter -a -t <pid>` in a sidecar, then exec java applications.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Got correct processor count which limit by cgroup.
ACTUAL -
Got host machine's processor count

---------- BEGIN SOURCE ----------
Any java application.
---------- END SOURCE ----------

FREQUENCY : always