Results 1 to 19 of 19

Thread: kayako error...

  1. #1
    Join Date
    Jul 2005
    Location
    Toronto, Ontario
    Posts
    260

    kayako error...

    We are getting the following in my apache logs when we are trying to reply to tickets..


    [Thu Aug 31 14:54:34 2006] [notice] child pid 42079 exit signal Segmentation fault (11)

    Anyone had this problem before with Kayako?
    Alex Maleki -/- 1.866.596.8401
    iTeraWeb Solutions -\- Quality cPanel, Unlimited Reseller, and A-Z VoIP Termination.
    http://www.iteraweb.com | 24x7x365 Phone/Chat Support

  2. #2
    Join Date
    Sep 2006
    Location
    Gothenburg, Sweden
    Posts
    32
    Perhaps asking for help at Kayakos site would be more rewarding?

    I'm sorry to say I haven't experienced the problem before.
    - Erik Bernskiold
    Web Designer, Photographer, Software Trainer & Owner of XLD Studios
    Bernskiold Media (Blog, Tutorials) | XLD Studios

  3. #3
    Join Date
    Oct 2002
    Location
    State of Disbelief
    Posts
    22,952
    From Kayako's forum: http://forums.kayako.com/showthread.php?t=2586
    Same error, with solution.

  4. #4
    Join Date
    Jul 2005
    Location
    Toronto, Ontario
    Posts
    260
    This is the ioncube version...
    Alex Maleki -/- 1.866.596.8401
    iTeraWeb Solutions -\- Quality cPanel, Unlimited Reseller, and A-Z VoIP Termination.
    http://www.iteraweb.com | 24x7x365 Phone/Chat Support

  5. #5
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    This is unlikely to be related to the Loader as replying to tickets is obviously a core feature of Kayako and we have no reports of such problems, but do check that you have the latest Loaders from us. If the Loader is in the php.ini file then you'll see the version displayed on a phpinfo page in the box near the top that mentions the PHP engine, or if you use runtime install with Loaders in the ioncube folder, update to the latest ones there from our Loaders page. If you have a dedicated server, a php.ini install is best btw. as it avoids the overhead of linking and unlinking the shared library on each request. Also if you have Zend Optimiser installed but don't need it for running any non ionCube encoded files, removing ZO is likely to increase system performance and may also improve stability. The current Loader version at the time of writing is 3.1.22. If you need to query anything with us, feel free to post a ticket in our helpdesk.

    ionCube

  6. #6
    Join Date
    Jul 2005
    Location
    Toronto, Ontario
    Posts
    260
    We recompiled the zend version of the software and it seems to be working fine...
    Alex Maleki -/- 1.866.596.8401
    iTeraWeb Solutions -\- Quality cPanel, Unlimited Reseller, and A-Z VoIP Termination.
    http://www.iteraweb.com | 24x7x365 Phone/Chat Support

  7. #7
    Join Date
    Aug 2002
    Location
    Canada
    Posts
    665
    removing ZO is likely to increase system performance and may also improve stability.
    ZO has never in our many years of experience with it, diminished a server's performance - don't buy into that one. Zend Encoded scripts + Zend Optimizer is a great combination, combined with Zend Platform the gains can be astonishing.

    I digress, concerning your issue, if the issue persists hmalekib, try the following:

    1. shut down your apache server entirely

    2. run httpd -X under gdb with the following commands, where /usr/sbin/httpd might vary on your server:
    gdb /usr/sbin/httpd
    (gdb) run -X
    3. use your web browser and access the script which causes the segfault, and reproduce the actual segfault.

    [ you will see a gdb prompt appear and some message indicating that there was a crash]

    4. At the prompt, issue the bt command (for backtrace)
    (gdb) bt
    This should generate a backtrace which will look something like this:

    (gdb) bt
    #0 0x080ca21b in _efree (ptr=0xbfffdb9b) at zend_alloc.c:240
    #1 0x080d691a in _zval_dtor (zvalue=0x8186b94) at zend_variables.c:44
    #2 0x080cfab3 in _zval_ptr_dtor (zval_ptr=0xbfffdbfc) at zend_execute_API.c:274
    #3 0x080f1cc4 in execute (op_array=0x816c670) at ./zend_execute.c:1605
    #4 0x080f1e06 in execute (op_array=0x816c530) at ./zend_execute.c:1638
    #5 0x080f1e06 in execute (op_array=0x816c278) at ./zend_execute.c:1638
    #6 0x080f1e06 in execute (op_array=0x8166eec) at ./zend_execute.c:1638
    #7 0x080d7b93 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
    #8 0x0805ea75 in php_execute_script (primary_file=0xbffff650) at main.c:1310
    #9 0x0805cdb3 in main (argc=2, argv=0xbffff6fc) at cgi_main.c:753
    #10 0x400c91be in __libc_start_main (main=0x805c580 , argc=2, ubp_av=0xbffff6fc,
    init=0x805b080 <_init>, fini=0x80f67b4 <_fini>, rtld_fini=0x4000ddd0 <_dl_fini>,
    stack_end=0xbffff6ec) at ../sysdeps/generic/libc-start.c:129
    (gdb) frame 3
    #3 0x080f1cc4 in execute (op_array=0x816c670) at ./zend_execute.c:1605
    (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
    $14 = 0x80fa6fa "pg_result_error"
    (gdb) print (char *)executor_globals.active_op_array->function_name
    $15 = 0x816cfc4 "result_error"
    (gdb) print (char *)executor_globals.active_op_array->filename
    $16 = 0x816afbc "/home/yohgaki/cvs/php/DEV/segfault.php"
    (gdb)
    5. Copy and paste this backtrace and submit it alongside your bug report.

    Locating the problematic function

    If you examine this backtrace, you'll see that the last frame which calls 'execute' is frame #3 (read in a bottom-up manner).

    6. Issue the 'frame 3' command. This will tell the core parser to set itself at the third frame.

    7. Type out the following command (careful of syntax) which will identify the problematic function:
    print (char*)(executor_globals.function_state_ptr->function)->common.function_name
    [the function name will be displayed]

    Glad you wrote it was resolved of course, but these steps might help you if the issue surfaces anew. You'll be able to tell at least which Kayako component is causing the problem, and submit to their staff a useful bug report.

    Good luck!
    Alex
    Last edited by Saeven; 09-12-2006 at 01:50 AM.
    circlical - hosting software development
    forums * blog

  8. #8
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    ZO has never in our many years of experience with it, diminished a server's performance - don't buy into that one.
    Have you ever measured and tested this? I'll expect you to say yes, but most people haven't because there is the assumption that there will be an overall speedup. The upshot is that there can be surprises to challenge conventional wisdom when one does benchmark, and IIRC, there was either a sitepoint or WHT thread a few months back about this precise issue and carrying some peoples' observations.

    combined with Zend Platform the gains can be astonishing.
    Of course, although this is substantially due to caching precompiled code.

    Certainly one can concoct examples that will make optimisation seem very impressive, but often these are not real world examples. The optimisations themselves are fine, and the reason for any slowdown is simply that the time taken to optimise can be greater than the resultant speedup. For at least a dedicated server running known scripts, and where an optimiser (as opposed to a code cache) is an option and not mandatory, spending half an hour running a few tests and averaging the results to see whether there is a difference doesn't hurt, and is better than blind faith.

    Another area where it can pay to investigate is with MySQL queries, as trusting that the query optimiser will use the most optimal join order is again a leap of faith that can cost dearly. In the past, and whilst not faulting the reason behind the choice of a join order, forcing a particular ordering yielded an order of magnitude speedup on some slow queries, and gave a long term benefit for the few minutes that it took to experiment.

  9. #9
    Join Date
    Aug 2002
    Location
    Canada
    Posts
    665
    Have you ever measured and tested this? I'll expect you to say yes,
    Indeed the answer is yes. We did this thoroughly when we had to make a choice between IonCube Encoder, for which we own a license, and Zend Encoder where our offerings are concerned. The difference between the two wasn't phenomenal, with Zend having a very small advantage in most our test cases, IonCube had a small advantage on static grinds. The IonCube encoder then was a command line job only though, and defining exclusion was a pita. Customers also relied on the runtime loader which of course is akin to running in molasses, and would oft complain. We dropped IC entirely and moved ahead with Zend. Zend Platform does much more than cache precompiled code though, have you seen its PHP Intelligence of mySQL query monitor?

    Another area where it can pay to investigate is with MySQL queries, as trusting that the query optimiser will use the most optimal join order is again a leap of faith that can cost dearly. In the past, and whilst not faulting the reason behind the choice of a join order, forcing a particular ordering yielded an order of magnitude speedup on some slow queries, and gave a long term benefit for the few minutes that it took to experiment.
    However true that optimizing mySQL is great, that's a bit off topic no? Anyone who's taken any kind of university computer science degree, or that has bothered to read their SQL server's manual knows this. http://dev.mysql.com/doc/refman/5.0/...imization.html is your best friend if MySQL is your flavor of choice...
    circlical - hosting software development
    forums * blog

  10. #10
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    Customers also relied on the runtime loader which of course is akin to running in molasses
    Anyone who's taken any kind of university computer science degree would know that runtime install would incur an overhead That said, program execution time is essentially the same whether one uses runtime or php.ini install, but dl() naturally adds an overhead from the OS linking the shared library on the first encoded file and unlinking it at the end of the request, and that can take a few 10's of milliseconds. In real terms, dl() overhead is negligible and typically imperceptible unless perhaps if you're on a pokey and/or overloaded shared server although not necessarily even then. There's always the option of a php.ini install if it's an issue, and dedicated server users would naturally go for a php.ini install unless wrongly advised.

    With encoded files a speedup with ZO would not be uncommon because the optimisation takes place at encoding time and not runtime, and the Olate benchmarks reflect this. Where slowdown can be evident is with unencoded files, and where parsing and compilation still takes place plus the overhead of non-trivial optimisations and code reorganisation.

    The disabling ZEND optimizer decreases load thread was one persons observation, but there may have been other reasons in their case. Speedup is certainly not a given though.
    Last edited by phpa; 09-12-2006 at 01:29 PM.

  11. #11
    Join Date
    Aug 2002
    Location
    Canada
    Posts
    665
    Anyone who's taken any kind of university computer science degree would know that runtime install would incur an overhead
    This wasn't disputed, I'd simply written that when clients are given an easy out with things like this, they usually take it instead of bothering their hosts to modify their php.ini. This inevitably becomes a source of complaints. It's best to force the optimal solution before the purchase point in the end, that way there are no hard feelings if requirements are not met, and where when they are, the potential for such complaints is circumvented.

    The disabling ZEND optimizer decreases load thread was one persons observation
    The optimizer is only instantiated when the encoder-header is present in the php files. When it is present, it serves to actually decrease load, bypassing the interpretation step which can be taxing. It's a moot point really, even if an administrator user chooses not to buy into the unfortunately expensive Zend Accelerator, there are many great (Free) bytecode caches out there that complement Zend Optimizer well (eAccelerator, APC, etc) to suit the very purpose that most 'biased' papers used to contest Zend Optimizer's benefits. Bytecode injectors are not caches, yes they do require CPU usage, but decrease CPU time in the end. Where speed of execution (or lack thereof) is more costly than execution requirement with the ever-decreasing price of strong processors, this is a very fair tradeoff.

    I'll desist here, since I feel that this thread has taken a turn of topic, but I really dislike when such misinformation about sound components is spread. Zend Optimizer is a great tool, written by the company that develops the language it protects/enhances itself. One has to believe, in addition to the many benchmarks available online, that they have some proprietary tricks up their sleeve to ensure that Zend Optimizer (their product) stands apart from its competition.

    I applaud IonCube for its work of course, it must not have been easy fighting a product war with a system's parent company. Nonetheless, those well-earned laurels aren't justification to spread falsifications about ZO.

    Cheers.
    Alexandre
    circlical - hosting software development
    forums * blog

  12. #12
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    We didn't start the offtopic discussion but did continue it so apologies to the original poster for that. This wasn't the intention, although it can be interesting to hear alternative views and perspectives so it's been interesting for that but will leave it after this.

    Quote Originally Posted by Saeven
    This wasn't disputed, I'd simply written that when clients are given an easy out with things like this, they usually take it instead of bothering their hosts to modify their php.ini. This inevitably becomes a source of complaints. It's best to force the optimal solution before the purchase point in the end.
    I can't honestly recall anyone raising this as an issue with us, and what you consider to be "optimal" for you may not be for someone else. What may also have been missed is that runtime install is not only optional for the end user but there's an Encoder option not to add runtime support to encoded files in the first place. So if a provider really wants to force their customers to go the php.ini route and believes this to be best then they can do it. Using binary encoding instead of ASCII is also marginally more "optimal", but there's a serious downside for many to make ASCII encoding, which is also optional, the far better choice. Something that suits one person may not suit another, and was essentially my original point.

    Our approach to product design is not to be restrictive, but to address the issues that exist within the end user base that we note from our own experience and taking the time to find out and listen to customers, such as the need for ASCII encoded files and runtime install. If appropriate, we then make these optional so that product users have the choice to make the most appropriate usage of the product for their situation rather than forcing them one way when valid alternatives exist.

    I applaud IonCube for its work of course, it must not have been easy fighting a product war with a system's parent company. Nonetheless, those well-earned laurels aren't justification to spread falsifications about ZO.
    Thanks for the hand-clap, although I'm not sure what "war" you refer to. I think that it's called healthy competition, and it's been rather easier than you might imagine for not just us to be successful but others as well. We recognise the Zend contribution on PHP, and when PHPA was released (before ionCube was created), were happy to make a personal promise to Zeev not to release the source code after he wrote personally to express his concern for Zend after seeing a free product hit the market that matched or exceeded the performance of Zend Cache as it was called at the time. Despite some documented and disappointingly less than honourable and dishonest actions by Zend since, we've honoured that promise to this day. That PHPA did emerge was undoubtedly good for PHP though as it showed that PHP, which was much criticised at the time for lacklustre performance, was a viable alternative to other technologies such as ASP when combined with a tool such as PHPA. Companies such as Yahoo! then adopting PHP with PHPA helped to propel PHP further forward at a quick pace. The launch of the Encoder and online service in 2002 then made encoding available to everyone and not just those with a few thousand to spend. For the first time, anyone could develop serious PHP applications and take the chance of doing so on a full time basis knowing that they could secure the revenue necessary to make a living and create a going concern. So we've been instrumental in contributing to the progress of PHP at some key stages, and it's been great to see the language become more mainstream over that period.

    As for ZO, your own personal experience, whilst as equally valid as our own, doesn't change the fact that we've observed a slowdown in the past when running benchmarks and when we've tried it on websites with unencoded files, and that others have measured this too. Just like spending money upfront on advertising is a gamgle, if you add overhead upfront with on the fly optimisation in the hope of getting a speedup down the line then it's a toss up as to whether you will as it depends very much on the structure and runtime nature of the PHP application. So my point is simply that the often made assumption that a component must make things faster because it's called an optimiser is invalid, and that if one has the chance then seeing whether there is a benefit or not doesn't hurt. A large part of our work is in code optimisation, and so we're used to not accepting intuition and what we think will make things faster, but to actually test and make a quantitative analysis to find out. Many people do not do this. Sorry if you misunderstood the intentions.
    Last edited by phpa; 09-13-2006 at 06:29 AM.
    Real-time intrusion protection and error reporting for PHP sites ioncube24.com
    Software protection for website owners and PHP developers ionCube PHP Encoder

  13. #13
    Join Date
    Sep 2004
    Posts
    1,904
    Wow - is the Auracle Support and Kayako going head to head? Hang on - I have to get something..........






    Okay - I'm ready now. Continue.


  14. #14
    Join Date
    Oct 2002
    Location
    State of Disbelief
    Posts
    22,952
    Actually it seems to be a ZEND vs IONCUBE debate....

  15. #15
    Join Date
    Sep 2004
    Posts
    1,904
    Ahhh - looks lik IONCUBE with Auracle Support. This is what I like to see so early in the morning. Let's play BALL!


  16. #16
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    Hehe, it was never zend vs. ionCube, just Alex getting upset to hear that ZO does not always make things faster [sorry Alex, honest ] We only chipped in early to offer help to someone as we like to offer free support to our indirect customers as well as the direct ones. Ho hum. Best intentions and all that...
    Last edited by phpa; 09-13-2006 at 08:51 AM.

  17. #17
    Join Date
    Aug 2002
    Location
    Canada
    Posts
    665
    and what you consider to be "optimal" for you may not be for someone else.
    Optimal is clear in this case - it is the optimization of a webserver's ability to serve a page in the least amount of time.

    untime install is not only optional for the end user but there's an Encoder option not to add runtime support to encoded files in the first place.
    This was a good move! When we used IonCube, it was just a shell type of job with very little documentation. I know that you have a nice GUI now which likely makes the options more intuitive. This isn't a point I would debate.

    That PHPA did emerge was undoubtedly good for PHP though as it showed that PHP, which was much criticised at the time for lacklustre performance, was a viable alternative to other technologies such as ASP when combined with a tool such as PHPA.
    That's a whole other ballgame. which becomes a bit of a religious debate. My company heads engineers and senior architects which get called in to head corporate projects; customers very rarely ask for PHP or LAMP setups. LAMP is in a bit of a state of disarray right now, I think there was an interesting article about this in this month's Dr. Dobbs titled just the same: "LAMP's state of disrray". I'm at home right now, but I can find the right volume and edition when I get to the office. I'd personally largely attribute this to Zend's maintenance of old versions, whilst unsuccessfully pushing a newer version (adoption of PHP5 isn't as quick as they had intended), whilst actively developing a SVN branch that has an incremented major index (PHP6)! Sorry for the vent; reality is that Struts + JSP, and .NET are what larger-scale developments request these days. The first statement that a customer usually exclaims is "You must be able to do this in ____", which scarcely includes PHP or invokes showdowns between encoders and accelerators. Back to topic however..

    As for ZO, your own personal experience, whilst as equally valid as our own, doesn't change the fact that we've observed a slowdown in the past when running benchmarks and when we've tried it on websites with unencoded files
    I'd appreciate that personal experience not be invoked. My intention wasn't to dispute that your offering is valid, but to add a grain of salt to something that seems a bit miscontrued (the original sentence of debate).

    So my point is simply that the often made assumption that a component must make things faster because it's called an optimiser is invalid
    Agreed, that's where one generates benchmarks to support such claims. My qualm wasn't with such sound reasoning, it was again, with the sentence that follows:

    Also if you have Zend Optimiser installed but don't need it for running any non ionCube encoded files, removing ZO is likely to increase system performance and may also improve stability.
    http://www.zend.com/products/zend_op...ral_faq#root_6 seems to say otherwise. As devil's advocate then, someone reading this thread could choose to believe Zend's claim that optimization will be the ineffable result (their product), or yours (a competitor) which claims otherwise. If this internal debate occurs then I have achieved what I believed would be best - a weighted decision....

    it was never zend vs. ionCube, just Alex getting upset to hear that ZO does not always make things faster
    ...which is all I had intended. At no point was I upset Also, at no point did I discredit your system's boon to its community, I just couldn't idly read that sentence without interjecting. Perhaps of no consequence, this thread's original poster solved the problem by switching to the Zend encoded version of the software, this would seem to contradict the attack on Zend's stability? Perhaps an isolated case.

    When our developments slow down, I'll gladly give IC + IC Accelerator and Zend Optimizer + Zend Platform another shootout, and PDF the results for the masses this time! Til that day I suppose, I would gracefully desist herein.

    Kind regards.
    Alexandre
    Last edited by Saeven; 09-13-2006 at 11:59 AM.
    circlical - hosting software development
    forums * blog

  18. #18
    Join Date
    Mar 2002
    Location
    London & Kent, UK
    Posts
    372
    Others have taken the time to perform tests.

    Stefan Rubner reached this conclusion earlier in the year:

    Conclusion

    As far as I can tell right now, the best option you have is to stay away from Zend Optimizer at all cost.
    You can read his full article here

    Someone elses benchmarks report a test with 10.67 request per second with no tool and 7.92 with Zend Optimiser, see here. I believe the results are old now as they mention PHPA, but I don't think that these were our own tests reported on DWP.

    So we don't make these claims up. Whether anyone uses ZO makes no difference to us (or Zend for that matter as it's free) as we don't compete with it, and the point really is just that in isolation it won't necessarily make your system faster and could slow it down. This should be obvious so I'm rather befuddled by all the fuss about mentioning it. If we had an optimiser product, then being honest Brits, we would give the same advice ourselves if it wasn't a sure thing on the performance front. If you use Zend Platform then you will definitely get an excellent boost, and it's not disputed that ZO should enhance performance further in that scenario.
    Last edited by phpa; 09-13-2006 at 01:22 PM.

  19. #19
    Join Date
    Aug 2002
    Location
    Canada
    Posts
    665
    Our last test was performed using Genetic Programming however, which is something that I've not seen in any public benchmarks that definitely is more taxing than any boring and repetitive loop or array sorting. Unfortunately in the links you post, the code used, and the processor and filesystem info are not given. This somewhat nullifies the value of those benchmarks entirely.

    Given our most appreciated conversation however, I do look forward to the exercise again, and will certainly bookmark this thread til such results are produced. I of course, wish you all fruition possible with your efforts, we're on the same team in the end - you a producer, and myself a consumer of such products.

    As aside, I've not had the pleasure of your learning name as you sign only ionCube. Should we meet in the future, I'd gladly shake your hand.

    Cheers.
    Alex
    circlical - hosting software development
    forums * blog

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •