Yep, hope V2019 fixes things as I can’t release my app as it is.
Sure, you can zip them and send us the Zip by email (or send us a link for download).
I’ve upgraded to ExeOutput for PHP 2019 but looks like the problems still exist.
Also when compiling my app to use PHP 7.3 I get the message “No input file specified.”
I’ll email you a download link to my app.
I’ve PM’ed you a download link, hope that’s ok.
Answered to you by PM.
Just thought I’d better chime in here - I’ve also been getting the 233 System Error too - it’s been going on since v2018, haven’t had time to debug it yet but I figured it might be something at my end, for now I’ve just been sending errors to the log file and the app seems to run okay despite the error - would be good to find a fix though, when I get time I’ll investigate further, really not sure if it’s ExeOut or an issue with my code…
This is an example of what it looks like in the log:
15/01/2019 04:56:28 Scheme Request URL start: http://heserver/getUDstats.php?_=1547528188082
15/01/2019 04:56:29 PHP ERROR: System Error. Code: 233.
No process is on the other end of the pipe
**15/01/2019 04:56:29 PHP ERROR: **
15/01/2019 04:56:30 Scheme Request URL start: http://heserver/getUDstats.php?_=1547528190386
The getUDstats script is being polled once every second - and the error shows up in the log every 5 mins or so.
Next step is to see if it correlates with anything in the cef debug log, I’m pretty sure it did when I was looking into it a while back. I’ll update if I can figure it out… Which reminds me of a feature request I was gonna post…
https://www.gdgsoft.info/t/feature-request-would-be-good-to-have-millisecond-timing-in-main-debug-log/3949
That generally means one of the PHP process has crashed and the main EXE loses the connection.
How do you trigger the script? Do you use the CRON job timer feature?
No, not using the CRON job feature. Just AJAX with timers and in some cases I call a script that terminates itself when certain conditions are met. For those I call them via Ajax, set ignore_user_abort to TRUE and set_time_limit to 0, and have the script periodically check certain files, then when certain conditions are met, the script exits - I generate a custom debug file that I write to to monitor those scripts, and everything seems to be okay there.
So, if a php process is crashes with a 233 error - what happens, does it attempt to restart another one? - providing the errors are sent to the log, I’m not noticing any problems with the apps functionality when the error occurs - just the error itself.
Simple PHP page with a menu and now with V2019 constantly getting 23 error:
Not sure what is going on but hope @gdgsupport get us a new version very soon:) So bad for me, having to crank up old VS projects and use them instead of exeout…Hard to explain to a client that a “fix” will be out soon but have no idea when…
Have you checked whether there was no remaining process related to your EXE in task manager? And is your antivirus still running in the background?
It would be better to use the new CRON timer, because it is designed to start a different PHP process to run your PHP script regularly. This will avoid possible multithreading problems.
It depends. If the PHP process crashes, the error is shown as you can see. Then, if there is a new request, a new PHP process is started.
Okay, I’ve not experimented with the new CRON timer, but that may well be the answer!
Think may have tracked down what is causing 233 error in my instance above.
Use this script to refresh an iframe which contains dynamic information from online server:
setTimeout(function(){
location.reload();
},45000);
There is also curl involved on the external page being refreshed. Seems the 233 error (no process is on the other end of pipe) is happening if the software is left open on users computer over night (or extended absents).
Will try the built-in cron instead of the script. Any tips on how to use in place of my refresh script example above appreciated.
Thank you very much for that info. That could explain the 233 error. Sure, CRON job would be better. You can assign a JavaScript call for instance that will reload the page. See here:
https://www.exeoutput.com/help/timer-cron-jobs-ui
1 Like
Regarding the 233 Error - I’ve figured out what’s going on to some extent.
As mentioned in previous post above, it occurs for me occasionally (every 5 mins or so) when doing an Ajax call that runs once a second, like this:
03/02/2019 13:47:26 Scheme Request URL start: http://heserver/getUDstats.php?_=1549201646034
03/02/2019 13:47:26 PHP ERROR: System Error. Code: 233.
No process is on the other end of the pipe
03/02/2019 13:47:26 PHP ERROR:
03/02/2019 13:47:27 Scheme Request URL start: http://heserver/getUDstats.php?_=1549201647549
I found that the 233 No process error coincides with a failed Ajax call to the getUDstats.php script that would normally return json to main script:
From the cefdebug log:
[0203/134726.545:INFO:CONSOLE(14642)] “Ajax statsUpdate error: error (ERROR)”, source: http://heserver/CAn.php?projectCode=1489549538&projectName=Adrian&KWnoScroll=1&freshOpen=1 (14642)
It seems that occasionlly (every five minutes or so) ExeOutput acts as if the getUDstats.php script doesn’t exist and throws an ExeOutput Viewer error (looks like a 500 server error), which in turn causes the Ajax call to fail. (as it’s a background script, I don’t get to see the ExeOut error page in the app, and I send the ajax error to the console and restart the scrip on errors anyway, so it currently doesn’t affect operation of the app, but for production I’d need to find a solution.)
This is what it looks like when the error occurs in devTools:
Error Thrown:
Headers tab:
Timing Tab:
Regarding the CRON feature, I’ve had a look, but not entirely sure how to implement it or it if would be be able to work in the way I’d need - would be good to have a bit of a deeper explination of how it could replace ajax - I’ve barely used any hescript yet, so it’s all a bit new to me…
The 500 error is the consequence of the 233 Error. Since the PHP cgi process crashed, it could not return a valid HTTP answer, hence the 500 error.
For your CRON job, you could just configure the timer to execute your PHP script as explained here:
https://www.exeoutput.com/help/timer-cron-jobs-ui
for instance, call the getUDstats.php script.
So are you any closer to understanding what causes the PHP cgi process to crash, is it just a consequence of EO not coping too well with multithreading or Ajax?
- in my case if it were possible to just disable the 233 error popup everything would be fine as it doesn’t cause any issues with the functioniality of my app - as soon as it causes the Ajax error I just restart the function that calls the script like so:
error: function (jqXHR, exception) {
var msg = '';
if (jqXHR.status === 0) {msg = 'Not connect.\n Verify Network.';
} else if (jqXHR.status == 404) {
msg = 'Requested page not found. [404]';
} else if (jqXHR.status == 500) {
msg = 'Internal Server Error [500].';
} else if (exception === 'parsererror') {
msg = 'Requested JSON parse failed.';
} else if (exception === 'timeout') {
msg = 'Time out error.';
} else if (exception === 'abort') {
msg = 'Ajax request aborted.';
} else {
msg = 'Uncaught Error.\n' + jqXHR.responseText;
}
console.log("Ajax statsUpdate error: (" + msg + ")");
statsUpdate(stats);
}
statsUpdate is the function that performs the Ajax call - so it effectively just calls itself again on error.
The thing is, I’m thinking the CRON timer might not be able to do what I need, or require considerable alterations to a lot of code… as it’s not just a case of calling the getUDstats script, I also send various variables and data to it at different times too, like getUDstats.php?blaaa=2&x=3 etc…
The script itself only runs for a fraction of a second each time, all it does is access a few files (that are written to via another background script) and returns some data in json format.
Might it make a difference if I replace the jquery $.ajax calls with vanilla javascript?
No. Now that we know more about what you are trying to do, we’re trying to reproduce the problem too.
1 Like