Crash when writing parallel compressed chunks


#1

I’m finding crashes when I try to write compressed datasets in parallel with the MPIO driver. I have produced a (fairly simple) test case to reproduce the issues I’m having. As I can’t upload attachments (new user) I’ve made a gist here: https://gist.github.com/jrs65/97e36592785d3db2729a8ed20521eaa6

The test does the following things:

  1. Creates a file with the MPIO driver
  2. Creates a 2D chunked dataset with gzip compression (chunks evenly split the dataset into 4x32 chunks)
  3. Collectively writes random data into it (distributed across the first axis). This means each rank will write across one chunk in the first dimension and 32 whole chunks in the second.
  4. Creates a second dataset (identical) except for the name
  5. Writes more random data into the new dataset

When running on 4 MPI processes the first two ranks exit attempting step 4 with the traceback (I’ve trimmed to just the end):

  #015: H5Dchunk.c line 4727 in H5D__chunk_collective_fill(): unable to write raw data to file
    major: Low-level I/O
    minor: Write failed
  #016: H5Fio.c line 165 in H5F_block_write(): write through page buffer failed
    major: Low-level I/O
    minor: Write failed
  #017: H5PB.c line 1028 in H5PB_write(): write through metadata accumulator failed
    major: Page Buffering
    minor: Write failed
  #018: H5Faccum.c line 826 in H5F__accum_write(): file write failed
    major: Low-level I/O
    minor: Write failed
  #019: H5FDint.c line 258 in H5FD_write(): driver write request failed
    major: Virtual File Layer
    minor: Write failed
  #020: H5FDmpio.c line 1807 in H5FD_mpio_write(): MPI_File_set_view failed
    major: Internal error (too specific to document in detail)
    minor: Some MPI function failed
  #021: H5FDmpio.c line 1807 in H5FD_mpio_write(): MPI_ERR_TYPE: invalid datatype
    major: Internal error (too specific to document in detail)
    minor: MPI Error String
    minor: Write failed
  #019: H5FDint.c line 258 in H5FD_write(): driver write request failed
    major: Virtual File Layer
    minor: Write failed
  #020: H5FDmpio.c line 1807 in H5FD_mpio_write(): MPI_File_set_view failed
    major: Internal error (too specific to document in detail)
    minor: Some MPI function failed
  #021: H5FDmpio.c line 1807 in H5FD_mpio_write(): MPI_ERR_TYPE: invalid datatype
    major: Internal error (too specific to document in detail)
    minor: MPI Error String

The crashes only occur under certain conditions, which are set in the test case.

  1. There must be two datasets created, one is not enough.
  2. The second dataset crashes only if an actual write is performed to the first.
  3. The write must be large enough. By that I mean two things I’ve tested
  • The dataset larger than some size I haven’t well determined
  • The actual data written must be complex. i.e. writing zeros (which compress too well) does not cause a crash
  1. The chunk size must be smaller than the write selection size by some undetermined amount. Reducing the size by powers of two, only causes a crash when the chunk size is 32x smaller than the total write selection size if the dataset size along the long dimension is 2^20, but 16x if it is 64.

I’ve tested this in HDF5 1.10.5 using OpenMPI 4.0.1, it crashes using either ompio or romio as the MPIO backends. I have reproduced this issue on both macOS and Linux.

The test case I’ve attached is in C. I originally found the issue when using h5py, and I found exactly the same issue using both the h5py high and low level interfaces. If it’s any use, I could supply those test cases too, though I think I’ve faithfully translated it into the C API.

I think this is a bug, although it’s possible I’m attempting an IO pattern which is not supported and is not caught cleanly, in which case I’d very much appreciate any guidance about what is possible, the documentation for writing filtered parallel datasets is not very clear.

Thanks!


#2

Hi @jrichardshaw,

is it possible that you might have two different versions of OpenMPI in your system path that might be conflicting with one another in terms of what HDF5 was built with and what’s getting loaded when running the application? I quickly tried this under Linux using combinations of HDF5 1.10.5 and the development branch, along with OpenMPI 3.0.0 and 4.0.1 and all combinations seemed to work just fine.


#3

Hi @jhenderson, thanks for your help.

I’m fairly sure my environment is clean. I’m running both on my local macOS laptop and on a Linux cluster reproducing the same issue, and on the latter I’ve been careful with my module environment.

With all that said, I couldn’t reproduce the issue on the Linux cluster with the exact file I sent you. That one failed reliably on macOS, but on Linux I needed to increase the size to be much larger (apologies). If you can, try changing the definition of LONGSIZE to (1 << 20) - I’ve also updated the gist accordingly. This is reliably reproducing the issue on the cluster. On my local machine I could get away with it being only 128 and it still worked, but there must be some platform/config difference that’s causing issues.

I just built and ran with a very naive:

$ h5pcc -g -o testh5 test_ph5.c
$ mpirun -np 4 ./testh5

I’ll try and check a few more environments later this afternoon to double check how widely I can reproduce it.


#4

As a quick check in the meantime, I’ve just checked that my HDF5 build and environment agree with what OpenMPI installation they are using (using ldd for the former, and checking the mpirun path for the latter), and they do. So I don’t think a mismatch is causing any problems. Thanks!


#5

Hmm, entertainingly enough even the latest gist appears to pass with each of my separate builds. Perhaps I need to keep increasing the size until I see a problem. One key thing that I’ve noticed with the feature is that users have tended to expose the bugs with it by repeatedly performing a dataset write over and over, sometimes nearly a hundred times before an issue occurs. For example, a bug was exposed recently with an MPI communicator handle not being freed, but it only occurred once all available handles were taken up after several writes.


#6

I’ve just checked with my colleague Tristan, and got him to reproduce this issue on his own machine with the test code above. He’s running Arch, and has OpenMPI 4.0.1 and HDF5 1.10.5 installed as well.

Do you have a standard environment you use for testing parallel HDF5? I can attempt to find a way of reproducing it in that environment if you do.

Thanks!


#7

Hi, @jrichardshaw
I tested your program using MPICH 3.3 and HDF5 1.10.5. I got a similar error message below which gives more detailed information.
" #021: …/…/hdf5-1.10.5/src/H5FDmpio.c line 1807 in H5FD_mpio_write(): Other I/O error , error stack:
ADIO_Set_view(48): **iobadoverlap displacements of filetype must be in a monotonically nondecreasing order"

This error was reported from MPI library, meaning the MPI datatype created by HDF5 internally and used in MPI_File_set_view is violating the MPI standard requirement that the flattened file offsets must be monotonically nondecreasing. I believe OpenMPI also does the same checking and returns an error.


#8

@wkliao This information actually seems to correspond with a known issue that has cropped up in the past but was notoriously difficult to reproduce. @jrichardshaw As far as a ‘standard environment’ for testing, in general I just use a fairly normal CentOS 6/7 system for testing parallel HDF5. Could you or @wkliao try building a debug version of HDF5 with asserts enabled? If you do this, then you should see an assertion failure like the following:

