Oops. Looks like I should check to see if main'log is already in the
call stack when I first go into main'log. Alternativly I could set a
semaphore in main'log to make sure I am not reentrant. Suggestions?
In message <199501160207.AA28835@access3.digex.net>,
"Matthew A. Braithwaite" writes:
>hi guys,
>
>you'll love this. btw i don't know a lick of perl, so please excuse
>any awkward descriptions:
>
>main'log calls
>main'lopen calls
>main'shlock calls
>xtmpfile calls
>open_temp calls
>main'abort calls
>main'log.
>
>uh-oh. turns out that if this sequence happens while trying to open
>the logfile, *and* the tempfile cannot be opened (permissions or
>whatever other reason), this will result in an infinite recursion of
>calls to main'log, eventually causing perl to die of a segfault (perl
>really ought to voluntarily limit its stack consumption to cause a
>more meaningful error message).
>
>i realize, of course, that this is due to improprer permission
>settings on my part. still, it's a less that useful way to tell me
>so. :-)
>
>also, i got the (cursory) suspicion that majordomo might (with all
>this tempfile stuff) require write access to the directory where it
>creates the logfile. This seems to be born out by an experimental
>test I performed: take a working configuration, change *only* the
>location of the logfile, and i get the same crash. note that i *did*
>previously create the named logfile, and make it writable to
>majordomo. so this would seem to indicate that majordomo requires
>write access to the directory where the logfile lives. this is a
>limitation that should if at all possible be removed. (my personal
>reason for wanting it so is that i like to keep *all* logs in
>/var/adm.)
>
>anyway, once i fix the permissions all is well. send me a patch if
>you decide to fix this stuff. :-)
>
>thanks!
>
>--
>Matt Braithwaite
> Every program has at least 1 bug and can be shortened by at least 1 line.
>It
> follows that any program can be reduced to one line of code that doesn't wo
>rk.
References:
|
|
