-
Notifications
You must be signed in to change notification settings - Fork 530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSEED: Segfault reading truncated file #1728
Conversation
Seems to be crashing in our code, not libmseed: 0x00007fffdda816aa in readMSEEDBuffer (mseed=0x18ffc10 "763445D BGLD EHEBW", <incomplete sequence \330>, buflen=4863, selections=0x0,
unpack_data=1 '\001', reclen=-1, verbose=0 '\000', details=0 '\000', header_byteorder=-1, allocData=0x7ffff7fae048, diag_print=0x7ffff7fae080,
log_print=0x7ffff7fae0b8) at obspy/io/mseed/src/obspy-readbuffer.c:472
472 if ((unpack_data != 0) && (msr->fsdh->data_offset >= 48) && |
Maybe @krischer can have a look when he's got some time, no hurry though.. |
This branch contains a fix: https://github.com/obspy/obspy/tree/mseed-fix-segfault-truncated-file Not sure why I cannot convert this issue to a PR right now but I'll try again later tonight or tomorrow. Or maybe somebody else can try? Some other types of record corruption where already caught by libmseed and correctly bubble up to the Python warnings. I'm not entirely sure why this one does not but maybe its just because its truncated fairly late in the file? In any case: now works as expected and it raises a nice warning (but still reads all previous records). |
Hmm...looks like one of my tries did convert it to a PR in the end? Or did someone else do it? Anyways - IMHO good to go. Feel free to review and merge :) |
Thanks for the fix @krischer, checking again, there's still some truncation scenarios that end in segfaults though.. Can you maybe have a look at these two byte offset:
These seem to be different issues.. the latter one I've seen in real live reading mseed files that currently also get appended to in other threads (checking data latency). import copy
from io import BytesIO
from obspy import read
from obspy.core.util import get_example_file
file_ = get_example_file('BW.BGLD.__.EHE.D.2008.001.first_10_records')
with open(file_, 'rb') as fh:
data = fh.read()
for i in range(1, 10000):
# this seems to be a different issue than the already covered one:
if i == 256:
continue
# these seem to be the same issue as with 256, as there just offset by 512
# bytes..
if i % 512 == 256:
continue
# this is finally the issue I was looking after: :-)
if i == 5066:
continue
print(i)
bio = BytesIO(copy.deepcopy(data[:-i]))
read(bio, format='MSEED') |
We already caught a couple of other variants of this but not this particular one. Now works correctly and raises a proper warning.
… MiniSEED reading function.
5475060
to
52d109d
Compare
All fixed, rebased and force pushed. The 256 + 512 bytes offsets were just because I forgot the |
Thanks for the fix(es)! 🎉 |
IMHO ready to be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works like a charm, thanks!
(somehow I can't 'approve' this PR, seems like there's a problem with the review button..)
While trying to work around a problem when reasding truncated files (in SDS client while reading files that are currently being appended to by a different program), I came across a segfault when reading truncated MiniSEED files: