Bug: Zero-Sized Reads Should Never Fail #3459
Assignees
Milestone
Comments
|
This has might been resolved in https://github.com/ornladios/ADIOS2/pull/3542/files |
|
@vicentebolea That is what I hope as well. @ax3l could you try adios v2.9 or tell me what code to run to reproduce this? |
|
Sorry for moving so fast and referencing deeply nested. I was going down a rabbit hole of bugs when I saw this, while patching through 3+ repos. More a memo to myself: |
|
@pnorbert @vicentebolea @anagainaru generally, shall we add a general test to ADIOS2 for zero-write blocks with and w/o compression? This is a pretty common corner case for us and can easily break :) X-ref: |
Validation Steps
$ bpls -D ...
...
double /data/10/particles/electrons/position/z {68368}
step 0:
block 0: [null ]
block 1: [null ]
block 2: [null ]
block 3: [null ]
block 4: [null ]
block 5: [null ]
block 6: [null ]
block 7: [null ]
block 8: [null ]
block 9: [null ]
block 10: [34710:42094]
block 11: [null ]
block 12: [50810:60201]
block 13: [null ]
block 14: [null ]
block 15: [18040:26991]
block 16: [26992:34709]
block 17: [null ]
block 18: [null ]
block 19: [null ]
block 20: [null ]
block 21: [null ]
block 22: [null ]
block 23: [null ]
block 24: [null ]
block 25: [null ]
block 26: [null ]
block 27: [null ]
block 28: [null ]
block 29: [null ]
block 30: [null ]
block 31: [null ]
block 32: [null ]
block 33: [null ]
block 34: [null ]
block 35: [null ]
block 36: [null ]
block 37: [null ]
block 38: [null ]
block 39: [42095:50809]
block 40: [null ]
block 41: [60202:68367]
block 42: [ 9840:18039]
block 43: [null ]
block 44: [null ]
block 45: [null ]
block 46: [null ]
block 47: [null ]
block 48: [null ]
block 49: [ 0: 9839]
block 50: [null ]
block 51: [null ]
block 52: [null ]
block 53: [null ]
block 54: [null ]
block 55: [null ]
block 56: [null ]
...
double /data/10/particles/electrons_n/position/z {8781}
step 0:
block 0: [null ]
block 1: [8488:8780]
block 2: [null ]
block 3: [null ]
block 4: [null ]
block 5: [ 0:8487]
block 6: [null ]
block 7: [null ]
block 8: [null ]
...Resultpython3 -X faulthandler -c 'from openpmd_viewer.addons import LpaDiagnostics; ts_bp = LpaDiagnostics("diag1/"); print(ts_bp.get_particle(species="electrons", var_list=["charge", "id", "mass", "theta", "x", "y", "z", "ux", "uy", "uz", "w"], iteration=10))'This still segfaults here: Calling into here: @franzpoeschel this might be us now? Gotta recompile w/ debug symbols. Follow-UpCan we nonetheless add a read test to ADIOS2 CI to make sure NULL-blocks will always work? I would like to cover:
|
|
Backtrace with debug symbols in openPMD-api... might be in ADIOS2 after all. Oh... do I need to test this with ADIOS2 post-2.9.1-master...? got it... |
There is a ticket for this at #3792 |
|
Thanks. Testing again with ADIOS2 Still a segfault, but I think it might be openPMD-api internal now 🎉 As of openPMD-api 0.15.2: In:
with a bit printf debugging: Removing the
|
#3 0x00007fffc1a5aa0d in std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator() (
this=0x7fffc2118ba0 <openPMD::detail::fromADIOS2Type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)::map>, __x=<error: Cannot access memory at address 0x700d365c8>,
__y="uint64_t") at /usr/include/c++/11/bits/stl_function.h:400Value |
|
Anyone has any update on this? Is this still an issue with the master branch? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In ADIOS 2.8.3, requesting to read a zero-size of data from a NULL block segfaults.
This should be made more robust.
attn @pnorbert @guj
cc @franzpoeschel
X-Ref:
The text was updated successfully, but these errors were encountered: