Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 May 2005 11:09:28 +0800
From:      Xu Qiang <Qiang.Xu@fujixerox.com>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>, Xu Qiang <Qiang.Xu@fujixerox.com>
Cc:        freebsd-questions@freebsd.org
Subject:   RE: The availability of socketbits.h?
Message-ID:  <20050518030008.1E5F71D93F@imss.sgp.fujixerox.com>

next in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote:
> A bug in the program.  The relevant code seems to be this part of
> nngs-1.1.14/nrat/command.c:
> =

>    1131 void commands_init()
>    1132 {
>    1133   FILE *fp, *afp;
>    1134   int i =3D 0;
>    1135
>    1136   fp =3D xyfopen(FILENAME_CMDS, "w");
>    1137   if (!fp) {
>    1138     return;
>    1139   }
>    1140   afp =3D xyfopen(FILENAME_ACMDS, "w");
>    1141   if (!afp) {
>    1142     fclose(fp);
>    1143     return;
>    1144   }
>    1145   for (i =3D 0; command_list[i].comm_name; i++) {
>    1146     if (command_list[i].adminLevel >=3D ADMIN_ADMIN) {
>    1147       fprintf(afp, "%s\n", command_list[i].comm_name);
>    1148     } else {
>    1149       fprintf(fp, "%s\n", command_list[i].comm_name);
>    1150     }
>    1151   }
>    1152   fclose(fp);
>    1153   fclose(afp);
>    1154 }
> =

> If we put for a while the horrible style aside, the bug seems to be
> that the for loop doesn't properly check the bounds of the
> command_list[] array.  This would probably be ok if the command_list
> array was declared to have a trailing element set to an "all zeroes"
> value: =

> =

> 	struct command_type command_list[] =3D {
> 	  {"accept",            "n",    com_accept,     ADMIN_USER },
> 	  {"actitle",           "dS",   com_actitle,    ADMIN_ADMIN },
> 	  {0,			0,	0,		0 },
> 	};
> =

> but it's not (look in nngs-1.1.14/nrat/command_list.h):
> =

> 	 /* Name        Options Functions       Security */
> 	struct command_type command_list[] =3D {
> 	  {"accept",            "n",    com_accept,     ADMIN_USER },
> 	  {"actitle",           "dS",   com_actitle,    ADMIN_ADMIN },
> 	  [...]
> 	  /* by Syncanph */
> 	  {"shownote",          "",     com_shownote,   ADMIN_USER },
> 	};
> =

> and this is *EXACTLY* where this particular bug lies.

Thank you, Giorgos. You hit the cause I didn't see. =


But after compile, there is a new segmentation fault, here is the GDB trace=
: =

gso_dev_2# gdb nngssrv nngssrv.core =

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.=

This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `nngssrv'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.2...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x281803d2 in strcmp () from /lib/libc.so.5
(gdb) bt
#0  0x281803d2 in strcmp () from /lib/libc.so.5
#1  0x2817f125 in qsort () from /lib/libc.so.5
#2  0x0805d740 in command_init () at command.c:212
#3  0x0805ae95 in main (argc=3D1116386171, argv=3D0xbfbfe958) at nngsmain.c=
:158

It seems still related to the array of command_list. =


Any further suggestions?

thanks, =


Regards,
Xu Qiang




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050518030008.1E5F71D93F>