OK, that's just kind of workaround until something better is invented. Actually - I think it would be better to tie STDOUT in the same way STDERR is tied
There are several things related to this issue: 1) Perl crash in particular circumstances. Root cause I think is Perl bug #41121. - Bug still seems to be open. - In fact I don't think Scmbug needs to get into these circumstances at all. I.e. bug could be workarounded relatively easy: a) either don't "pollute" standard outputs with problematic encodings; and/or b) don't call call fork() AFTER Bugzilla initialization: i.e. Scmbug to daemonize early forking BEFORE loading Bugzilla. 2) Bugzilla is trying to modify STDOUT, STDERR encoding (calling binmode) - No real issue with Bugzilla here - it's just trying to adapt to console (running in USAGE_MODE_CMDLINE). - No straightforward way to skip this yet. (That has been designed for single-threaded console-mode usage). ---- So both 1a) and 1b) seem good idea to implement, though 1a) would be enough (tying STDOUT and noop BINMODE) Regards, Yavor On Mon, Mar 14, 2011 at 01:54, Kristis Makris <[email protected]> wrote: > I don't see how doing anything other than calling a Bugzilla function > is the right thing to do. > > I won't apply this patch. > > On Mon, 2011-03-14 at 01:06 +0200, Yavor Nikolov wrote: > > Hello guys, > > > > Here is a patch for this issue: > > 1) I'm just resetting stdout & stderr encodings to utf8 after Bugzilla > > module has been loaded. > > 2) I'm explicitly setting usage mode to ..CMDLINE just in case. (Th > > other modes which are currently available seem to be less > > appropriate). > > * 3) As I've already suggested - setting SERVER_SOFTWARE doesn't seem > > a good idea: it triggers cgi-specific responses (like http 301 > > Redirect and who knows what). > > > > Regards, > > Yavor > > > > >
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
