http-parser recently got updated from 2.0-9.20121128gitcd01361.fc23 to 2.7.1-2.fc23. Since then, ocserv segfaults when accepting connections: [root@shinybook tests]# valgrind /usr/sbin/ocserv -d 1 -f -c configs/test-user-cert.config ==2261== Memcheck, a memory error detector ==2261== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==2261== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==2261== Command: /usr/sbin/ocserv -d 1 -f -c configs/test-user-cert.config ==2261== Skipping unknown option 'cookie-validity' Parsing plain auth method subconfig using legacy format Setting 'certificate+plain' as primary authentication method listening (TCP) on 0.0.0.0:443... listening (TCP) on [::]:443... listening (UDP) on 0.0.0.0:443... listening (UDP) on [::]:443... ocserv[2261]: main: not using control unix socket ocserv[2261]: main: initialized ocserv 0.10.12 ocserv[2263]: sec-mod: reading supplemental config from files ocserv[2263]: sec-mod: sec-mod initialized (socket: ./ocserv-socket.2261) ocserv[2261]: main: processed 1 CA certificate(s) ocserv[2272]: worker: tlslib.c:379: no certificate was found ==2272== Conditional jump or move depends on uninitialised value(s) ==2272== at 0x5E1FFC4: http_parser_execute (http_parser.c:1927) ==2272== by 0x11B6B0: vpn_server (worker-vpn.c:520) ==2272== by 0x115869: main (main.c:1265) ==2272== ==2272== Use of uninitialised value of size 8 ==2272== at 0x5E1FFE3: http_parser_execute (http_parser.c:1927) ==2272== by 0xBFAD1AF: ??? ==2272== by 0x11B6B0: vpn_server (worker-vpn.c:520) ==2272== by 0x115869: main (main.c:1265) ==2272== ==2272== Jump to the invalid address stated on the next line ==2272== at 0x6F6974616D726F66: ??? ==2272== by 0x6F6973726576206B: ??? ==2272== by 0x2022302E31223D6D: ??? ==2272== by 0x676E69646F636E64: ??? ==2272== by 0x22382D465455223C: ??? ==2272== by 0x666E6F633C0A3E3E: ??? ==2272== by 0x20687475612D6768: ??? ==2272== by 0x223D746E65696C62: ??? ==2272== by 0x70797420226E7075: ??? ==2272== by 0x2274696E69223D64: ??? ==2272== by 0x6F69737265763C3D: ??? ==2272== by 0x76223D6F6877206D: ??? ==2272== Address 0x6f6974616d726f66 is not stack'd, malloc'd or (recently) free'd ==2272== ==2272== ==2272== Process terminating with default action of signal 11 (SIGSEGV) ==2272== Bad permissions for mapped region at address 0x6F6974616D726F66 ==2272== at 0x6F6974616D726F66: ??? ==2272== by 0x6F6973726576206B: ??? ==2272== by 0x2022302E31223D6D: ??? ==2272== by 0x676E69646F636E64: ??? ==2272== by 0x22382D465455223C: ??? ==2272== by 0x666E6F633C0A3E3E: ??? ==2272== by 0x20687475612D6768: ??? ==2272== by 0x223D746E65696C62: ??? ==2272== by 0x70797420226E7075: ??? ==2272== by 0x2274696E69223D64: ??? ==2272== by 0x6F69737265763C3D: ??? ==2272== by 0x76223D6F6877206D: ??? ==2272== ==2272== HEAP SUMMARY: ==2272== in use at exit: 249,462 bytes in 851 blocks ==2272== total heap usage: 3,114 allocs, 2,263 frees, 1,302,359 bytes allocated ==2272== ==2272== LEAK SUMMARY: ==2272== definitely lost: 8,448 bytes in 2 blocks ==2272== indirectly lost: 0 bytes in 0 blocks ==2272== possibly lost: 42,521 bytes in 30 blocks ==2272== still reachable: 125,789 bytes in 818 blocks ==2272== suppressed: 72,704 bytes in 1 blocks ==2272== Rerun with --leak-check=full to see details of leaked memory ==2272== ==2272== For counts of detected and suppressed errors, rerun with: -v ==2272== Use --track-origins=yes to see where uninitialised values come from ==2272== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) ocserv[2261]: main: [::1]:54118 user disconnected (rx: 0, tx: 0) ocserv[2261]: main: main.c:521: Child 2272 died with sigsegv
Rebuilding ocserv against the new http-parser 'fixes' it. Did the library break binary compatibility without updating its soname?
(In reply to David Woodhouse from comment #1) > Rebuilding ocserv against the new http-parser 'fixes' it. Did the library > break binary compatibility without updating its soname? If they did, they're in violation of their own semver-based versioning scheme. Sorry about this; according to semver, http-parser 2.7.1 should have been backwards-compatible with anything built against 2.0. That being said, it looks like the previous maintainer of this package had been using a git snapshot between 2.0 and 2.1 to fix certain errors in the tests. It's entirely possible that this specific version had introduced a regression that would have been fixed in 2.1.0 when it was finally released and we are only just now feeling it. Anyway, I apologize for the breakage. Since it seems that a trivial rebuild should be all that's needed, I'll see if I can do that for each of the packages depending on http-parser in F23.
I've submitted an update (rebuild) for ocserv: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b4a82e707e
ocserv-0.10.12-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b4a82e707e
ocserv-0.10.12-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.