H5Dchunk.c:4876: H5D__chunk_collective_fill: Assertion `chunk_disp_array[i] > chunk_disp_array[i - 1]' failed.

If this is the case, then we are definitely aware of the issue but have not yet made efforts towards fixing it. It is, however, affecting another feature and this could help make the issue a higher priority.


#9

@jhenderson
I tested again with the debug version of HDF5 and got the exact error message you mentioned. My test machine is a Redhat Enterprise 6.10.


#10

@wkliao and @jrichardshaw, could you try the attached patch I generated against the 1.10.5 release branch? Note that it’s a quick hack, so I wouldn’t consider it production quality or anything, but I’m interested to see if this approach fixes the issue that you’re encountering.

H5Dchunk_assertion.patch (1.6 KB)


#11

Was able to reproduce this issue on AWS based HPC cluster 3 nodes x m5d.2xlarge:

  • Open MPI: 4.1.0a1
  • HDF5 Version: 1.11.6 Default API mapping: v112
  • slurm 19.05.1-2
  • pmix: 3.1.3rc4
  • 3 nodes x m5d.2xlarge AWS instance

error message of srun -n 4 ./testh5

[master:06075] Read -1, expected 11776, errno = 38
[master:06076] Read -1, expected 11776, errno = 38
[master:06075] Read -1, expected 11776, errno = 38
[node01:06103] Read -1, expected 11776, errno = 38
testh5: H5Dchunk.c:4876: H5D__chunk_collective_fill: Assertion `chunk_disp_array[i] > chunk_disp_array[i - 1]' failed.
testh5: H5Dchunk.c:4876: H5D__chunk_collective_fill: Assertion `chunk_disp_array[i] > chunk_disp_array[i - 1]' failed.
[master:06076] *** Process received signal ***
[master:06075] *** Process received signal ***
[master:06075] Signal: Aborted (6)
[master:06075] Signal code:  (-6)
[master:06076] Signal: Aborted (6)
[master:06076] Signal code:  (-6)
[master:06076] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f70719d7890]
[master:06075] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f3b22f97890]
[master:06075] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f3b22bd2e97]
[master:06076] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f7071612e97]
[master:06075] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f3b22bd4801]
[master:06076] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f7071614801]
[master:06075] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f3b22bc439a]
[master:06076] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f707160439a]
[master:06075] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f3b22bc4412]
[master:06076] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f7071604412]
[master:06076] [ 5] /home/steven/./testh5(+0x38a643)[0x5601833dd643]
[master:06075] [ 5] /home/steven/./testh5(+0x38a643)[0x55ae770de643]
[master:06076] [ 6] /home/steven/./testh5(+0x398646)[0x5601833eb646]
[master:06076] [ 7] /home/steven/./testh5(+0x9b08a)[0x5601830ee08a]
[master:06076] [ 8] /home/steven/./testh5(+0xa04ea)[0x5601830f34ea]
[master:06076] [ 9] /home/steven/./testh5(+0xa922f)[0x5601830fc22f]
[master:06076] [10] /home/steven/./testh5(+0x99e16)[0x5601830ece16]
[master:06075] [ 6] /home/steven/./testh5(+0x398646)[0x55ae770ec646]
[master:06075] [ 7] /home/steven/./testh5(+0x9b08a)[0x55ae76def08a]
[master:06075] [ 8] /home/steven/./testh5(+0xa04ea)[0x55ae76df44ea]
[master:06075] [ 9] /home/steven/./testh5(+0xa922f)[0x55ae76dfd22f]
[master:06075] [10] /home/steven/./testh5(+0x99e16)[0x55ae76dede16]
[master:06076] [11] /home/steven/./testh5(+0x9c4e5)[0x5601830ef4e5]
[master:06076] [12] /home/steven/./testh5(+0x3ad615)[0x560183400615]
[master:06076] [13] /home/steven/./testh5(+0x1b86a1)[0x56018320b6a1]
[master:06076] [14] /home/steven/./testh5(+0x17dbaa)[0x5601831d0baa]
[master:06076] [15] /home/steven/./testh5(+0x13940c)[0x56018318c40c]
[master:06076] [16] /home/steven/./testh5(+0x13a1a4)[0x56018318d1a4]
[master:06076] [17] /home/steven/./testh5(+0x176300)[0x5601831c9300]
[master:06076] [18] /home/steven/./testh5(+0x17fbaa)[0x5601831d2baa]
[master:06076] [19] /home/steven/./testh5(+0x9b70f)[0x5601830ee70f]
[master:06075] [11] /home/steven/./testh5(+0x9c4e5)[0x55ae76df04e5]
[master:06075] [12] /home/steven/./testh5(+0x3ad615)[0x55ae77101615]
[master:06075] [13] /home/steven/./testh5(+0x1b86a1)[0x55ae76f0c6a1]
[master:06075] [14] /home/steven/./testh5(+0x17dbaa)[0x55ae76ed1baa]
[master:06076] [20] /home/steven/./testh5(+0x32f193)[0x560183382193]
[master:06076] [21] /home/steven/./testh5(+0x3123d2)[0x5601833653d2]
[master:06076] [22] /home/steven/./testh5(+0x31ac7f)[0x56018336dc7f]
[master:06076] [23] /home/steven/./testh5(+0x8f358)[0x5601830e2358]
[master:06076] [24] /home/steven/./testh5(+0xd12a)[0x56018306012a]
[master:06075] [15] /home/steven/./testh5(+0x13940c)[0x55ae76e8d40c]
[master:06075] [16] /home/steven/./testh5(+0x13a1a4)[0x55ae76e8e1a4]
[master:06075] [17] /home/steven/./testh5(+0x176300)[0x55ae76eca300]
[master:06075] [18] /home/steven/./testh5(+0x17fbaa)[0x55ae76ed3baa]
[master:06075] [19] /home/steven/./testh5(+0x9b70f)[0x55ae76def70f]
[master:06076] [25] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f70715f5b97]
[master:06076] [26] /home/steven/./testh5(+0xcbea)[0x56018305fbea]
[master:06076] *** End of error message ***
[master:06075] [20] /home/steven/./testh5(+0x32f193)[0x55ae77083193]
[master:06075] [21] /home/steven/./testh5(+0x3123d2)[0x55ae770663d2]
[master:06075] [22] /home/steven/./testh5(+0x31ac7f)[0x55ae7706ec7f]
[master:06075] [23] /home/steven/./testh5(+0x8f358)[0x55ae76de3358]
[master:06075] [24] /home/steven/./testh5(+0xd12a)[0x55ae76d6112a]
[master:06075] [25] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f3b22bb5b97]
[master:06075] [26] /home/steven/./testh5(+0xcbea)[0x55ae76d60bea]
[master:06075] *** End of error message ***
--------------------------------------------------------------------------
An MPI communication peer process has unexpectedly disconnected.  This
usually indicates a failure in the peer process (e.g., a crash or
otherwise exiting without calling MPI_FINALIZE first).

Although this local MPI process will likely now behave unpredictably
(it may even hang or crash), the root cause of this problem is the
failure of the peer -- that is what you need to investigate.  For
example, there may be a core file that you can examine.  More
generally: such peer hangups are frequently caused by application bugs
or other external events.

  Local host: node01
  Local PID:  6103
  Peer host:  master
--------------------------------------------------------------------------
--------------------------------------------------------------------------
An MPI communication peer process has unexpectedly disconnected.  This
usually indicates a failure in the peer process (e.g., a crash or
otherwise exiting without calling MPI_FINALIZE first).

Although this local MPI process will likely now behave unpredictably
(it may even hang or crash), the root cause of this problem is the
failure of the peer -- that is what you need to investigate.  For
example, there may be a core file that you can examine.  More
generally: such peer hangups are frequently caused by application bugs
or other external events.

  Local host: node01
  Local PID:  6104
  Peer host:  master
--------------------------------------------------------------------------
srun: error: master: tasks 0-1: Aborted
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
srun: error: node01: tasks 2-3: Killed

#12

@jhenderson I’ve applied and tested your patch against HDF 1.10.5, and while it doesn’t crash it now hangs at the same stage. What seems to be happening is that the nodes have gotten out of sync and some hit an MPI section, and others didn’t. I’ve taken stack traces of each process and put them below, apologies for the verbose dump!

Updated with debugging output

Rank 0 (rank 1 is very similar, with just a deeper set of msort calls, probably dependent on when I sample):

#0  0x00007f42cd583b60 in memcpy@GLIBC_2.2.5 () from /cvmfs/soft.computecanada.ca/nix/store/63pk88rnmkzjblpxydvrmskkc8ci7cx6-glibc-2.24/lib/libc.so.6
#1  0x00007f42cd534ce2 in msort_with_tmp.part.0 () from /cvmfs/soft.computecanada.ca/nix/store/63pk88rnmkzjblpxydvrmskkc8ci7cx6-glibc-2.24/lib/libc.so.6
#2  0x00007f42cd534cf8 in msort_with_tmp.part.0 () from /cvmfs/soft.computecanada.ca/nix/store/63pk88rnmkzjblpxydvrmskkc8ci7cx6-glibc-2.24/lib/libc.so.6
#3  0x00007f42cd534ce2 in msort_with_tmp.part.0 () from /cvmfs/soft.computecanada.ca/nix/store/63pk88rnmkzjblpxydvrmskkc8ci7cx6-glibc-2.24/lib/libc.so.6
#4  0x00007f42cd53524f in qsort_r () from /cvmfs/soft.computecanada.ca/nix/store/63pk88rnmkzjblpxydvrmskkc8ci7cx6-glibc-2.24/lib/libc.so.6
#5  0x00000000004df4f0 in H5D__chunk_collective_fill (dset=0x1d66dc0, chunk_info=0x7ffe63a73530, chunk_size=531, fill_buf=0x1eb8ac0) at H5Dchunk.c:4683
#6  0x00000000004de2f6 in H5D__chunk_allocate (io_info=0x7ffe63a73b80, full_overwrite=false, old_dim=0x7ffe63a739d0) at H5Dchunk.c:4402
#7  0x000000000050fdaf in H5D__init_storage (io_info=0x7ffe63a73b80, full_overwrite=false, old_dim=0x7ffe63a739d0) at H5Dint.c:2421
#8  0x000000000050f7ea in H5D__alloc_storage (io_info=0x7ffe63a73b80, time_alloc=H5D_ALLOC_CREATE, full_overwrite=false, old_dim=0x0) at H5Dint.c:2334
#9  0x000000000051cb6b in H5D__layout_oh_create (file=0x1d534b0, oh=0x1db43f0, dset=0x1d66dc0, dapl_id=720575940379279367) at H5Dlayout.c:507
#10 0x000000000050938b in H5D__update_oh_info (file=0x1d534b0, dset=0x1d66dc0, dapl_id=720575940379279367) at H5Dint.c:976
#11 0x000000000050aa0d in H5D__create (file=0x1d534b0, type_id=216172782113783850, space=0x1d57bf0, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5Dint.c:1277
#12 0x000000000093059d in H5O__dset_create (f=0x1d534b0, _crt_info=0x7ffe63a748d0, obj_loc=0x7ffe63a73f80) at H5Doh.c:299
#13 0x00000000006b6519 in H5O_obj_create (f=0x1d534b0, obj_type=H5O_TYPE_DATASET, crt_info=0x7ffe63a748d0, obj_loc=0x7ffe63a73f80) at H5Oint.c:2452
#14 0x000000000065e722 in H5L__link_cb (grp_loc=0x7ffe63a74640, name=0x7ffe63a741a0 "dset2", lnk=0x0, obj_loc=0x0, _udata=0x7ffe63a747c0, own_loc=0x7ffe63a745ac) at H5L.c:1603
#15 0x00000000005f6a2e in H5G__traverse_real (_loc=0x7ffe63a74980, name=0x97c9ee "dset2", target=0, op=0x65e406 <H5L__link_cb>, op_data=0x7ffe63a747c0) at H5Gtraverse.c:626
#16 0x00000000005f78a1 in H5G_traverse (loc=0x7ffe63a74980, name=0x97c9ee "dset2", target=0, op=0x65e406 <H5L__link_cb>, op_data=0x7ffe63a747c0) at H5Gtraverse.c:850
#17 0x000000000065f30d in H5L__create_real (link_loc=0x7ffe63a74980, link_name=0x97c9ee "dset2", obj_path=0x0, obj_file=0x0, lnk=0x7ffe63a74850, ocrt_info=0x7ffe63a748f0, lcpl_id=720575940379279374) at H5L.c:1797
#18 0x000000000065e3a8 in H5L_link_object (new_loc=0x7ffe63a74980, new_name=0x97c9ee "dset2", ocrt_info=0x7ffe63a748f0, lcpl_id=720575940379279374) at H5L.c:1556
#19 0x0000000000505f0d in H5D__create_named (loc=0x7ffe63a74980, name=0x97c9ee "dset2", type_id=216172782113783850, space=0x1d57bf0, lcpl_id=720575940379279374, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5Dint.c:328
#20 0x00000000004bf947 in H5Dcreate2 (loc_id=72057594037927936, name=0x97c9ee "dset2", type_id=216172782113783850, space_id=288230376151711746, lcpl_id=720575940379279374, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5
D.c:144
#21 0x0000000000404003 in main (argc=1, argv=0x7ffe63a74b98) at test_ph5.c:81

Rank 2 (again rank 3 similar):

#0  0x00007f4db850bb46 in psm2_mq_ipeek2 () from /cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09/lib/libpsm2.so.2
#1  0x00007f4db8757409 in ompi_mtl_psm2_progress () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/openmpi/mca_mtl_psm2.so
#2  0x00007f4dbd0a4e0b in opal_progress () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libopen-pal.so.40
#3  0x00007f4dbdc46435 in ompi_request_default_wait () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#4  0x00007f4dbdca6303 in ompi_coll_base_sendrecv_actual () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#5  0x00007f4dbdca6739 in ompi_coll_base_allreduce_intra_recursivedoubling () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#6  0x00007f4dbdc5a5b8 in PMPI_Allreduce () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#7  0x00007f4dbdd2aafc in mca_io_romio_dist_MPI_File_set_view () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#8  0x00007f4dbdcfa9ab in mca_io_romio321_file_set_view () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#9  0x00007f4dbdc6ad68 in PMPI_File_set_view () from /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/gcc8/openmpi/4.0.1/lib/libmpi.so.40
#10 0x000000000090aa05 in H5FD_mpio_write (_file=0x2aee1d0, type=H5FD_MEM_DRAW, dxpl_id=720575940379279368, addr=0, size=1, buf=0x2c52b20) at H5FDmpio.c:1806
#11 0x00000000005b6669 in H5FD_write (file=0x2aee1d0, type=H5FD_MEM_DRAW, addr=0, size=1, buf=0x2c52b20) at H5FDint.c:257
#12 0x0000000000933e3b in H5F__accum_write (f=0x2aee360, map_type=H5FD_MEM_DRAW, addr=0, size=1, buf=0x2c52b20) at H5Faccum.c:825
#13 0x000000000073df2c in H5PB_write (f=0x2aee360, type=H5FD_MEM_DRAW, addr=0, size=1, buf=0x2c52b20) at H5PB.c:1027
#14 0x00000000005885f4 in H5F_block_write (f=0x2aee360, type=H5FD_MEM_DRAW, addr=0, size=1, buf=0x2c52b20) at H5Fio.c:164
#15 0x00000000004dfa65 in H5D__chunk_collective_fill (dset=0x2b012e0, chunk_info=0x7ffc343d85a0, chunk_size=531, fill_buf=0x2c52b20) at H5Dchunk.c:4731
#16 0x00000000004de2f6 in H5D__chunk_allocate (io_info=0x7ffc343d8bf0, full_overwrite=false, old_dim=0x7ffc343d8a40) at H5Dchunk.c:4402
#17 0x000000000050fdaf in H5D__init_storage (io_info=0x7ffc343d8bf0, full_overwrite=false, old_dim=0x7ffc343d8a40) at H5Dint.c:2421
#18 0x000000000050f7ea in H5D__alloc_storage (io_info=0x7ffc343d8bf0, time_alloc=H5D_ALLOC_CREATE, full_overwrite=false, old_dim=0x0) at H5Dint.c:2334
#19 0x000000000051cb6b in H5D__layout_oh_create (file=0x2aee360, oh=0x2b4dac0, dset=0x2b012e0, dapl_id=720575940379279367) at H5Dlayout.c:507
#20 0x000000000050938b in H5D__update_oh_info (file=0x2aee360, dset=0x2b012e0, dapl_id=720575940379279367) at H5Dint.c:976
#21 0x000000000050aa0d in H5D__create (file=0x2aee360, type_id=216172782113783850, space=0x2af2790, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5Dint.c:1277
#22 0x000000000093059d in H5O__dset_create (f=0x2aee360, _crt_info=0x7ffc343d9940, obj_loc=0x7ffc343d8ff0) at H5Doh.c:299
#23 0x00000000006b6519 in H5O_obj_create (f=0x2aee360, obj_type=H5O_TYPE_DATASET, crt_info=0x7ffc343d9940, obj_loc=0x7ffc343d8ff0) at H5Oint.c:2452
#24 0x000000000065e722 in H5L__link_cb (grp_loc=0x7ffc343d96b0, name=0x7ffc343d9210 "dset2", lnk=0x0, obj_loc=0x0, _udata=0x7ffc343d9830, own_loc=0x7ffc343d961c) at H5L.c:1603
#25 0x00000000005f6a2e in H5G__traverse_real (_loc=0x7ffc343d99f0, name=0x97c9ee "dset2", target=0, op=0x65e406 <H5L__link_cb>, op_data=0x7ffc343d9830) at H5Gtraverse.c:626
#26 0x00000000005f78a1 in H5G_traverse (loc=0x7ffc343d99f0, name=0x97c9ee "dset2", target=0, op=0x65e406 <H5L__link_cb>, op_data=0x7ffc343d9830) at H5Gtraverse.c:850
#27 0x000000000065f30d in H5L__create_real (link_loc=0x7ffc343d99f0, link_name=0x97c9ee "dset2", obj_path=0x0, obj_file=0x0, lnk=0x7ffc343d98c0, ocrt_info=0x7ffc343d9960, lcpl_id=720575940379279374) at H5L.c:1797
#28 0x000000000065e3a8 in H5L_link_object (new_loc=0x7ffc343d99f0, new_name=0x97c9ee "dset2", ocrt_info=0x7ffc343d9960, lcpl_id=720575940379279374) at H5L.c:1556
#29 0x0000000000505f0d in H5D__create_named (loc=0x7ffc343d99f0, name=0x97c9ee "dset2", type_id=216172782113783850, space=0x2af2790, lcpl_id=720575940379279374, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5Dint.c:328
#30 0x00000000004bf947 in H5Dcreate2 (loc_id=72057594037927936, name=0x97c9ee "dset2", type_id=216172782113783850, space_id=288230376151711746, lcpl_id=720575940379279374, dcpl_id=720575940379279377, dapl_id=720575940379279367) at H5D.c:144
#31 0x0000000000404003 in main (argc=1, argv=0x7ffc343d9c08) at test_ph5.c:81

Hope that’s of some use. Let me know if there’s anything more I can help test out.


#13

Also, I clearly forgot to build in debug mode. I’ll rebuild now and reattach the stack traces if they have have anything more useful in them.


#14

From those traces, it looks like rank 0 and 1 allocated chunks out of address order and got stuck in a sort loop due to a naive mistake I just spotted in the patch I uploaded. Ranks 2 and 3, however, seem to have allocated chunks in the correct address order and went on to try doing the collective chunk write. Here’s a new patch that hopefully fixes that issue.

H5Dchunk_assertion.patch (2.6 KB)

Meanwhile, I’m going to see if I can find some system we can test this on where I can get the same results. It can be a bit non-deterministic as it relies on the chunks being allocated out of order and I’m not yet certain on a way to force this condition. Thankfully, the issue seems reproducible on a wide variety of systems, so this shouldn’t be too difficult.


#15

Bingo. That patch works! Thanks @jhenderson


#16

@jhenderson as it sounded like a known bug is there a JIRA issue for this one? I just want to keep track of it so I know when it has been merged. We’re currently using a patched version and I want to know when we can move back to a released version. Thanks again!


#17

Hi @jrichardshaw,

The JIRA issue we have for this is: https://jira.hdfgroup.org/browse/HDFFV-10792.

I have a slightly revised set of changes that’s currently sitting in a PR for the HDF5 development branch, wherein we’re discussing coming up with a test/modifying what’s given here to be a test for the issue. However, I think it would be safe to assume that the fix for this issue will make it into the upcoming HDF5 release. Once that happens, we will probably need to work on assessing how much the newly-introduced sort call affects parallel performance and whether we should be trying to tackle the issue at different layers within the library so that we don’t get to the point where we need the sort.