Current version of Raptor apparently causes Soprano to segfault: possible to fix? #66
Assignees
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. |
cooljeanius
added a commit
to cooljeanius/raptor2
that referenced
this issue
Apr 12, 2024
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. |
|
FWIW, the issue occurs with raptor 2.0.16 but not 2.0.15 ; maybe there's some useful information in that? Someone motivated enough could do a git bisect to find the raptor commit that introduced the breaking change.
|
|
FWIW bis: I can reproduce the crash with soprano 2.9.4 on Kubuntu 14.04 with a self-installed raptor 2.0.16 : I'm a little surprised that neither platform gives a runtime error about doing a double free: I'm used to getting those. |
Here you go (Linux AMD64, raptor2 2.0.16): |
|
Also, if you look at Soprano's raptor parser, there is no evident possibility to get a double free or any other kind of memory management error. It's all pretty straightforward: allocate a raptor parser, use it done or until a parsing error occurs, free the parser and return. Checking for I did find another shared-desktop-ontologies file where soprano crashes (with a double-free-or-corruption warning when run from the debugger) but |
|
yes, as I said above, the issue could more likely be with the file being parsed Failed to parse file/opt/local/share/ontology/pimo/tmo.trig(Parsing failed (3): syntax error, unexpected end of file, expecting } (line: 75, column: -1)) now that you found a way to trigger the crash just with rapper, perhaps it can be sorted. Thanks for that. |
|
Failed to parse file/opt/local/share/ontology/pimo/tmo.trig(Parsing failed (3): syntax error, unexpected end of file, expecting } (line: 75, column: -1))
now that you found a way to trigger the crash just with rapper, perhaps it can be sorted.
Yes, because the library shouldn't crash this way on bad input. The fastest fix (one that's also required, one way or another) would (might?) probably be a fix of the input.
have we uploaded that file here?
I uploaded `pimo.trig` I realise, but it also crashes for the same reason. I'll upload tmo.trig too.
|
|
I looked at the input last month but I could not spot the issue. Maybe you can see it? Linefeeds, something silly? Now that it’s all internal to raptor perhaps it can be debugged more easily. |
|
I looked at the input last month but I could not spot the issue. Maybe you can see it? Linefeeds, something silly?
It is of course possible that the syntax error report is another symptom of the regression.
|
|
BTW, the symptoms are a little different between Darwin and Linux: Curiously, setting Using |
|
I can reproduce this crash with raptor GIT head and the given example file on x86_64 and arm64 |
|
Preliminary patch seems to be: although you'd need to re-generate the parser with bison |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@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
sopranosegfaults 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: