Bugzilla 4.0 console initialization causes perl crash in fork() on Windows
Yavor Nikolov
We're facing an issue with Bugzilla 4.0 on Windows (perl 5.12.3 - reproduced both with Strawberry and ActiveState).
This affects scmbug (http://www.mkgnu.net/scmbug) which is directly Bugzilla as Perl libraries.
Simplified test looks like that:
use Bugzilla;
my $pid;
defined ( $pid = fork() ) or die( "Can't fork: $!\n" );
print "something [$pid]";
And this crashes in fork call (print is never reached).
***
Root cause of the problem is changing stdout/stderr encodings in Bugzilla::Install::Util->set_output_encodings(). (This is called by Bugzilla.pm init_page which is called on module initialization).
The deadly combination is something like that:
# code page of console is somehow detected - e.g. cp866
binmode STDOUT, ":encoding(cp866)";
defined ( $pid = fork() ) or die( "Can't fork: $!\n" );
# this is enough to crash perl when forking
(binmode to utf8 doesn't seem to cause such failures).
* Setting SERVER_MODE environment variable prevents the error however this results in running some CGI-specific code (i_am_cgi returns true, etc) which is maybe bad idea in our case. (Scmbug is running as OS daemon process).
* Bugzilla 3.6 is not affected
* This doesn't fail on Linux.
***
Q1. What usage_mode is appropriate to be used in our case (OS daemon)?
Scmbug used to run in USAGE_MODE_CMDLINE in Bugzilla 3.6, however I'm not sure that's appropriate now having this console-specific encoding tweaking.
Q2. Is the behavior described above expected or this is a bug? (Looks like Windows-specific Perl bug to me).
Max Kanat-Alexander
> use Bugzilla;
> my $pid;
> defined ( $pid = fork() ) or die( "Can't fork: $!\n" );
> print "something [$pid]";
>
> And this crashes in fork call (print is never reached).
This is very likely a bug in Perl; I'd suggest reporting it to the Perl
maintainers. If you have any trouble reaching them, let me know and I'm
happy to help.
-Max
> Q1. What usage_mode is appropriate to be used in our case (OS daemon)?
USAGE_MODE_CMDLINE would be right.
-Max
--
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services
Yavor Nikolov
Thanks for your reply!
On Mon, Mar 21, 2011 at 11:14, Max Kanat-Alexander <mka...@bugzilla.org>wrote:
> On 03/07/2011 11:02 AM, Yavor Nikolov wrote:
> > use Bugzilla;
> > my $pid;
> > defined ( $pid = fork() ) or die( "Can't fork: $!\n" );
> > print "something [$pid]";
> >
> > And this crashes in fork call (print is never reached).
>
> This is very likely a bug in Perl; I'd suggest reporting it to the
> Perl
> maintainers. If you have any trouble reaching them, let me know and I'm
> happy to help.
>
Actually this seems to be a known bug (not fixed yet):
http://rt.perl.org/rt3/Public/Bug/Display.html?id=41121
Another thing is that it got clear that Bugzilla is not fork-safe (db
handles are broken in child process if they have been initialized before the
fork /even when parent process immediately exits after fork/. At least this
is the case with DBI:Pg). So it would be good idea to move any forking
before Bugzilla initialization anyway.
>
> -Max
>
> > Q1. What usage_mode is appropriate to be used in our case (OS daemon)?
>
> USAGE_MODE_CMDLINE would be right.
>
OK - seemed to be the best fit to me too.
However I think it would be good idea to be able to somehow skip these
console-specific initializations: those are unlikely to be desired when
embedding Bugzilla in some daemon app, batch script, etc. I.e. the embedding
application should be responsible for formatting it's outputs.
There are some workarounds now (reset outputs encoding after Bugzilla is
initialized; or tying them in order to override binmode). But those don't
seem very clean and need special attention on when exactly is Bugzilla.pm
module loaded.
Another thing which is related to usage mode - would be good to be able to
set the usage_mode before Bugzilla module is initialized. Currently it
happens so that the first call of init_page is always getting the default
usage_mode.
>
> -Max
> --
> http://www.bugzillasource.com/
> Competent, Friendly Bugzilla, Perl, and IT Services
> _______________________________________________
> support-bugzilla mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put support-...@lists.mozilla.org in the To: field when you
> reply.
>
Best Regards,
Yavor
Max Kanat-Alexander
> Actually this seems to be a known bug (not fixed yet):
> http://rt.perl.org/rt3/Public/Bug/Display.html?id=41121
Okay, good to know.
> Another thing is that it got clear that Bugzilla is not fork-safe (db
> handles are broken in child process if they have been initialized before the
> fork /even when parent process immediately exits after fork/. At least this
> is the case with DBI:Pg). So it would be good idea to move any forking
> before Bugzilla initialization anyway.
That makes sense. Bugzilla is not designed to fork or thread.
> However I think it would be good idea to be able to somehow skip these
> console-specific initializations: those are unlikely to be desired when
> embedding Bugzilla in some daemon app, batch script, etc. I.e. the embedding
> application should be responsible for formatting it's outputs.
Mmm, that's possible. You could also specify a LANG environment
variable when starting the daemon, like "en_US.UTF-8" that would cause
the encoding to go UTF-8.
Yavor Nikolov
Yes, that seems to work fine on *nix. The problem currently is with insane
Windows-based setups (maybe except Cygwin) and also with non-unicode locale
environments.
>
> -Max
> --
> http://www.bugzillasource.com/
> Competent, Friendly Bugzilla, Perl, and IT Services
> _______________________________________________
> support-bugzilla mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put support-...@lists.mozilla.org in the To: field when you
> reply.
>
Regards,
Yavor
Max Kanat-Alexander
> Yes, that seems to work fine on *nix. The problem currently is with insane
> Windows-based setups (maybe except Cygwin) and also with non-unicode locale
> environments.
Oh, well, there's probably some reasonable way to do this on Windows,
perhaps with some Perl code at startup time.