Closed GoogleCodeExporter closed 8 years ago
I ran examples/AddCampaign.php on Ubuntu using everyone one of those versions
and I
wasn't able to replicate the segmentation fault. Are you building the PHP
installations from source, and if so what configuration options are you using?
Are
you setting any SOAP or HTTP configurations in your php.ini file? Do you have
a core
file from the fault, and have you tried running a backtrace on it?
http://bugs.php.net/bugs-generating-backtrace.php
Original comment by api.ekol...@gmail.com
on 8 Apr 2010 at 3:47
Original comment by api.ekol...@gmail.com
on 8 Apr 2010 at 4:06
First off, ekoleda, thank you very much for your response. I realize I didn't
give
enough info and should have posted a backtrace. I was just a bit at my wit's
end.
Now get this. I started running my scripts this morning and all of a sudden
there is
no Segmentation Fault!
I have no idea what happened since yesterday as I have been working on this
problem
for over a week now. I can't tell you how many times I have installed packages,
built
deb files, built php from source all with the same problem.
Did anything change on Google's end, and if it did can you make sure to keep it
that
way? ;)
Original comment by goo...@envoymediagroup.com
on 8 Apr 2010 at 5:48
As far as I know nothing has changed on Google's end, but I'll look into it.
I'll
close this issue for now, but feel free to open it again if the problem returns.
Original comment by api.ekol...@gmail.com
on 8 Apr 2010 at 6:58
Ok I figured out how to seg fault it. I was attempting to set a new campaign to
the
ConversionOptimizer bidding strategy with a messed up Pricing Model.
This is the way that I was setting the biddingStrategy object:
$object->biddingStrategy = new ConversionOptimizer(new
PricingModel('CONVERSIONS'));
which seemed right because the API docs say that it is an enumeration but of
type
PricingModel. However, I am quickly finding out that in the case of
enumerations, the
soap server wants to see the string, so I am now setting it like this:
$object->biddingStrategy = new ConversionOptimizer('CONVERSIONS');
Ok, now there is no more segmentation fault, woot! The only issue I have now is
that
I keep getting this error when I try to SET biddingStrategy on a campaign:
[faultstring] => Call to undefined method stdClass::getXsiTypeName()
For the sake of completeness, this is what the object looks like right as I
send it
to mutate:
CampaignOperation Object
(
[biddingTransition] =>
[operand] => stdClass Object
(
[id] => 48349935
[biddingStrategy] => ConversionOptimizer Object
(
[pricingModel] => CONVERSIONS
[BiddingStrategyType] =>
[_parameterMap:private] => Array
(
[BiddingStrategy.Type] => BiddingStrategyType
)
)
)
[operator] => SET
[OperationType] =>
[_parameterMap:private] => Array
(
[Operation.Type] => OperationType
)
)
Any ideas?
Original comment by goo...@envoymediagroup.com
on 8 Apr 2010 at 8:17
I just recently heard about the getXsiTypeName() error, which can occur if you
use a
non-WSDL-generated object in your request. I've created a fix for this issue,
which
has been pushed out to the trunk of this project. Please update your library
with the
trunk and let me know if that resolves your issue.
P.S. - Was the getXsiTypeName() error resulting in a segmentation fault?
Original comment by api.ekol...@gmail.com
on 8 Apr 2010 at 8:49
Thanks ekoleda,
That change to trunk fixed the getXsiTypeName() problem.
In terms of the segmentation fault I found it was when I was setting this
(effectively):
$object->biddingStrategy = new ConversionOptimizer(new PricingModel(''));
I had a variable instead of the blank quotes, but had mistyped the variable
name in
the code so I was attempting to send a PricingModel object (mistake #1) and then
specifying the type of that object to be blank (mistake #2). This apparently is
the
exact way to recreate the segmentation fault.
Original comment by goo...@envoymediagroup.com
on 8 Apr 2010 at 9:16
Original issue reported on code.google.com by
goo...@envoymediagroup.com
on 7 Apr 2010 at 11:45