On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote:
>> See the bug for more investigation.
>>
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
>> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
>> pthreads are not yet loaded. Thi
Currently, `update_copyright_year.sh` hardcodes `master` to be the base
reference. While this works on mainline and update release repos, this does not
work for projects like Valhalla or Leyden, whose PRs target lworld/premain
branches. We can add a new flag to allow customized base reference to
On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote:
>> See the bug for more investigation.
>>
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
>> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
>> pthreads are not yet loaded. Thi
On Thu, 28 Aug 2025 12:45:47 GMT, David Holmes wrote:
> Looks okay, though don't hotspot tests need the same fix in
> JtregNativeHotspot.gmk?
Hm. I have not seen any hotspot test failures, and I only did the changes that
fix the broken tests. If I understand the build files correctly, Hotspot'
On Thu, 28 Aug 2025 15:17:47 GMT, Matthias Baesken wrote:
> Recent versions of GCC have a static code analyzer option (-fanalyzer) that
> works quite well for C code (but it has still issues with C++).
> This can be used to identify e.g. some leaks like memory leaks, double close,
> use of unin
On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote:
>> See the bug for more investigation.
>>
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
>> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
>> pthreads are not yet loaded. Thi
Recent versions of GCC have a static code analyzer option (-fanalyzer) that
works quite well for C code (but it has still issues with C++).
This can be used to identify e.g. some leaks like memory leaks, double close,
use of uninitialized data etc. .
Some info about it :
https://gcc.gnu.org/onli
On Thu, 28 Aug 2025 15:17:47 GMT, Matthias Baesken wrote:
> Recent versions of GCC have a static code analyzer option (-fanalyzer) that
> works quite well for C code (but it has still issues with C++).
> This can be used to identify e.g. some leaks like memory leaks, double close,
> use of unin
On Thu, 28 Aug 2025 14:32:48 GMT, Aleksey Shipilev wrote:
> Maybe the `BUILD_JDK_JTREG_EXECUTABLES` should just do the same? Let me try...
Yes! I think that works too. And it looks better, because: a) we do not have to
whack-a-mole every executable one by one; b) this is what Hotspot jtregs is
> See the bug for more investigation.
>
> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
> pthreads are not yet loaded. This bug seems to uniquely affect custom
> launchers. We figured th
On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote:
> This is a topic that we, at Oracle, have discussed numerous times over the
> years and we have some simple guidelines that never get written down properly
> and which we/I tend to forget and then can't locate. To remedy that I would
> lik
> This changes the timeout factor from 4 to 1. Most of the changes add timeouts
> to individual test cases so that I am able to run them with a timeout factor
> of 0.7 (some margin to the checked in factor of one)
>
> In addition to changing the timeout factor, I am also using a library call to
On Thu, 28 Aug 2025 07:43:19 GMT, Aleksey Shipilev wrote:
> See the bug for more investigation.
>
> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
> pthreads are not yet loaded. This bug
On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote:
>> This changes the timeout factor from 4 to 1. Most of the changes add
>> timeouts to individual test cases so that I am able to run them with a
>> timeout factor of 0.7 (some margin to the checked in factor of one)
>>
>> In addition to cha
On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race wrote:
> > @prrace the change maintains the same absolute timeout value for those
> > tests. Before the default of 120 was multiplied by the timeoutFactor of 4
> > to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to
> > give 48
On Thu, 28 Aug 2025 07:43:19 GMT, Aleksey Shipilev wrote:
> See the bug for more investigation.
>
> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able
> to debug it to older glibc issue, which makes `dlerror` not thread-safe when
> pthreads are not yet loaded. This bug
On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi wrote:
> In this PR I propose to refresh the included headers in hotspot
> `precompiled.hpp`. The current set of precompiled headers was refreshed in
> 2018, 7 years ago. I repeated the same operations and measurements after
> refreshing the
On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshin
On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshin
See the bug for more investigation.
The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to
debug it to older glibc issue, which makes `dlerror` not thread-safe when
pthreads are not yet loaded. This bug seems to uniquely affect custom
launchers. We figured this is becaus
20 matches
Mail list logo
