[ic] one store gone nuts - 500 errors - (still) HELP please!

Greg Hanson greg at perusion.com
Fri Sep 7 16:52:02 EDT 2007


Ron Phipps wrote:
> Glenn McCalley wrote:
>>
>> ----- Original Message ----- From: "Peter" <peter at pajamian.dhs.org>
>> To: <interchange-users at icdevgroup.org>
>> Sent: Tuesday, September 04, 2007 9:01 PM
>> Subject: Re: [ic] one store gone nuts - 500 errors - HELP!
>>
>>
>>> On 09/04/2007 05:39 PM, Glenn McCalley wrote:
>>>>
>>>> ----- Original Message ----- From: "Peter" <peter at pajamian.dhs.org>
>>>> To: <interchange-users at icdevgroup.org>
>>>> Sent: Tuesday, September 04, 2007 7:41 PM
>>>> Subject: Re: [ic] one store gone nuts - 500 errors - HELP!
>>>>
>>>>
>>>>> On 09/04/2007 04:27 PM, Glenn McCalley wrote:
>>>>>> ----- Original Message ----- From: "Peter" <peter at pajamian.dhs.org>
>>>>>> To: <interchange-users at icdevgroup.org>
>>>>>> Sent: Tuesday, September 04, 2007 7:05 PM
>>>>>> Subject: Re: [ic] one store gone nuts - 500 errors - HELP!
>>>>>>
>>>>>>
>>>>>>> On 09/04/2007 02:22 PM, Glenn McCalley wrote:
>>>>>>>> Hi all.
>>>>>>>>
>>>>>>>> Store works fine until you press the final "Place Order" button
>>>>>>>> on the
>>>>>>>> checkout page.
>>>>>>>> 500 - Internal Server Error.
>>>>>>>
>>>>>>> The only time I have seen where the global error.log file
>>>>>>> doesn't show
>>>>>>> something is if Perl itself crashes, check for a core dump.>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>> Hi Peter, yes I do get perl.core dumps.  Sorry should have said that
>>>>>> before.
>>>>>>
>>>>>> - FreeBSD 5.3
>>>>>> - Perl 5.8.5 compiled myself, not the port.
>>>>>> - Interchange 5.2.0
>>>>>> - No Perl updates additions in some time.
>>>>>>
>>>>>> BUT -- the other stores are fine.  Hald a dozen of them.  Same IC.
>>>>>> Selling things, issuing receipts, making money.
>>>>>> That's what's got me swinging - this box has been rock solid for
>>>>>> over a
>>>>>> year and it's only -this-one-store-.
>>>>>> I'd think if it was Perl by itself they'd all be smoking ruins.
>>>>>
>>>>> If you're getting core dumps from Perl then that's definitely your
>>>>> problem.  They can be caused by the oddest combination of things
>>>>> and can
>>>>> easily happen on just one shop.
>>>>>
>>>>> Upgrade to the latest perl (5.8.8) and build a new
>>>>> Bundle::InterchangeKitchenSink, DBD::mysql (or whatever other
>>>>> database
>>>>> you have) and any other perl modules you might be using.  >>> Do
>>>>> that and your problems will almost certainly disappear.
>>>>>
>>>>> Peter
>>>>
>>>> Agreed, except how can it easily happen on just one store?  They
>>>> all use
>>>> the same Perl,
>>>
>>> Bugs like this are typically buffer overflow bugs that happen only in
>>> rare circumstances, so a particular combination of things could be
>>> triggering it (ie this internal function is called with that exact
>>> value
>>>
>>> Of course the other option is to leave perl and the bug in place, find
>>> the trigger in IC, and avoid triggering it.  If upgrading Perl doesn't
>>> fix the problem that may be your best solution.
>>>
>>>
>>> Peter
>>>
>> Still chasing this one.  (Sorry to disappear - 2,000 miles driving
>> past 2 days, family thing, real fun).
>>
>> Current situation:
>> - Perl upgraded to 5.8.8
>> - Bunldle::InterchangeKitchenSink rebuilt (takes a while, doesn't it?)
>> - I did find out where the icdebug file is logging, that does work
>> but doesn't show anything illuminating.
>> - ran expireallm thought maybe huge session lib or something
>> - Restart IC - other stores still OK, this one still crashes on
>> "Place Order".
>>
>> Verified that AuthNet process is completed OK, have the card
>> authorization - it happens after that but before receipts are processed.
>>
>> I agree it's Perl or Perl-triggered-by-IC.
>> The server error log still just shows "Premature end of script headers".
>> There is a message there that I can't see.
>> Is there a way or where in the IC code:
>> -- could I add CGI.pm's "fatalsToBrowser" or something like that to
>> get Apache to log whatever is being said by Perl as it dies?
>> -- where to start putting some additional debug log statements to tie
>> it down more specifically?
>>
>>
>
> You could try adding debug statements in log_transaction and
> etc/profiles.order at different points to see where the order process
> stops at.
>
>
Ron also asked earlier if you had disabled your payment gateway... ie
try using TestPayment to isolate that. I did not see if you answered
that. Sure sounds like it is specific to this catalog, and involves
something that could cause the core dump, and was only happening during
the order finalize process so it may be something to try.(also if you
got lucky and it is something to do with your payment gateway, you could
get the site running on TestPayment and gpg while you solve the problem)
The debugging of the log_transaction would probably show you that as
well if the payment portion is in fact the problem.

-- 
Greg Hanson
Interchange Consulting
Perusion
1506 E Gilbert Ave
Coeur d'Alene, ID 83815

Email		greg at perusion.com
Phone		208-667-2442
Toll Free	800-949-1889
Fax		775-256-2231
Web		http://www.perusion.com




More information about the interchange-users mailing list