-
Notifications
You must be signed in to change notification settings - Fork 146
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
httpd/3.2.2 segfaults when accessing /admin/proc #3154
Comments
I think the double-dereferencing there is deliberate, and that the real problem here is that FreeBSD is differentish from other platforms in some way that we aren't properly accommodating. Have a look at 8e23292 -- we're going to some lengths here to detect platform quirks and interact with various I don't understand qsort_r's portability concerns well enough to just intuit the correct fix, but I think it will involve changing the block of macros before |
Ahh, those macros were later moved to lib/cyr_qsort_r.h by 3302c80, which is probably why you didn't see them. Do you have cunit installed? There's a unit test for this function... what does |
After ./configure'ing with --enable-unit-tests:
After adding this to cunit/timeofday.c at line 213:
Finally, after replacing a couple of
The FreeBSD ports system applies this patch before building:
I just added this to
Now the unit test succeeds:
|
httpd has been running ok with the last change to |
malloc.h is nonstandard, and some platforms complain about it. Reported in #3154.
malloc.h is nonstandard, and some platforms complain about it. Reported in #3154.
That's good to hear. I'm having trouble following the sequence of cyr_qsort_r changes in the patches (both the ports system's and your own). Can you please attach your current (working) cyr_qsort_r.h and cyr_qsort_r.c, so that I can diff them against our git sources locally? I think that will make it a bit easier for me to see what's going on. |
I went looking around to see what other projects experiences of this are, and it's a bit of a minefield. Interestingly, FreeBSD appears to be moving towards using the glibc-style qsort_r argument order: https://reviews.freebsd.org/D17083. I don't completely understand their process but from the discussion it sounds like they're expecting to be glibc-compatible here for FreeBSD-13, so at some point we'll need to update our detection macros in cyr_qsort_r to cope with that. I don't really understand the motivation behind the existing It would also be interesting to see what happens if you build from a pure source tarball and or a git clone, but skimming through the other patches in the port, it might be fiddly/distracting at the moment. So the main thing I'm interested in, in addition to your current working sources, is what happens when cyr_qsort_r.c specifically is completely unpatched. |
cyr_qsort.h gets not modified on FreeBSD:
Working cyr_qsort.c:
qsort_r() on FreeBSD 12 expects argument |
This is quite strange: I'm stepping through the macros in cyr_qsort_r.h and I think that the Like, we use that function-based implementation if-and-only-if neither "HAVE_GLIBC_QSORT_R" nor "HAVE_BSD_QSORT_R" are defined. If either are defined, then Notice that the So, maybe the problem is that the function needs to be not-compiled if we're using the macros... but that would explain compilation errors, but doesn't explain the crash. And it doesn't explain why patching the function fixes the crash. Hmm. Can you please run something like The |
Please see attached file which is the output of |
cc --version:
|
As cyr_qsort_r() from cyr_qsort_r.c is not hidden by the macros from cyr_qsort_r.h, I'm suggesting this patch based on FreeBSD's ones:
It currently runs on my BSD box, avoids compiling cyr_qsort_r if defined by a macro, and honors reversed arguments of compar() on BSD when there's no native qsort_r() available. |
What happens if you exclude the FreeBSD patch entirely, and only leave this change:
I suspect /admin/proc will work correctly, but it will start breaking in a bunch of new places... I'm looking very closely at the comment at the top of cyr_qsort_r.h, which reads:
and I think its intent is this macro MUST be used for the "compar" functions, but not for cyr_qsort_r. But, looking through our source, I can see a bunch of places where our compar function has not been declared using this macro (e.g. My gut feeling at the moment is that maybe the FreeBSD patch was mistakenly added to fix the calls that were missing the macro. But then that has meant that the ones that are already correctly declared ( If my hunch is correct, there will be three parts to this fixing this properly:
I guess step 3 will require coordination with the ports maintainer, once there is a real release containing this set of fixes. I'm not currently sure how to reach them, but I guess the first step is confirming that 1 & 2 work, and we can worry about 3 once we're confident they do. |
Actually I'm looking at the fallback |
i.e. if the system has NO qsort_r function and we need to fake it with qsort Part of cyrusimap#3154
Based on a patch from FreeBSD ports and modified further by @felixjogris Part of cyrusimap#3154
This is where I'm at: cyrus-imapd-3.2...elliefm:v32/3154-cyr_qsort_r
This is the equivalent of your "#elif !defined cyr_qsort_r" patch, but it also protects the nested-functions implementation, in case clang starts supporting these.
This is the FreeBSD patch plus your fix. I might still remove this, more discussion below.
And this one fixes up the bad compar function in jmap_contact, which turned out to be the only one that was missing the macro after all. I have finally understood how the FreeBSD patch worked: When we But with the new commit such that we only compile the fallback function if we need it, it will no longer accidentally replace the real qsort_r, and instead cyr_qsort_r will just be a wrapper macro as intended. So, now the fallback should really be a fallback! This should make the FreeBSD patch and your fix to it redundant for FreeBSD, since it will now use the BSD qsort_r and not the fallback. Actually, it might make it completely redundant for every system (since a system with no qsort_r at all cannot possibly have opinions about the ordering of the thunk argument)... I need to think about this more still. But I think, all along, the problem was that we didn't make the fallback function conditional, and thus accidentally replaced qsort_r instead of just wrapping it. Can you please try it out with this set of patches? (You can download any git commit as a patch file from github by just adding ".patch" to the end of the address.) They should apply cleanly on 3.2.2, or you can try with 3.2.3 which came out a few days ago. You'll still need your cunit/timeofday.c patch either way, but the "malloc.h -> stdlib.h" problem is fixed in 3.2.3. (I didn't integrate the cunit/timeofday.c patch, because it doesn't replace the function, just drops the real one in place. This is adequate for the cyr_qsort_r test, which doesn't care about fiddling with dates/times anyway, but I think it won't work for many of the tests, which expect to be able to mock the system time.) |
Compiles and runs fine. Sorting on /admin/proc works ok. |
All 3 patches apply and run ok in regards to /admin/proc. FreeBSD uses 3.2.3 already.
|
Oh, I missed that one somehow, thanks! Though it turns out the two JMAP ones were already fixed on master a few months, so I'll replace my bespoke commit with a cherry-pick of that one. :) |
i.e. if the system has NO qsort_r function and we need to fake it with qsort Part of cyrusimap#3154
i.e. if the system has NO qsort_r function and we need to fake it with qsort Part of cyrusimap#3154
Hi,
httpd of a non-murder 3.2.2 setup segfaults when accessing /admin/proc with a webbrowser to get a list of currently running services. Syslog on the server:
lldb reveals:
Trivial fix:
My environment:
The text was updated successfully, but these errors were encountered: