>Number:         8912
>Category:       lib
>Synopsis:       vfprintf/strlen problem (stdargs.h)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 28 16:57:00 1999
>Last-Modified:
>Originator:     Makoto Fujiwara
>Organization:
        Fujiwara at Nagazu
>Release:        <NetBSD-current source date> 1.4
>Environment:
	
System: NetBSD fujiwara 1.4 NetBSD 1.4 (GENERIC-at) #0: Mon May 10 15:23:29 JST 1999 makoto@fujiwara:/usr/src/sys/arch/sparc/compile/GENERIC-at sparc


>Description:
	
++ use mailshar 

makoto@fujiwara$B"#(B9:20:46/991129(...htdocs/usrlocal)> mailshar makoto@ki.nu gs*
Segmentation fault - core dumped
makoto@fujiwara$B"#(B9:20:54/991129(...htdocs/usrlocal)> 

++ version of the mailshar
makoto@fujiwara13:50:01/991126(~)> which mailshar
/usr/local/bin/mailshar
makoto@fujiwara9:46:48/991129(~)> mailshar --version
mailshar - sharutils 4.2.1

++ How did I get sharutils
above sharutils compiled after getting gettext-0.10.35 with just
./configure;make
I got the same symptom with sharutils 4.2

++ gdb trace
makoto@fujiwara$B"#(B9:20:54/991129(...htdocs/usrlocal)> ls *core
shar.core
makoto@fujiwara$B"#(B9:21:13/991129(...htdocs/usrlocal)> gdb /usr/local/bin/shar shar.core
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc--netbsd"...
Core was generated by `shar'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libc.so.12.40...done.
#0  0x10085000 in strlen ()
(gdb) where
#0  0x10085000 in strlen ()
#1  0x10082fa4 in vfprintf ()
#2  0x100823c4 in fprintf ()
#3  0x3a9c in generate_one_header_line (local_name=0xeffff280 "gs-Makefile.patch", restore_name=0xeffff280 "gs-Makefile.patch") at shar.c:699
#4  0x2ae8 in walkdown (routine=0x3a68 <generate_one_header_line>, local_name=0xeffff280 "gs-Makefile.patch", restore_name=0xeffff280 "gs-Makefile.patch") at shar.c:287
#5  0x2d50 in walktree (routine=0x3a68 <generate_one_header_line>, local_name=0xeffff61b "gs-Makefile.patch") at shar.c:410
#6  0x44f0 in generate_full_header (argc=4, argv=0xeffff550) at shar.c:856
#7  0x81b0 in main (argc=11, argv=0xeffff534) at shar.c:2082
(gdb) 

------------------ shar.c around line 699 -----------
/*---.
| ?  |
`---*/

static int
generate_one_header_line (local_name, restore_name)
     const char *local_name;
     const char *restore_name;
{
  fprintf (output, "# %6ld %s %s\n", struct_stat.st_size,
	   mode_string (struct_stat.st_mode), restore_name);
  return 0;
}
-------------- (man fprintf) -------------------------------
     #include <stdarg.h>
     int
     vfprintf(FILE *stream, const char *format, va_list ap);
-------------------------------------------------------------
>How-To-Repeat:
	
   I think above section describes how to  reproduce the problem.

   The list of files I meant with gs* is shown below. It is little bit
file name dependent, but the possibility is high to core dump.

  makoto@fujiwara9:51:11/991129(...htdocs/usrlocal)> ls -l gs*
-rw-r--r--   1 makoto   10           1603 Nov 26 12:59 gs-Makefile.patch
-rw-r--r--   1 makoto   wheel         245 Nov 26 13:27 gs-gxxfvf.c-patch
-rw-r--r--   1 makoto   wheel         355 Nov 26 15:40 gs-gxxfvf.c-patch-VF_Init
-rw-r--r--   1 makoto   wheel       13451 Nov 26 17:00 gs.shtml

>Fix:
	

  Sorry I don't know yet.
>Audit-Trail:
>Unformatted: