whizard is hosted by Hepforge, IPPP Durham
close Warning: Error with navigation contributor "BrowserModule"

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#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)

test.sin (1.0 KB) - added by Christian Speckner 15 years ago.
valgrind.log (24.7 KB) - added by Christian Speckner 15 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 15 years ago by Christian Speckner

Milestone: v2.0.2

Changed 15 years ago by Christian Speckner

Attachment: test.sin added

Changed 15 years ago by Christian Speckner

Attachment: valgrind.log added

comment:2 Changed 15 years ago by Christian Speckner

Resolution: invalid
Status: newclosed

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 the state_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 local beam_data, then the polarization in the global beam_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.

comment:3 Changed 15 years ago by Christian Speckner

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.

Note: See TracTickets for help on using tickets.