topic Re: DIG crash in Operating System - OpenVMS

DIG crash

Willem Grooters — Thu, 08 Feb 2007 17:06:21 GMT

(IA64, VMS 8.3)

TCPIP$DIG.EXE has a weird way of telling it cannot cope with the absence of a DNS server and resolver: The image crashes.

WILLEM>dig ecvs06
assert error: expression = strlen(str) > 0U, in file BUILD23$:[TCPIP_V56_BL9.SRC.BIND9_RESOLVER]LWCONFIG.C;1 at line 210
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF84AAAB60, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000003
Name = 0000000000000434
FFFFFFFF84AAAB60
000000000000001B

Register dump:
R0 = 0000000000000000 R1 = 000000007B562000 R2 = 000000007ACCF690
R3 = 000000000000000A R4 = 000000007FFCF818 R5 = 000000007FFCF8B0
R6 = 0000000000000001 R7 = 0000000000000001 R8 = 0000000000000000
R9 = 0000000000100000 R10 = 0000000000100000 R11 = 0000000000000000
SP = 000000007ACCF6E0 TP = 000000007B73ED90 R14 = FFFFFFFF8452A9F0
R15 = 000000007B949F20 R16 = FFFFFFFF841E9CB0 R17 = 0000000000100000
R18 = 000000007B763308 R19 = 0000000000000000 R20 = 0000000000000000
R21 = 0000000000000000 R22 = 000000007ACCF6C0 R23 = 0000000000000000
R24 = 000000007B9045B0 R25 = 0000000000000001 R26 = 0000000000000000
R27 = FFFFFFFF8F9A3C7C R28 = 000000000000000F R29 = 000000007ACCF6C0
R30 = 000000000000000C R31 = 0000000000000000 PC = FFFFFFFF84AAAB60
BSP/STORE = 000007FDBFFD43E8 / 000007FDBFFD43E8 PSR = 0000101308026010
IIPA = 000000000099DC48
B0 = FFFFFFFF84AAAB60 B6 = FFFFFFFF841E9CB0 B7 = FFFFFFFF8452A9F0

Interrupted Frame RSE Backing Store, Size = 16 registers

R32 = 0000000000000006 R33 = FFFFFFFFFFFFFFFE R34 = 0000000000000434
R35 = 0000000000000000 R36 = 0000000000000001 R37 = FFFFFFFF84E99900
R38 = C00000000000030B R39 = 000000007ACCF740 R40 = FFFFFFFF8465DA10
R41 = C000000000000184 R42 = 000000007BB2C000 R43 = 0000000000000434
R44 = 0000000000000000 R45 = 000000007ACCF6FC R46 = 000000007ACCF6C0
R47 = 000000007ACCF6C0
WILLEM>

Re: DIG crash

Hoff — Thu, 08 Feb 2007 22:33:36 GMT

No support contract, eh?

Looks to be a bug in tcpip$dig in V5.6, and I see no ECO available.

The source code for the lwconfig.c module is available from various sources, if you want a look at it, or even try to build it. OpenSolaris has a copy. (I don't know which version of the module was used for the TCP/IP Services module.)

Re: DIG crash

Steven Schweda — Fri, 09 Feb 2007 00:34:09 GMT

A quick look at the source for BIND 9.3.4
suggests that it's a null domain name which
causes this particular assert(). I assume a
version difference and/or the fact that the
TCPIP code does something other than parse
the "/etc/resolv.conf" file to get such data
accounts for your line 210 corresponding to
line 197 in the generic source:

lwres_strdup(lwres_context_t *ctx, const char *str) {
char *p;

REQUIRE(str != NULL);
REQUIRE(strlen(str) > 0U); <--- 197.
[...]

Called from (I'm guessing, based on the
generic code):

static lwres_result_t
lwres_conf_parsedomain(lwres_context_t *ctx, FILE *fp) {
[...]
confdata->domainname = lwres_strdup(ctx, word);
[...]

or some place very like that.

I'm too lazy (and far from a suitable test
system) to see exactly what happens on a UNIX
system if there's a complete or partial lack
of resolver configuration data, but it's
probably a near-unheard-of situation in real
life there. And if it does happen, a better
complaint is probably emitted if the fopen()
fails for "/etc/resolv.conf" than this one.
(But perhaps a "resolv.conf" with no domain
name would cause something similar.)

So, I'd guess that you're welcome to report
this problem, but I wouldn't expect a
drop-everything response to do the repair.

If it did explode on a UNIX system, the BIND
folks might do something about it on their
end. (And a fix there might survive the
adaptation to VMS.)

Re: DIG crash

Ian Miller. — Fri, 09 Feb 2007 04:50:54 GMT

FYI - assert calls abort which results in the %SYSTEM-F-OPCCUS, opcode reserved to customer fault

Re: DIG crash

Willem Grooters — Sat, 10 Feb 2007 14:12:09 GMT

Thanks Steven (Schweda) for explaining, I agree DIG has no meaning anyway in such an configuration. But the crash shouldn't happen, and therefroe it should be mentioned. And Hoff: right: no support contract...So what else is there to do than post it here (assuming VMS engineers nonitor this forum).

Re: DIG crash

Willem Grooters — Sat, 10 Feb 2007 14:14:49 GMT

Hoping engineering picks this up one day (No hurry)

Re: DIG crash

Steven Schweda — Sat, 10 Feb 2007 14:25:00 GMT

A potentialy more reliable feedback mechanism
might be the "OpenVMS Systems Product
feedback" Web page. It's not actual support,
but you can more safely assume that someone
looks at it.

http://h71000.www7.hp.com/fb_business.html

There's a link to it from the more obvious
"OpenVMS Systems web site feedback" page:

http://h71000.www7.hp.com/fb_web.html

You could always VMS-ize the original source
yourself, and make it all perfect.

http://www.isc.org/index.pl

Re: DIG crash

Hoff — Sat, 10 Feb 2007 15:32:08 GMT

I'd submit the bug against the original BIND source pool (over at ISC?) pointing to where it's been seen, and OpenVMS and TCP/IP Services can then acquire the fixed code from there during a future code upload.

Re: DIG crash

Steven Schweda — Tue, 13 Feb 2007 14:47:45 GMT

For the record, a quick attempt to get a
similar failure in BIND 9.3.4 on Tru64 V5.1B
failed. The closest I could get was with a
"/etc/resolv.conf" which had a line like:
domain
(instead of, say, "domain antinode.org"), and
then the symptom was a helpful complaint:

urtx# ./bin/dig/dig alp
./bin/dig/dig: parse of /etc/resolv.conf failed

So, the UNIX code seems to handle this
situation just fine, and I think that it's
pretty safe to assume that a complaint to the
BIND people will not avail much, as the
problem is in the TCPIP-specific code (which
does not parse "/etc/resolv.conf"), not the
generic BIND code.

I assume that it would not be difficult to
fix, if one had the source code.