Commit 604f0cd
RLC: a D2D UM TX entity must withdraw from the mode controller before it dies
D2DModeController::perPeerTxEntities_ holds raw pointers to RLC UM TX entity
*modules*, filed by peer when the entity learns its flow. Nothing ever removed
them, while BearerManagement::deleteLocalRlcQueues() deletes those modules on
every handover and on bearer teardown, so the registry accumulated dangling
pointers. The next registration for the same peer walks the set and calls the
virtual isEmptyingBuffer() on freed memory:
Invalid read of size 8
at D2DModeController::isEmptyingTxBuffer() D2DModeController.cc:41
by D2DModeController::registerD2DPeerTxEntity() D2DModeController.cc:18
by RlcUmTxEntityD2D<LteRlcUmTxEntity>::setFlowControlInfo()
by BearerManagement::installRlcTxSide() BearerManagement.cc:417
Address is 344 bytes inside a block of size 464 free'd
at LteRlcUmTxEntityD2D::~LteRlcUmTxEntityD2D()
by BearerManagement::deleteLocalRlcQueues() BearerManagement.cc:688
by HandoverController::deleteOldBuffers()
by HandoverController::doHandover()
Once the freed block is recycled the vptr slot reads back as 0 and the call
jumps to address 0. That is the SIGSEGV that killed lte/cars VoIP-D2D at
t~19.1s -- with no usable stack, since nothing valid is left on it.
The registration moved into the entity itself when the D2D code was split out
(it used to be done by BearerManagement for every UM entity), so the withdrawal
belongs there too, rather than putting a D2DModeController reference back into
the core RLC/RRC code. The entity records the peer it was filed under, so it
withdraws under exactly that key, and re-setting the flow re-files it. The
ModuleRefByPar is already null when the controller itself is gone, which covers
the whole-NIC teardown case.
Only reachable when entities are deleted while the simulation runs -- a
handover or a bearer teardown -- so the static scenarios never build up a stale
pointer: full fingerprint suite 182/182 PASS, CSVs unchanged.
lte/cars VoIP-D2D now runs to completion (100s) where it died in a SIGSEGV at
t~19.1s, both on this branch and on plain inet/dev. The registry has never had
a withdrawal path (the pre-split code did not either), so this is a long-
standing defect whose visible outcome depended on allocator luck.1 parent 59b8305 commit 604f0cd
3 files changed
Lines changed: 43 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
56 | 56 | | |
57 | 57 | | |
58 | 58 | | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
59 | 63 | | |
60 | 64 | | |
61 | 65 | | |
| |||
79 | 83 | | |
80 | 84 | | |
81 | 85 | | |
82 | | - | |
83 | | - | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
| 100 | + | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
84 | 106 | | |
85 | 107 | | |
86 | 108 | | |
| |||
113 | 135 | | |
114 | 136 | | |
115 | 137 | | |
| 138 | + | |
| 139 | + | |
116 | 140 | | |
117 | 141 | | |
118 | 142 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
19 | 19 | | |
20 | 20 | | |
21 | 21 | | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
22 | 33 | | |
23 | 34 | | |
24 | 35 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
23 | 23 | | |
24 | 24 | | |
25 | 25 | | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
26 | 32 | | |
27 | 33 | | |
28 | 34 | | |
| |||
0 commit comments