Bug 2443 - -F option kills segfaults amd
-F option kills segfaults amd
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: am-utils (Show other bugs)
6.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: David Lawrence
:
: 2912 3476 3741 4463 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-04-30 15:21 EDT by ralph
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-15 11:18:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ralph 1999-04-30 15:21:27 EDT
i.e.
[ralph@todd amd]$ ./amd -F amd.conf
Segmentation fault (core dumped)

[ralph@todd amd]$ cat amd.conf
[ global ]
dismount_interval =             240
Comment 1 kenneths 1999-05-31 11:56:59 EDT
I had the same problem, it occurs whenever you use -F and not
-x noall.

I have traced the problem to the glibc21 patch which sets the logging
facility to NULL in libamu/xutil.c. If any logging is done before
 switch_to_logfile is called in amd/get_args.c, amd will try to log
to a FILE* that is NULL, hence the core dump. A quick hack is to use
this patch instead of the glibc21, but it doesnt really fix the
problem:
 --- am-utils-6.0/libamu/xutil.c.glibc21 Sun Dec 27 07:25:24 1998
+++ am-utils-6.0/libamu/xutil.c Fri May 28 16:21:09 1999
@@ -48,7 +48,7 @@
 #include <am_defs.h>
 #include <amu.h>

-FILE *logfp = stderr;          /* Log errors to stderr initially */
+FILE *logfp = NULL;            /* Log errors to stderr initially */

 static char *am_progname = "unknown";  /* "amd" */
 static char am_hostname[MAXHOSTNAMELEN + 1] = "unknown"; /* Hostname
*/
@@ -310,6 +310,10 @@
   time_t t = clocktime();
   char *sev;

+  if(logfp==NULL){
+       fprintf(stderr, "Setting logging facility to STDERR\n");
+       logfp=stderr;
+  }
   if (t != last_t) {
     last_ctime = ctime(&t);
     last_t = t;
--- am-utils-6.0a16/include/am_defs.h.glibc21   Thu Jan 21 11:15:18
1999
+++ am-utils-6.0a16/include/am_defs.h   Thu Jan 21 11:23:54 1999
@@ -308,7 +308,7 @@
  * like Linux, it also defines "struct datum".
  */
 #ifdef HAVE_NDBM_H
-# include <ndbm.h>
+# include <db1/ndbm.h>
 # ifndef DATUM
 /* ensure that struct datum is not included again from
<rpcsvc/yp_prot.h> */
 #  define DATUM

As you can see, it sets the logfd pointer to stderr if it is NULL, in
static void show_time_host_and_name(int lvl), which is called before
any logging is commited to a FILE*. However, this is probably not the
right place for it. Either the FILE * logfd = NULL should be fixed,
but im not wuite sure why gcc chokes when we set FILE * logfd =
stderr, as is done in the vanilla am-utils distribution. Or perhaps
one should put logfd=stderr early in amd/amd.c: int main(int argc,
char *argv[]).

Anyway, I will put up i386 RPMS and SRPMS of the am-utils with the
previous patch on ftp.oslo.sintef.no/pub/kenneths shortly.
Comment 2 kenneths 1999-05-31 18:23:59 EDT
The bug occured in other programs that came with the am-utils pkg to.
I have fixed them. Patch will be sent to bugzilla@redhat.com. RPMS and
SRPMS are at ftp.oslo.sintef.no/pub/kenneths. Its release 4 of the pkg
that has the full fix.
Comment 3 Jeff Johnson 1999-06-15 11:00:59 EDT
*** Bug 2912 has been marked as a duplicate of this bug. ***

using config files from my 5.2 installation with
the 6.0 version of am-utils causes am-utils to
crash with a core dump.

BTW: I tried picking up the sources from the author and they
      would not compile in the 6.0 environment.

------- Additional Comments From jbj@redhat.com  05/18/99 18:17 -------
Can you supply a (minimal if possible) configuration so that we
can reproduce the problem? A stack back trace would help also.

What type of compile failure are you seeing?

------- Additional Comments From jbj@redhat.com  05/18/99 18:17 -------
Can you supply a (minimal if possible) configuration so that we
can reproduce the problem? A stack back trace would help also.

What type of compile failure are you seeing?

------- Additional Comments From kenneths@regina.uio.no  06/01/99 15:43 -------
I guess this is the same bug as # 2443, I have submitted patches
for this bug, and made some comments on it.*** Bug 3476 has been marked as a duplicate of this bug. ***

I have hit a (show-stopper) problem with am-utils-6.0-3
under
redhat 6.0 (this is after a clean "everything" install). If
you try to use the -F option - which allows you to point to
an
external configuration file - amd promptly dumps core (some
amd options I use in our machines are only accessible from
the
configuration file as opposed to command line switches).

The core dump appears to be related to an fprintf to stderr
that's processed when the configuration is parsed from the
command line and the "-F" flag is found. A message is
supposed
to be printed to stderr but instead the whole thing core
dumps. Commenting out the offending line and rebuilding the
whole package is the workaround I'm currently using. This
might be a problem with the underlying glibc2.1...
Comment 4 Jeff Johnson 1999-06-15 11:18:59 EDT
Fixed in am-utils-6.0-4. Thanks for the patch.
Comment 5 Cristian Gafton 1999-08-29 14:12:59 EDT
*** Bug 4463 has been marked as a duplicate of this bug. ***

If you use the -F option of amd, the it immediately
segfaults. I have tracked it down to one of the patches
applied to deal with glibc 2.1. The problem is that the
output log FILE descriptor has not been set. I will send a
patch.
Comment 6 Cristian Gafton 1999-08-29 14:13:59 EDT
*** Bug 3741 has been marked as a duplicate of this bug. ***

The version of amd distributed with RH 6.0 segfaults while
reading my amd config files.  A previous release (not the RH
5.1 one) that I was running on RH 5.1 works fine.

Here's a uuencoded gzip'd tar file containing my amd config
files.  I do not know if this data survived the cut and
paste into your description window.  I know that Netscape
ate at least the single backquote character that should be
on the next-to-last line right above the "end" keyword.

begin 644 amd.tar.gz
M'XL(".H0=#<``V%M9"YT87(`[5QM;]LX$NY7ZU>P27&]6\2V)%OV;8(L4&"[
M=X?;-D73[7YH%P$MT;9JB=22=!QOT?]^0XJ2)<>6G"*V6YP&"&I)S\SP968X
MI$8ETN^*I?`9'8>3+HZ#)X]/CFT/^GWT!"FRU_Y5-.PA-!BZKF/W[9Z-D./V
M>NX39.^A+?=H+B3F"#WAC,DJ7-WS[Y1>_/R?MY==;+VZ^NWUNS?OKB^M%Z]^
MOE(_GK=_05T"Y@%&H?XZRD90FZ/V'<)1]-PZ=M,;>@0R$ZPG=U\ZE/_;ZWY?
M\'_'`Y\?>)[KN7W75O[ON(-^X_^'H&Y`QG@>28'&XOSRV6<\ERP(^9?NL\]\
MRH3\TE4=5U=C\>6")5)<4B;F87!&64!NK1_,'&JP$C`CRR\7<IF0\TMUZX(K
MN=TF6'RCE`7X?>I`?7OH>17K/U+^/^QYMF/W'`_\W^YYX/_>/AN5T?^Y_Z\O
M\/O049?_]?MJ_@?]P=#KN<Y0Y7^V-VSB_R'HPR1B(QS]8<4XN5%A&UVB<1@1
M2Q#,_>E-@N44;F6)H(6L#UW,&0U&*0O%L6()1AWU%!Z.HJ#T!*ZS1["N$%^6
M^?0M#1AQMA!X%)$;N"G@V9((Q35E,2GQJ!N5')24E<!UU@3!_=(CN,X?+<I/
M%OK!L>=GWY3YOYFFO>BH\7_7T_X_=#UOV!O:`Y7_#9W&_P]">?[74KG=^:7.
MZLXX.^,B_(M<_M/YT3U;Y#]-8D?'(H)(<(JN*"(33B12]@.B;A&F07IQ2SC"
MG*"(^3A"G."@N^"A)#JZ(+$4DL2B@]"+*`)!3$X!'V-_&E(B4,SF5"*X%Z,Q
M9[%1HH2T&8V6'<L"72UR%PHI_M[5*K32-/W\AVEF%-+9A4X_UQ$7:6?Y`GVT
M6D^WRS%9K59O,MEUD&5!3UL*=VEP#U*N&)]F"G;0EG!R.&4A%8=39ED_M%H&
M."(81M4@0:A=!%Z_?/O^Y=N;=R^OW^V$MT2$Z:1"ML$M&)^)*4NV`Z_G]'<`
M70.H^]Y[[72O681Y*')-IPCL\@9,-^',AR8X9^:'>[[\>)XYB8$QX=;B8`:J
MQ0'`P*K%Y3B)HV@+SCP%'%A9M5H`&%BUVA0G6;)='(RQ"!GM`LA`MXLL8V]_
M'-:+!9"!UHLU6,*K.P\``ZONO,(=.[[74;;^IPG<?G34K/^>[;KY^C]09\&.
MX_6;\Y^#4'G]SY;_NK7?PC(&<P_RH`K7@O#;8K!4NP0PJRPV!LFDQ"$HGA&#
M)W<)XU)G^CE\/J*L&+,+@=A9EST1B21"YG`93LJ!>PT?2KKTYUAF>)`NIY7X
M/W$N_$\LB!^,[L%S;*DIT9QB[FP#1Z.97@<S=,(FK-C/51.B@*K]V&I$YE$4
ML$E%HX$CBLG#&%@8J<1JE]:(,&[M!J0XV0U9&KAJ),>!WI\^J'=2!*.'C<=B
ML2B,AYS.QV')KDK@)8[%`\3'>)RC)PS+%;0((K`B%YHP71**5TBO9$V4+,I#
M&%;I!Q<H652=TP#>YV3EP*-0,%J-5PG%[JTI6FLMF).)[NO.^&35D@4!%XY6
M>'<#OF3>=<(!'&")'S"2BF,UJS7A#?"E>=VE_=IR8[:[AK*IC]G=1GO,@<7^
M5H-UU,]&,L*PBLS%9A\"?,F'ZL<QN1\(JCO*`I_<R>+(*`!$8-_M+##M3$3'
M9[$1L)&WV)T'\98"?>T4`H/V_:*1UXT'\(@E]7>T6T`_(%HH=#%\UG<@74JV
M!*[R,JA2!\)W]V=(/@I-J10-T%*[JP4OW5DY22&^:EL;[E?[L](QP3+;FX\(
MV;)9+K.J?7(KTZ:8^%:HMO:RE@46R</5:*X*/<?.2!LZ)&7[O^Q0?1\Z:O9_
M/7LPU.__7*_GN4Y?O?]Q;*?9_QV"MIS_UA_^6J?H+<$1FD.`%&@1RJE^,6/>
MZ#`>$H$810)6:-E19WM92%4WVI"JFABD^5=G@*?HC2#S@+6-W"E#4WQ+0!1!
MZ:NJLAIU%NS?BA8.`G/XR"XV)ZA.OK6DXEYCSE/8+>;Y/B[&R;8V%T\-U:E/
MS&B^OJ270FX\8MS>/[S6+35V!!;%)5)RH9,J2@LVEJW-`=\H&$O8:VU&%'?7
M4RF38!>@P/$([P1<CB`AV(9,L#_#$R*Z*:RM_ARG8W=ZG9ZU;DHP)`%#E,ET
M9*JL2KT!I*.M.Y*2;8U)%+$XQ^+R072Q+Q&FY--N0BF>4QGOAN7S$=FUL2*D
MD^DL-`O]A+,XW';\7N3;<`!O>+.-IKFJX[?DG+/9CAV[)73"`]/6L4]'[?3.
MUS6X*"#;8!1OU39]$;$`STQS_L(C/\1?UQ+#:QJ17=7J5_;\$C8$Z+\AGR%R
MEQ`>QH1*F%*$)7H5S@AZIX;WN4`!$3.PXQD@23;8`:,@<&MX)"R)"`HI^I51
M@&I_42_:RHIT0!8)YN`AH&#"6##^5*]!^-,([]"28R];#3T2Y>?_>2'&X^NH
MR?^<GC=<G?\/=/U/O]]K\K]#T%?G?RH?:54F2%G&HG]DX9%9.G3>B"G$K$KV
M-,1JW#UF[M>S=@"U8HQQ&%4W5R$,'OL2`BF[M"'M\GW&@YOB<9=)\=R4>7K>
MU7$9;4"FM\RX`=N$X_CBHP*W6KK$X?SR)"^QUS=N"E)0Q:,-A;K//JM:K2\G
MF8(YS57,!>^.0MJE?C)/2RM6ORHD06;-Z+U.F7OW>K6U2T4AZWTJ/:ONU*/T
MZ-CN]LU1-AVF1FXO.NKJ/[U>7]=_>I[=[WM]7?_EVDW\/P0]O/X_6R/2SP!T
M&=B_,0T@)U5&U%5,B),QX83Z1%5X_3XE5.]B42A439<I"3/%7F?H$TR!VOLA
M#*+$,AZQ*/21RM6!^4H5ABU"`;C4NU7Y"AMK.9S$3)),$&33Z7MD$J05K*=9
ME1D*XY@$(98D6J:)\>M?KCO0\NSCA72K4/IV8;55@.<?+51`/MWTE4/I\X?O
MZ)N'S/]-(>Q>=-3YOSL<K/(_E0N"__<&C?\?@E;^7ZS_"%25Y2Y98/DEYEJY
MG%B`517.R8(=H:J@<C?DL4?O^Z?<_Q='J_]"CM=;U7^[NO[;&S3UWP>AS?5?
M._K_ZE1_8ZWLU77;`\-JG/4;IJU;S$?4`?Y?^?U?O^]H_^_9L`7P7/#_OMUK
MZC\/0J=/D=Y(BZEE_7KUK_056,3T?P71ACVUM@O+TA@P"X)^^@D]`R!R?_J;
M8X5C]`$]1>T`/7/0'Q<J*Z=6B_A3ADY\3K`^BD[S]H2%L'4'W$E91"N>P7X#
MM1,EHO1D'%J6%I4UPQRQJ!=`ZUBK>"*0@MO7&3Y-W]N_(7-RT]%'V9UQZ/N=
MB4#M-^CD!+7?H_008DWRL2=HS[3]..;Q=-3Z?_K_?SA.;V"[`^W_$`L:_S\$
M5?E_)_.E\\PN8$-]M%B@)6UT<].Z@H?7^/3C2#GVU#744$,--=100PU]%?T/
(7SN'!`!0````

end


------- Additional Comments From jbj@redhat.com  06/26/99 10:11 -------
Can you reply to this message with your config file attachment?
Thanks ...

------- Additional Comments From gafton@redhat.com  07/28/99 03:24 -------
assigned to jbj

Note You need to log in before you can comment on or make changes to this bug.