JDK-8224487 : outputStream should not be copyable
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-05-21
  • Updated: 2019-10-11
  • Resolved: 2019-05-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.5Fixed 13 b22Fixed
Related Reports
Blocks :  
JDK-8224193 - stringStream should not use Resource Area
Duplicate :  
JDK-8224485 - Crash in Exceptions::log_exception() due erroneous copying of stringStream
Relates :  
JDK-8224485 - Crash in Exceptions::log_exception() due erroneous copying of stringStream
Description
outputStream should not be copyable since none of them implements copy semantics. This could be implemented, but actually it is not really needed, so to reduce complexity lets just forbid it.
Comments
Fix Request: Important to fix because: This is a prerequisite for https://bugs.openjdk.java.net/browse/JDK-8224193 and https://bugs.openjdk.java.net/browse/JDK-8225225, both which are important to fix. This, in itself, will not fix any existing bugs but prevent new bugs. Nature of fix: This fix makes copy/assignment of outputStream child classes unaccessible. This prevents errors where one were to copy a stringStream object accidentally (e.g. confusing pass-by-value and pass-by-reference), which may lead to double frees in the context of JDK-8224193. Low risk because: All this fix does is to prevent calling copy or assignment on outputStream child classes. If it builds, it works. Backport RFR discussion: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001274.html Testing: All the SAP nightlies went through (tck, jtreg, gtests)
24-06-2019
This issue is a prerequisite of JDK-8224193.
21-05-2019
Hmm. I do not see the point of keeping this a ResourceObj if it does not get used as such but maybe I do not understand the roles here: - StackObj cannot be new()ed at all - CHeapObj can be new()ed and will by default live in C-Heap but it can also live on the stack. - ResourceObj can be new()ed and will by default live in RA but can also be new()ed to C heap and can also live on stack. This is counterintuitive - I would have expected this to be more descriptive. The way it is now, a ResourceObj is actually least restricting, it can live anywhere. But anyway the important part was forbidding to copy streams so I removed the ResourceObj part of the issue.
21-05-2019
But ResourceObj can also be allocated in the C_HEAP and that is needed for the global outputStream ie tty void ostream_init() { if (defaultStream::instance == NULL) { defaultStream::instance = new(ResourceObj::C_HEAP, mtInternal) defaultStream(); tty = defaultStream::instance; Further ResourceObj's can be stack-allocated as well.
21-05-2019