Malloc error when running latest XB

[DougP]

Hi,

I have been running XB for a while on Mac OSX, compiled with gfortran with no issues.  I recently downloaded the latest source code, compiled it with no issues but when I run it locally I get the following error just before the grid is built.

xbeach(2163) malloc: *** error for object 0x100402ac8: incorrect checksum for freed object - object was probably modified after being freed.

Previously I was using revision 2107 and it ran fine locally but from revision 2134 onwards the error occured.

I can compile and run newer models on a HPC cluster that uses the same compiler so I can't understand what's going on.

Has anyone had the same issues with recent revisions?

Cheers,

Doug

[Fedor Baart]

Hi Doug,

It looks like something is writing to unallocated memory. I usually solve these issues by running the memcheck module of valgrind. 

I'll have a look....

Cheers,

Fedor

--
You received this message because you are subscribed to the Google Groups "XBeach" group.
To view this discussion on the web visit https://groups.google.com/d/msg/xbeach/-/HN7aIZWmO-wJ.
To post to this group, send email to xbe...@googlegroups.com.
To unsubscribe from this group, send email to xbeach+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xbeach?hl=en.

[Fedor Baart]

Hi Doug,

I got the following errors. 

==42609== Invalid write of size 8

==42609==    at 0x100106AD9: __initialize_MOD_sed_init (initialize.F90:876)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609==  Address 0x10099c5a8 is 0 bytes after a block of size 8 alloc'd

==42609==    at 0x1001D41EF: malloc (vg_replace_malloc.c:236)

==42609==    by 0x1001054CB: __initialize_MOD_sed_init (initialize.F90:840)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609== 

==42609== Invalid write of size 8

==42609==    at 0x100106AFB: __initialize_MOD_sed_init (initialize.F90:877)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609==  Address 0x10099c5f8 is 0 bytes after a block of size 8 alloc'd

==42609==    at 0x1001D41EF: malloc (vg_replace_malloc.c:236)

==42609==    by 0x100105541: __initialize_MOD_sed_init (initialize.F90:841)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609== 

==42609== Invalid write of size 8

==42609==    at 0x100106B1D: __initialize_MOD_sed_init (initialize.F90:878)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609==  Address 0x10099c648 is 0 bytes after a block of size 8 alloc'd

==42609==    at 0x1001D41EF: malloc (vg_replace_malloc.c:236)

==42609==    by 0x100105716: __initialize_MOD_sed_init (initialize.F90:844)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609== 

==42609== Invalid write of size 8

==42609==    at 0x100106B3F: __initialize_MOD_sed_init (initialize.F90:879)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609==  Address 0x10099c698 is 0 bytes after a block of size 8 alloc'd

==42609==    at 0x1001D41EF: malloc (vg_replace_malloc.c:236)

==42609==    by 0x10010578C: __initialize_MOD_sed_init (initialize.F90:845)

==42609==    by 0x10015D847: main (xbeach.F90:97)

==42609== 

If I look at the shapes of the parameters being set, we can see what's going on:

    write(*,*) shape(par%D50), '->', shape(s%D50)

    write(*,*) shape(par%D90), '->', shape(s%D90)

    write(*,*) shape(par%sedcal), '->', shape(s%sedcal)

    write(*,*) size(par%ucrcal), '->', shape(s%ucrcal)

    s%D50 = par%D50

    s%D90 = par%D90

    s%sedcal = par%sedcal

    s%ucrcal = par%ucrcal

          99 ->           1

          99 ->           1

          99 ->           1

          99 ->           1

Fitting 99 numbers into 1 small piece of memory doesn't fit. 

I checked when this part was added using svn blame initialize.F90 and it seems that it was added in revision 2128

  2128     mccall     s%D50 = par%D50

  2128     mccall     s%D90 = par%D90

  2128     mccall     s%sedcal = par%sedcal

  2128     mccall     s%ucrcal = par%ucrcal

Mccall used the par version because: "D50 and D90 are already read in params.F90, no need to reread in initialize. "

The par versions however are 99 long (fixed length, not allocated). So I think the code should be:

s%D50(1:ngd) = par%D50(1:ngd) 

I changed this in revision 2152, please try it out. 

Thanks for reporting this issue.

[DougP]

Hi Fedor,

That makes sense.  The reason I updated to newer revisions was due to a warning saying D50 and D90 were not being read which I think must have been what revision 2128 fixed.

Anyway, it builds and runs fine locally now.  

Thanks for that.

Doug