On Thu 03 May 2007 at 01:17:19 +0200, Rhialto wrote:
> So read(2) reads 1496 extra 0 bytes?!? That seems sooo unlikely...

so I went tracing trough read() with "stepi" (is there some way to get
gdb to show the next machine instruction after each stepi? instead it
shows the next C line which is rather useless) and quickly got lost in
the dynamic loader. So I linked statically, reran and things changed
again...

 I found only one disk, sd0.
 Therefore I assume you want to upgrade NetBSD on it.
 
 
 
 
 

 
                           lqqqqqqqqqqqqqqqqqqqqqqqk
                           x>Hit enter to continue x
Program received signal SIGSEGV, Segmentation fault.
0x0005dadb in strlen (0)
(gdb) bt
#0  0x0005dadb in strlen (0)
#1  0x0001fff0 in waddnstr (623488, 0, -1)
#2  0x00020033 in waddstr (623488, 0)
#3  0x00011b4a in draw_menu_line (m=0x81398, opt=0, cury=1, arg=0x0, 
    text=0x0, 529304, 0, 1, 0, 0) at menu_defs.c:1559
#4  0x00011e12 in draw_menu (m=0x81398, arg=0x0, 529304, 0) at menu_defs.c:1617
#5  0x00012808 in process_menu (num=12, arg=0x0, 12, 0) at menu_defs.c:1924
#6  0x00014806 in do_upgrade ()
    at /vol1/rhialto/cvs/src/distrib/utils/sysinst/arch/vax/../../upgrade.c:74
#7  0x00010790 in opt_act_4_1 (m=0x81178, arg=0x0, 528760, 0)
    at menu_defs.c:273
#8  0x0001290d in process_menu (num=4, arg=0x0, 4, 0) at menu_defs.c:1947
#9  0x00013f38 in main (argc=1, argv=0x7fffebcc, 1, 2147478476, 2147478484)
    at /vol1/rhialto/cvs/src/distrib/utils/sysinst/arch/vax/../../main.c:210
(gdb) up
#1  0x0001fff0 in waddnstr (623488, 0, -1)
(gdb) up
#2  0x00020033 in waddstr (623488, 0)
(gdb) up
#3  0x00011b4a in draw_menu_line (m=0x81398, opt=0, cury=1, arg=0x0, 
    text=0x0, 529304, 0, 1, 0, 0) at menu_defs.c:1559
1559                    waddstr(m->mw, MSG_XLAT(text));
(gdb) print text
$1 = 0x0
(gdb) up
#4  0x00011e12 in draw_menu (m=0x81398, arg=0x0, 529304, 0) at menu_defs.c:1617
1617                            draw_menu_line(m, m->numopts, cury++, arg, m->exitstr);
#5  0x00012808 in process_menu (num=12, arg=0x0, 12, 0) at menu_defs.c:1924
1924                    draw_menu(m, arg);
(gdb) up
#6  0x00014806 in do_upgrade ()
    at /vol1/rhialto/cvs/src/distrib/utils/sysinst/arch/vax/../../upgrade.c:74
74              process_menu(MENU_distset, NULL);


Well, yes, if one passes NULL... then MSG_XLAT(text) seems likely to be
NULL as well.

/scratch2/obj.vax/distrib/utils/sysinst/arch/vax/menu_defs.h:#define
MSG_XLAT(x) msg_string(x)

(gdb) call msg_string(0)
$2 = 0x0

waddnstr(3)'s 2nd arg is indeed a char *.
waddstr(3)'s  2nd arg is indeed a char *.
menu_defs.c is generated .../obj.vax/distrib/utils/sysinst/arch/vax/menu_defs.c

#include "msg_defs.h"
const char *msg_list[] = {
NULL,
"usage: sysinst [-r release] [-f definition-file]\n"
...

const char *
msg_string(msg msg_no)
{
    int m = (intptr_t)msg_no;

    if (m > sizeof msg_list / sizeof msg_list[0])
	/* guess that we were passed a text string */
	return msg_no;

    if (msgmap != MAP_FAILED && m != 0 && m <= msgmapcount) {
	unsigned int offset = atoi(msgmap + 8 + 8 * m);
	if (offset != 0 && offset < msgmapsz)
	    return msgmap + offset;
    }

    return msg_list[m];
}

so msg_string(NULL) indeed returns msg_list[0] which is NULL.

But why does this apparently work when linked dynamically?
Or maybe it doesn't, but does not crash for some reason, but instead
causes the later call to read(2) to fail? Hmmm... Other calls to
process_menu() also have a NULL argument, so this seems quite
intentional. I'm getting more and more confused.
It doesn't seem to be VAX-specific, either.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.