DIG crash

[Willem Grooters]

(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>

[Hoff]

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.)

[Steven Schweda]

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.)

[Ian Miller.]

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

[Willem Grooters]

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).

[Willem Grooters]

Hoping engineering picks this up one day (No hurry)

[Steven Schweda]

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

[Hoff]

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.

[Steven Schweda]

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.