dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2020-01-21T19:13:05Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/80New relay unit test code fails to link using libtool under Fedora 30/Centos 82020-01-21T19:13:05ZThomas MarkwalderNew relay unit test code fails to link using libtool under Fedora 30/Centos 8Build farm failed to build on Fedora30 (and Centos 8) when trying to link the new unit test binary, relay/tests/relay_unitttest:
```
libtool: link: gcc -g -O2 -I../../../../includes -I/home/jenkins/workspace/isc-dhcp-master-distcheck/L...Build farm failed to build on Fedora30 (and Centos 8) when trying to link the new unit test binary, relay/tests/relay_unitttest:
```
libtool: link: gcc -g -O2 -I../../../../includes -I/home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/include -o .libs/relay_unittests dhcrelay.o relay_unittests.o -L/opt/atf/lib /opt/atf/lib/libatf-c.a ../../common/.libs/libdhcp.so ../../omapip/.libs/libomapi.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/irs/.libs/libirs.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/isccfg/.libs/libisccfg.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/dns/.libs/libdns.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/isc/.libs/libisc.so -ldl -lcap -lz -Wl,-rpath -Wl,/home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/_inst/lib
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `find_class'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `classify'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcpv6'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `check_collection'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `bootp'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcp'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `parse_allow_deny'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcp_set_control_state'
```
Need to add function definitions for these to the test code.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/75Add interface name to socket setup fatal error logs2020-01-14T19:31:54ZThomas MarkwalderAdd interface name to socket setup fatal error logsThere mulitple calls to setsockopt (and the ilk) in common/socket.c that do not emit the interface name for which the operation is being invoked. It's helpful data to have when these calls fail and while it can typically be inferred, it...There mulitple calls to setsockopt (and the ilk) in common/socket.c that do not emit the interface name for which the operation is being invoked. It's helpful data to have when these calls fail and while it can typically be inferred, it's easy enough to simply emit it.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/72(From ISC Bugs 47555) dhcpd: failover.c...:scrubbing lease for ... emitted un...2020-01-14T12:29:40ZCathy Almond(From ISC Bugs 47555) dhcpd: failover.c...:scrubbing lease for ... emitted unexpectedlyFrom [BUG ticket #47555](https://bugs.isc.org/Ticket/Display.html?id=47555) - I understand the intent was to fix this in 4.4.2 but it seems not to have had a GL issue opened for it.
Originally from Customer Support ticket [#12731](https...From [BUG ticket #47555](https://bugs.isc.org/Ticket/Display.html?id=47555) - I understand the intent was to fix this in 4.4.2 but it seems not to have had a GL issue opened for it.
Originally from Customer Support ticket [#12731](https://support.isc.org/Ticket/Display.html?id=12731)
This message is logged by scrub_lease() in server/failover.c:
void scrub_lease(struct lease* lease, const char *file, int line) {
log_debug ("%s(%d):scrubbing lease for %s, hostname: %s", file,
line,
--
It seems to be the only log_debug statement in the failover code that is not surrounded by a "#if defined (DEBUG_FAILOVER_MESSAGES)" statement, which seems to be an oversight.
The code that introduced this logging stanza was added to ISC DHCP with this change:
- Leases are now scrubbed of certain prior use information when pool
re-balancing reassigns them from one FO peer to the other. This
corrects an issue where leases that were offered but not used
by the client retained the client hostname from the original
client. Thanks to Pavel Polacek, Jan Evangelista Purkyne University
for reporting the issue.
[ISC-Bugs #42008]4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/71Correct buffer pointer logic in dhcrelay agent option functions2020-01-28T15:02:10ZThomas MarkwalderCorrect buffer pointer logic in dhcrelay agent option functionsTwo functions in dhcrelay.c, strip_relay_agent_options() and add_relay_agent_options() incorrectly advance pointers when removing existing agent options. See #63 for details.
This will need to be fixed in v4_1_esv as well.Two functions in dhcrelay.c, strip_relay_agent_options() and add_relay_agent_options() incorrectly advance pointers when removing existing agent options. See #63 for details.
This will need to be fixed in v4_1_esv as well.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/68Changing 'd' content type to RFC 1035 name broke omapi-key parsing2023-05-17T11:22:29ZThomas MarkwalderChanging 'd' content type to RFC 1035 name broke omapi-key parsingWe overlooked three server options with 'd' format: omapi-key, ldap-port, ldap-init-retry. Changing 'd' under #2 from being handled as text, breaks the ability to match omapi-key to any parsed keys. When server config file defines a TS...We overlooked three server options with 'd' format: omapi-key, ldap-port, ldap-init-retry. Changing 'd' under #2 from being handled as text, breaks the ability to match omapi-key to any parsed keys. When server config file defines a TSIG key to use with omapi such as shown below:
```
# define a key
key toms-key {
algorithm hmac-md5;
secret <some key here>;
}
# tell the server to use the key for omapi
omapi-key toms-key;
```
With a "d" option format for omapi-key, during configuration parsing the server will emit the error "OMAPI key : not found" and then exit. This is because the value for omapi-key option when evaluated by the server is in RFC 1035 format "\007toms-key" rather than plain text "toms-key". Changing the format to "t" will solve the problem. This should work for all three as prior #2, "d" format content equivalent to plain text.
This will need to go to v4_1_esv too.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/57Fix reference count leaks2020-01-14T08:15:10ZThomas MarkwalderFix reference count leaksFix leaks reported in #44.Fix leaks reported in #44.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/53dhclient v4.4.1 - REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT2019-11-18T16:52:56ZGhost Userdhclient v4.4.1 - REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT---
name: REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT
about: dhclient v4.4.1
---
**Describe the bug**
We noticed that sometimes, under heavy load, when SIGTERM/SIGINT is sent to dhclient, the following ASSERT is trig...---
name: REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT
about: dhclient v4.4.1
---
**Describe the bug**
We noticed that sometimes, under heavy load, when SIGTERM/SIGINT is sent to dhclient, the following ASSERT is triggered:
```
...lib/isc/unix/app.c:574: REQUIRE(ctx->running) failed, back trace
#0 0x59355e in ??
#1 0x5936ea in ??
#2 0x5b4492 in ??
#3 0x7f20d70f0560 in ??
#4 0x7f20d71758f0 in ??
#5 0x7f20d71757a4 in ??
#6 0x42486c in ??
#7 0x40a39a in ??
#8 0x7f20d70dd6b0 in ??
#9 0x40ae39 in ??
Aborted
```
If the SIGTERM/SIGINT signal is sent during startup, in the small window interval between signal handler registration and the moment when ctx->running is set to 1, the REQUIRE(ctx->running) assertion is triggered.
Please let us know if any additional info is required.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/50Update Contributor's Guide to reflect gitlab and new procedures2019-11-18T16:31:10ZThomas MarkwalderUpdate Contributor's Guide to reflect gitlab and new proceduresCONTRIBUTING.md is seriously out of data and also visible on the Wiki. It needs to be revamped to reflect gitlab. See Kea's CONTRIBUTING.md.CONTRIBUTING.md is seriously out of data and also visible on the Wiki. It needs to be revamped to reflect gitlab. See Kea's CONTRIBUTING.md.4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/47Remove the includes/cf directory and files2019-09-06T20:20:14ZThomas MarkwalderRemove the includes/cf directory and filesThe files in includes/cf are not used in the code anywhere, nor do we distribute them. We should remove them from the repo as they only serve as a distraction.The files in includes/cf are not used in the code anywhere, nor do we distribute them. We should remove them from the repo as they only serve as a distraction.4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/37Understanding 'authoritative' in dhcpd.conf2019-12-20T16:26:21ZCathy AlmondUnderstanding 'authoritative' in dhcpd.confFrom Support ticket [#14997](https://support.isc.org/Ticket/Display.html?id=14997)
We were surprised that when an ISC DHCP server does not have 'authoritative' set to yes an option (the default is no) that all DHCPINFORM messages are no...From Support ticket [#14997](https://support.isc.org/Ticket/Display.html?id=14997)
We were surprised that when an ISC DHCP server does not have 'authoritative' set to yes an option (the default is no) that all DHCPINFORM messages are not responded to and the logs contain "not authoritative for subnet".
Reading the man page for dhcpd.conf, we see this explanation:
> The authoritative statement
...
> The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.
In other words, if there are clients out there that are going to be getting leases from other servers that ISC DHCP knows nothing about, and then trying to get additional options via DHCPINFORM, and you're not really sure that you've got your configuration correct, then *not* being authoritative is probably the right way to go...
> Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.
In other words, if you're certain that you're right and any clients sending DHCP messages to your servers for addresses that they shouldn't be, then being authoritative is correct.
=======
But not having your ISC DHCP server be authoritative, causes it not to respond to *any* DHCPINFORMs, rather than just those with which it has a problem. It stops the DHCPNAKs, but it also stops the DHCPACKs too.
=======
Is this something where the documentation could be cleared, or is it functionality that was not supposed to be this way?4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/35Update instructions for getting and building ATF for unit tests2019-12-02T20:23:12ZThomas MarkwalderUpdate instructions for getting and building ATF for unit testsDocumentation for getting and building ATF for unit testing needs to be updated, since Kyua's project site has changed.Documentation for getting and building ATF for unit testing needs to be updated, since Kyua's project site has changed.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/34Merge Keama and distribute it2019-11-12T16:13:15ZThomas MarkwalderMerge Keama and distribute itKeama branch should be merged into master so that it can be distributed with 4.4.2 release.Keama branch should be merged into master so that it can be distributed with 4.4.2 release.4.4.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/33Fix dhcpd/dhcrelay in v6 mode operation on OpenBSD2019-11-18T16:18:43ZBrad SmithFix dhcpd/dhcrelay in v6 mode operation on OpenBSDThe linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~c...The linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/isc-dhcp/patches/patch-common_socket_c?rev=1.7&content-type=text/plain&hideattic=14.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/30Coverity: memory leaks in conf file parsing2019-11-18T16:01:03ZMark AndrewsCoverity: memory leaks in conf file parsingCIDs 1448191, 1448193, 1448194, 1448195CIDs 1448191, 1448193, 1448194, 14481954.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/26ieee.org oui.txt URL moved2021-01-18T17:49:11ZTommy Smithieee.org oui.txt URL moved---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufac...---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt
**To Reproduce**
Steps to reproduce the behavior:
1. Remove /usr/local/etc/oui.txt
2. Run dhcp-lease-list
3. See message to "To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt"
4. Attempt to download http://standards.ieee.org/regauth/oui/oui.txt
5. Get 404 error from ieee.org
**Expected behavior**
Message from dhcp-list-list should be as follows:
To get manufacturer names please download http://standards-oui.ieee.org/oui.txt to /usr/local/etc/oui.txt
**Environment:**
- ISC DHCP version: 4.3.5 to current
- OS: e.g. Ubuntu 18.04 x64
**Additional Information**
I have a patch ready to go that updates /contrib/dhcp-lease-list.pl with the correct URL.
I need to have permissions to push the branch and then make the merge request.
**Describe the solution you'd like**
I would like permission to push a branch and then submit a merge request with the fix.
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs? No.
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code? Yes.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them. Yes4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/22[keama] dhcp4 option 67 wrong name2019-11-12T15:01:31ZChris[keama] dhcp4 option 67 wrong nameI used keama quite successfully to convert an existing ISC-dhcpd config to use as template (awesome work!), but came upon an incomplete conversion of dhcp4 option 67: bootfile-name
Kea config uses the name "boot-file-name", but keama ou...I used keama quite successfully to convert an existing ISC-dhcpd config to use as template (awesome work!), but came upon an incomplete conversion of dhcp4 option 67: bootfile-name
Kea config uses the name "boot-file-name", but keama outputs "bootfile-name".
isc-dhcpd source:
```
option bootfile-name "boot.pxe"
```
keama output:
```
"option-data": [
{
"space": "dhcp4",
"name": "bootfile-name",
"code": 67,
"data": "boot.pxe"
}
]
```
While discussions can (and maybe should) be held whether the kea name is "incorrect" in the first place (both RFC2132 and kea's own [KB](https://kb.isc.org/docs/aa-01323) for supported options refer to it as "Bootfile Name") or should support both versions, the goal of keama is to create valid kea configs and should output "boot-file-name".4.4.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/19HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined2019-11-22T11:13:17ZJoe LeVequeHAVE_SO_BINDTODEVICE referenced before it has a chance to be defined---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includ...---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L152) in the following conditional:
```
#if defined (USE_BPF_SEND) || defined (USE_NIT_SEND) || \
defined (USE_DLPI_SEND) || defined (USE_UPF_SEND) || \
defined (USE_LPF_SEND) || \
(defined (USE_SOCKET_SEND) && defined (HAVE_SO_BINDTODEVICE))
# define USE_SOCKET_FALLBACK
# define USE_FALLBACK
#endif
```
However, it might not get defined until [line 267](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L267), as follows:
```
#if defined (SO_BINDTODEVICE) && !defined (HAVE_SO_BINDTODEVICE)
# define HAVE_SO_BINDTODEVICE
#endif
```
Therefore, if `USE_SOCKET_SEND` is defined, it is possible that `USE_SOCKET_FALLBACK` and `USE_FALLBACK` will not get defined, even though they should, simply because `HAVE_SO_BINDTODEVICE` is referenced before it has had a chance to get defined.
**To Reproduce**
Steps to reproduce the behavior:
1. Add a `#pragma message()` line inside the first `#if` block mentioned above (e.g., at line 153 of includes/osdep.h) so that the preprocessor will print the message if it enters the block
2. Compile isc-dhcp on a system which defines `SO_BINDTODEVICE` (e.g., Debian Stretch), while also defining `USE_SOCKETS` (e.g., via the `--enable-use-sockets` configure flag)
3. Note that the message does not print, although it should
**Expected behavior**
`HAVE_SO_BINDTODEVICE` should have an opportunity to be defined before it is referenced
**Environment:**
- ISC DHCP version: All versions since commit d758ad8cac9c00c70cfe4dd459bf7e87c268c579 (pre-version 4.0.0)
- OS: Debian Jessie/Stretch, most likely many other Linux flavors
- Which features were compiled in: `USE_SOCKETS`
**Describe the solution you'd like**
Reorder the file includes/osdep.h to ensure `HAVE_SO_BINDTODEVICE` has a chance to be defined before it is referenced.4.4.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/18Bundle BIND9 version-correct tar ball into the main repo2019-11-18T15:24:12ZThomas MarkwalderBundle BIND9 version-correct tar ball into the main repoThe BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It elimi...The BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It eliminates outsiders needing to run util/bind.sh. We need to follow suit and do this to main repo. Either that or we simply merge the migration-assistant branch into master.4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/16A NSUPDATE compiling issue was observed2019-07-04T10:03:19ZGhost UserA NSUPDATE compiling issue was observedDescription:
A following error was observed:
```
| omapip/isclib.c: In function 'dns_client_init':
| omapip/isclib.c:356:18: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| if (dhcp_gbl_ctx.dnsclien...Description:
A following error was observed:
```
| omapip/isclib.c: In function 'dns_client_init':
| omapip/isclib.c:356:18: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| if (dhcp_gbl_ctx.dnsclient == NULL) {
| ^
| omapip/isclib.c:363:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| &dhcp_gbl_ctx.dnsclient,
| ^
| omapip/isclib.c:364:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'use_local4'
| (dhcp_gbl_ctx.use_local4 ?
| ^
| omapip/isclib.c:365:25: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'local4_sockaddr'
| &dhcp_gbl_ctx.local4_sockaddr
| ^
| omapip/isclib.c:367:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'use_local6'
| (dhcp_gbl_ctx.use_local6 ?
| ^
| omapip/isclib.c:368:25: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'local6_sockaddr'
| &dhcp_gbl_ctx.local6_sockaddr
```
Test source is based on:
https://source.isc.org/git/dhcp.git
```
commit 85ef0d90e2ab5eee758242d5a094c1d12ce24576
Merge: a5b21e1 479b929
Author: Francis Dupont <fdupont@isc.org>
Date: Thu Nov 29 16:41:42 2018 +0100
Fixed server option code point conflict
```
How to reproduce:
Drop one line in includes/site.h:
```
-#define NSUPDATE
```
Possible fix:
I have verified it could be fixed by this patch: [0001-Fix-a-NSUPDATE-compiling-issue.patch](/uploads/6c1d137a5ee712338c7df0ca8a081a55/0001-Fix-a-NSUPDATE-compiling-issue.patch)
How to contact the reporter:
liu.ming50@gmail.com4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/15confpars.c has invalid error messages when memory allocation fails2019-11-08T17:40:56ZGhost Userconfpars.c has invalid error messages when memory allocation failsGCC 9 detects two cases where confpars.c includes NULL values in error messages. The error exists in both 4.4.1 and current master; I believe the attached patch is a correct fix for them.
[0001-Emit-correct-error-message-when-malloc-fai...GCC 9 detects two cases where confpars.c includes NULL values in error messages. The error exists in both 4.4.1 and current master; I believe the attached patch is a correct fix for them.
[0001-Emit-correct-error-message-when-malloc-fails.patch](/uploads/2422be5dd4cacd64ace575f694c4fd30/0001-Emit-correct-error-message-when-malloc-fails.patch)4.4.2Thomas MarkwalderThomas Markwalder