A few more observations (basically I'm calling Bugzilla::User->check(
'invaliduser' )):
Scenario 1: (SERVER_SOFTWARE=1; usage_mode uninitialized): results in cgi
BROWSER mode. Errors are formatted as html; possible interactive questions
to user.
Scenario 2: (SERVER_SOFTWARE=1; usage_mode = ...XMLRPC): results in
complications when error needs to be reported:
Can't locate object method "faultcode" via package "SOAP::Fault" (perhaps
you forgot to load "SOAP::Fault"?)
Scenario 3: (SERVER_SOFTWARE=1; usage_mode = ...CMDLINE): this seems to work
OK in my test. However:
- Results in Bugzilla internal function i_am_cgi() returning true and maybe
some other cgi-specific stuff. Maybe that won't cause serious problems but I
don't like it very much. E.g. following is executed in such case:
# This makes sure we're in a CGI.
if ($ENV{SERVER_SOFTWARE} && !$ENV{MOD_PERL}) {
require CGI::Carp;
CGI::Carp->import('fatalsToBrowser');
}
- Console initialization (init_console call) is never performed. Which is
maybe good. binmode STDERR is never touched in this scenario (just binmode
STDOUT, ':utf8')
***
So the current options are:
(1) Use Scenario 3.
(2) "Hack" Bugzilla code. (Could be result of Bugzilla team fixing a bug if
this is considered a Bugzilla bug).
(3) Switch to non-windows environment (and SERVER_SOFTWARE unset;
usage_mode=...CMDLINE). Actually this would result in locale-based encoding.
I don't know if that's good or bad.
Regards,
Yavor
On Mon, Mar 7, 2011 at 08:45, Yavor Nikolov <[email protected]> wrote:
> Hi,
>
> I managed to setup a test environment on Win32 (using strawberry perl -
> latest version).
>
> Seems the problem is reproducible for me too. Simplified test looks like
> that:
> use Bugzilla;
> $pid = fork();
> print "something [$pid]";
>
> And this fails (print is never reached).
> Trying to call Bugzilla->usage_mode( USAGE_MODE_*** ); doesn't have desired
> effect since module needs to be initialized before that call.
>
> Only setting SERVER_SOFTWARE seems to prevent the problem from what I've
> tested so far. Or changing Bugzilla code.
>
> ***
> Root cause of the problem is changing stdout/stderr encodings in
> Bugzilla::Install::Util->set_output_encodings().
>
> The deadly combination is something like that:
> # code page of console is somehow detected (used to be utf8 before)
> binmode STDOUT, ":encoding(cp866)";
> defined ( $pid = fork() ) or die( "Can't fork: $!\n" );
> # this is enough to crash perl when forking
>
> In scmbug point of view I don't think we want to change encoding to
> something like that at all. (I'm not sure what's best - maybe utf8 as it
> used to be)
>
> ***
> I think it would be best if we ask Bugzilla team for their opinion too:
> 1) Report the described behavior (Bugzilla is crashing fork unless
> SERVER_SOFTWARE is set)
> 2) Module initialization takes place before before usage_mode(...) so how
> to switch usage_mode then?
> 3) Which mode would be best for us to use /maybe new one/
>
>
> Regards,
> Yavor
>
> 2011/3/6 Kristis Makris <[email protected]>
>
>> On Thu, 2011-03-03 at 12:48 +0100, Thorsten Schöning wrote:
>> > script? If this works, Kristis may have to options: Issue a call to
>> > Bugzilla::usage_mode with USAGE_MODE_BROWSER before doing anything
>> > else with Bugzilla or defining the env variable before using Bugzilla.
>>
>> Could someone test this before I release something that breaks Bugzilla
>> 4.0 for everyone?
>>
>> In particular, test NOT setting SERVER_SOFTWARE=1 in ENV. This sounds
>> like poking under the Bugzilla covers. Using Bugzilla::usage_mode sounds
>> more proper.
>>
>> _______________________________________________
>> scmbug-users mailing list
>> [email protected]
>> http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
>>
>>
>
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
