#317 closed defect (invalid)
Memory corruption when state_matrix_init is called after state_matrix_final
Reported by: | Christian Speckner | Owned by: | kilian |
---|---|---|---|
Priority: | P4 | Milestone: | v2.0.2 |
Component: | core | Version: | 2.0.1 |
Severity: | minor | Keywords: | |
Cc: |
Description
This is a rather technical issue I stumbled over while working on the polarization stuff and which I accidentally managed to trigger in beam_data_set_polarization
. If you look at the code
subroutine beam_data_set_polarization_bp (beam_data, bp) type(beam_data_t), intent(inout) :: beam_data type(beam_polarization_t), dimension(:), intent(in) :: bp integer :: i if (size (bp) /= beam_data%n) call msg_bug ( & "beam_data_set_polarization_pol: initial state multiplicty mismatch") do i = 1, beam_data%n ! call polarization_final (beam_data%pol(i)) beam_data%pol(i) = beam_polarization2polarization & (bp(i), beam_data%flv(i)) end do call beam_data_compute_md5sum (beam_data) end subroutine beam_data_set_polarization_bp
you find that I have commented out a line which calls the polarization_t
destructor on the beam polarization before reassigning it (there is a similar thing a few lines above). Re-enabling this line causes memory corruption (and I suppose that leaving it out creates a small memory leak). As beam_polarization2polarization
returns a new, fully initialized polarization object, this should cause no harm, but it seems that the finalization and re-initialization of the state_matrix_t
contained in polarization_t
(hidden in the assignment operator) leads to memory corruption.
The corruption is not easily observable; I haven't managed to produce anything much simpler than the original sindarin example which triggered the bug and which I have attached. It is supposed to histogram the angular distribution of polarized W decays - first longitunal, then in a loop -1, 0, 1, then again longitudinal and finally unpolarized. The corruption manifests itself either as a segfault or as the fourth distribution being off; inserting density_matrix_write
into different places shows that the reassigment of the polarization inside the scan
loop in fact corrupts the polarization outside the loop, and valgrind reveals a number of access violation with reads from memory freed in polarization_final / state_matrix_final (I have attached the valgrind run). All issues disappear if I refrain from finalizing polarization_t
before reassignment.
While I believe that this currently is not an issue, this has the potential of silently corrupting density matrices, so we should try to fix this ;)
Attachments (2)
Change History (5)
comment:1 Changed 15 years ago by
Milestone: | → v2.0.2 |
---|
Changed 15 years ago by
Changed 15 years ago by
Attachment: | valgrind.log added |
---|
comment:2 Changed 15 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 Changed 15 years ago by
For the record (without reopening this ticket): after turning the beam_data_t assignment into a deep copy, I still get segfaults, but with valgrind now claiming that the memory accessed has been freed somewhere within iso_varying_string. This is obviously sick and might be a compiler issue, some deeply-hidden issue with a forgotten target attribute somewhere or even something completely different... I leave it as is for now (no deep copy), the leak is tiny and definitely better than funky memory issues, but I'll try to find the time to nail this down eventually.
OK, I dug a bit deeper into the code and found out what happens here: when the local copy of
rt_data_t
is created,beam_data
is not created as deep copy, but just as a usual FORTRAN assignment copy which will create _copies_ of thestate_matrix_t
type down along the chain with the pointer to the root node being simply carried over. If I now finalize the polarization data in the localbeam_data
, then the polarization in the globalbeam_data
is corrupted.As this is just a nasty programming pitfall and has nothing to do with the title of the ticket, I am closing it as invalid. However, still, not finalizing the polarization creates a memory leak, so I am thinking about introducing a deep copy for
beam_data_t
, but I'll have to consult WK on this.