-
Bug
-
Resolution: Fixed
-
P2
-
hs24, hs25
-
b49
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8017749 | 8 | Zhengyu Gu | P2 | Closed | Fixed | b96 |
| JDK-8016863 | 7u60 | Zhengyu Gu | P2 | Closed | Fixed | b01 |
| JDK-8018384 | 7u45 | Zhengyu Gu | P2 | Closed | Fixed | b01 |
| JDK-8016875 | 7u40 | Zhengyu Gu | P2 | Closed | Fixed | b30 |
| JDK-8016884 | hs25 | Zhengyu Gu | P2 | Closed | Fixed | b38 |
When developing new tests for NMT I ended up with:
# Internal Error (..\..\src\share\vm\services\memSnapshot.cpp:623), pid=6180, tid=10848
# assert(new_rec->is_allocation_record()) failed: Sanity check
Zhengyu looked at it and it seems like it's a race where we end up with the wrong sequence id when one thread is releasing memory and another thread is reserving and gets the same address but they end up with incorrectly ordered sequence numbers.
# Internal Error (..\..\src\share\vm\services\memSnapshot.cpp:623), pid=6180, tid=10848
# assert(new_rec->is_allocation_record()) failed: Sanity check
Zhengyu looked at it and it seems like it's a race where we end up with the wrong sequence id when one thread is releasing memory and another thread is reserving and gets the same address but they end up with incorrectly ordered sequence numbers.
- backported by
-
JDK-8016863 NMT: reserve/release sequence id's in incorrect order due to race
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
(1 relates to)