Undefined subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78. main::die_with_dignity('Undefined subroutine &main::ThrowCodeError called at Bugzilla/CG...') called at Bugzilla/CGI.pm line 78 Bugzilla::CGI::new('Bugzilla::CGI') called at Bugzilla.pm line 81 Bugzilla::_init_transient('Bugzilla=HASH(0x832356c)') called at Bugzilla.pm line 35 Bugzilla::create('Bugzilla') called at globals.pl line 1702 require globals.pl called at ./processmail line 31 Compilation failed in require at ./processmail line 31. main::die_with_dignity('Undefined subroutine &main::ThrowCodeError called at Bugzilla/CG...') called at ./processmail line 31 This shows up visually to the user as "Status: 400 Bad Request (invalid multi-part post)" in the spot where the output from processmail normally goes when responding to a posted attachment. The fundamental problem here appears to be that Bugzilla.pm is creating a Bugzilla::CGI object when it's not called from a CGI environment (processmail is a separate program). Unfortunately, all the environment variables are still hanging around and there's nothing left on standard input to parse, so it totally dies. Although I believe the symptoms of this will be fixed by moving processmail to a module (which is another bug, and almost ready for checkin I believe), the core problem of automatically creating a CGI object from Bugzilla.pm should probably be dealt with because Bugzilla.pm should really be loadable from any program wishing to access Bugzilla, whether it's CGI or not, and trying to load CGI when you're not in a CGI environment isn't always pretty, as demonstrated here.

btw, this is in the 2.17.3 tarball....

I should think this would be "fixed" by bug 124174, yes.

Hmm. That should lead to empty cgi data. Can you check what the error text is? processmail will need to require "CGI.pl" for that to work. Thats a separate issue, but the globals<=>CGI dependancies have always been messy.

I played with this a bit over the long weekend. I was going to fix this by creating the Bugzilla object in each script, but there are complications due to the interactiosn with stuff in globals.pl. A quick hack for anyone running cvs is to test $^0 (or whatever the var is for the script name). I'll try to get a better solution working tonight.

Ug. there are checksetup.pl interactions too... Does that fle still need globals.pl included?

Once upon on a time we were trying very hard to avoid including globals.pl in checksetup.pl because of wierdness that can happen. I'm really not sure when that changed (although I suspect CVS Blame could tell me).

Yeah, and I foret why we had to bring it in. there was a reason, but I can't recall :)

My best guess is because checksetup.pl deals with params now, but that's all it is :)

CVS Blame... my friend :) Bug 126571 is where globals.pl was added to checksetup.pl by Myk.

I can no longer reproduce this on the tip. I was going to say it got fixed by the checkin for bug 124174, except that I couldn't reproduce it on landfill/bugzilla-tip prior that that checkin being picked up by it. My best guess is something in the checkin from bug 191863 must have fixed it. Anyhow, it's fixed. :)

*** Bug 198998 has been marked as a duplicate of this bug. ***

*** Bug 213129 has been marked as a duplicate of this bug. ***