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
Current version of Raptor apparently causes Soprano to segfault: possible to fix? #66
Comments
Lines 475 to 505 in 72a8a2d
I see there's a check to guard against the uri pointer being null, but it looks like one of its subpointers, uri->world , could still be null, though... what happens if you add a check to ensure uri->world isn't null before dereferencing it, does that fix it?
|
There's not enough information here to help. My guess is that it's how raptor's functions are being called. Since raptor isn't written in a reference counted language with garbage collection, it can't guarantee use-after-free if the caller does free twice. I would suggest building and running your app with something like valgrind or clan asan and see if there are such issues. I have tested raptor release code that way and in other ways, such as with coverity. |
check for potential null pointer dereference; see dajobe#66 (untested)
@dajobe By the way, since the problem happens on Intel too, maybe you could try |
@cooljeanius Does it solve the issue on x86 for you? |
You mean cooljeanius/raptor2@85fc5b7? I haven't tested it yet, which is why I haven't submitted a PR for it yet... |
I did try @cooljeanius 's patch, and it doesn't error in the raptor code but still later errored in the system. I rebuilt raptor with clang's address sanitizers enabled, and I believe it shows a double-free is happening as suspected. I'm not 100% sure why or how to fix it at the moment. Perhaps someone familiar with how raptor works like @dajobe might see the issue?
|
This appears to be the spot in soprano where these calls emanate from:
perhaps "parser" needs to be tested as non-NULL prior to this call?
|
testing for null didn't fix the issue, but removing the line did, right or wrong. that then leads to this error:
which may indicate what the problem really is... |
If you can demonstrate this issue/crash with the lastest release build of raptor and the 'rapper' utility, then I probably can look deeper. FWIW I only have amd64, aarch64 (linux) / arm64 (darwin), armv7l, riscv arches here to test. |
The issue is present on |
I don't think this issue has anything to do with raptor really -- although I guess ideally it shouldn't crash when given bogus data, that is not raptor's fault. The main problem is most likely soprano, which is ancient, out-of-date, unsupported upstream, and horribly fails it's test suite when that is attempted. |
@kencu But it presumably worked at some point, right? At least in a sense of KDE4 ports building and working with it (not necessarily passing its own test-suite). |
yes, soprano worked last year when i built kdelibs4 on Sonoma. Something broke it since then. not raptor, though. Let's leave this man in peace. |
@dajobe Sorry to disturb with this, this may not be a Raptor bug, however it seems at least that Raptor somehow causes this.
We are unable to build KDE4 libs now, since
soprano
segfaults due to unclear reason, but logs point at Raptor. Notably, the failure occurs on different macOS versions and different archs (apparently it works nowhere in fact).Discussion is here: https://trac.macports.org/ticket/68452
This is what I see in a crash log on a PowerPC:
And the issue is also confirmed on x86 (the ticket referred has full logs).
Could this be addressed? It would be really helpful.
The text was updated successfully, but these errors were encountered: