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
Seg fault for std_string in message pack #465
Comments
Here is a typical gdb stack trace for the segfault, but haven't made any real progress understanding the problem:
and the Python stack trace as shared by @nksauter is here:
|
Can also trigger a segfault by the following steps, where
|
@phyy-nx your code as written works fine for me - macOS / Python 3.9
|
Where by work fine, I mean it fails to fail. It succeeds. I can also manually inspect the file and verify that it indeed appears to work:
Seems to do the things I would have expected it to do... |
I can however report that on RHEL7 with DIALS 3.8.0 release I do reproduce your error:
|
OK, additional - the When I try to load the macOS derived file on RHEL7 (which should work) I get a big badda boom
The pickling nonsense there is because of our graceless fallback. |
Default string encoding on both platforms is UTF8:
-> 🤔 I don't see why the saved messagepack files would be different -> this is probably a pointer to the underlying fault |
Adding
(because I am old and debug with |
Ah, OK - this probably works on macOS as a happ accident - because the actual string data are saved in the If I write
I get the expected segmentation fault on macOS -> this must never have ever even considered working (and yeh probably time for an |
OK; after a little investigation of this we have the following issue:
Packing to:
as a stream of bytes then unpacking the same would make sense here - overloading in the same manner as the shoebox - but my interval to look at this expired so I backed out teh changes. It can be done, but is probably a 3 coffee problem. |
Obviously there are also some rather embedded assumptions here, for example that the strings are |
Working on cctbx/dxtbx#465 This could never have worked. Now trying to make something which does work. This does not work. This is at least some stubs / breadcrumbs on how it could work
I'm going to close this here - not because it isn't an issue - but because it's explicitly a dials issue, and there is an existing ticket to track this: dials/dials#1858 |
Thanks @graeme-winter for looking at this. Good set of clues. At the moment I'm inclined to look into whether we can do away with the |
Hi, this came up while looking at message pack instead of pickle for cctbx.xfel.merge, which currently outputs pickle files. Here's a minimal reproducer:
Output indicates a segfault:
Further, running
dials.show seggy.refl
will also seg fault. It is also super weird that the first assert passes and the second fails.Note that the same file dumped using pickle will work just fine.
The text was updated successfully, but these errors were encountered: