I'm issuing a serious problem using php-fpm and pcntl_fork.
Both are working pretty well, but when they are together, I "loose" standard output for web browser. This mean the fork works, but the standard output (client browser) is totally lost for everybody (all children and the parent).
Outside fpm (in command line for example) the fork works as expected (all children print to terminal output).
Does someone gone something working or it's general problem with php-fpm ?
Ok I finally found the good way...
The code I use (which can be found at many place) use exit(0) function on child process to terminate it. But on php-fpm this also kill the main process... That's why it was not outputing after first child call...
Here is solution (found on pcntl_fork user comment):
register_shutdown_function(create_function(
'$pars', 'ob_end_clean(); posix_kill(getmypid(), SIGKILL);'
), array());
This will kill as expected any zombie at the end of script without killing main process
Related
I stumbled upon an issue when I recently switched to VSCode as editor.
I have several projects that have a full (medium-complex+) autotool
setup and they all work fine. However I discovered that the makefile plugin for VSCode in order to initialize itself (and finding all dependencies and targets) starts by running
make --dry-run --always-make
as first time initialization. This throws the makefile (or actually the
re-config) into an endless loop re-running "configure" (since the targets are never resolved to disk).
I have also confirmed this behavior with the smallest possible autoconf/automake
setup. I can also kind-of understand why this happens (and it seems make
have an internal way to discover this exact situation with the special
variable MAKE_RESTARTS that could possible be used to detect a cyclic
behavior)
Is there a known best-practice workaround ? or is it even a reasonable expectations that these two options in combination should work? (Good to have a second opinion before I go down the rabbit-hole of reminding myself of all the details I forgot about the magical land of autotools)?
We are using Progress OpenEdge 10.2A for years and for the last 4 months we begin to receive unknown error messages from our customers.
We call our .w files using lines as follows:
RUN VALUE(myPath + "myProgram.r") PERSISTENT SET myPrograms[i].
Normally the same program calls work without any problem, but on rare occasions, the program window seems to get unresponsive, but in fact when we look at the windows taskbar, there is another entry in the taskbar which is a prowin32.exe window having title "Error". But when selected, there seems to have no visible window attached to it.
When we close it from the taskbar using Close Window option, it appears again in the taskbar 6-7 times again and then whole prowin32 session restarts.
We could not identify the error since it does not show any message or any error number.
If you encounter such a problem, I'd like to know how you solved it.
If not, it would be appreciated if you direct me to the way to solve the problem.
Edit 1:
After adding -errorstack -debugalert -clientlog myLogFile.log to my startup parameters, myLogFile.log is generated. The below part is written when the error occured.
**Unable to realise TEXT myText. (4025)
** ABL Debug-Alert Stack Trace **
--> enable_UI c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 21014
c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 14858
USER-INTERFACE-TRIGGER c:\myFolder\myFile2.r (c:\myFolder\myFile2.r) at line 2905
0) OpenEdge 10.2a is ancient, obsolete and unsupported. You should have moved to a modern release 10 years ago. At the very minimum you should be on 10.2b08. Do you also refuse to update Windows? OpenEdge 12 is the current release. It is possible, perhaps even likely, that unanticipated changes in Windows or other aspects of the environment are causing your problem. Progress is never going to update 10.2a to accommodate that sort of thing. You are just prolonging the agony by staying on an obsolete release.
1) What changed in your code or your environment 4 months ago?
2) You can get a stack trace for the extra prowin32 session by running proGetStack. That should help to explain what was launched, what the error is and why another 6-7 start after you kill it. Open a "proenv" window as "Administrator" and run proGetStack (you can get the process id from taskmgr).
proenv> proGetStack 123456
The stack trace will appear in the working directory of the target process. That is usually the same directory that proenv is in but it is possible that the application changes it so you might have to go hunting for it. (Administrator proenv windows sometimes do not start in %wrkdir%, you may also need to cd /d %wrkdir%)
3) If they are not already present you should add -debugalert and -errorstack to your client startup parameters. -clientlog logfileName.log would probably also be helpful.
4) Examine your code base for bits that invoke prowin32 sub-processes. There are many ways to do this such as OS-COMMAND, INPUT THROUGH or via Windows DLL calls. Directly invoking prowin32 can be found by searching for that string but it might also be indirect invocations via a BAT file or other technique.
5) if you have a repeatable way to produce the error then you could also add the 4GLTrace log entry type either at startup or in the code when you get to the proper point: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpspr/log-entry-types-(-logentrytypes).html
I use squish-4.2.2 for testing GUI of our tool and use purecov.i386_linux2.7.3 for covering them. Our tools are based on qt-4.7.4_qsci version of QT. After building our tools in Purecov mode, when we run our tests, they fail if tests contain operation with "popsup menu". Purecov cannot generate the result *.pcv file. Also I would like to note that our tools do not fail when they are run without Squish, however "Popsup Menu" opens not earlier than after 30-60 seconds (in normal mode it is done during 1-2 seconds).
So I have 2 issues:
1. when tests are run with Squish, they fail when tests contain operation with "Menu" item;
2. Purecov does not generate *.pcv file when tests fail.
I tried to find some interesting things on your site for resolving those problems, but I couldn't find anything related to my issues.
In my opinion, Squish failed because when I try to open "Menu" item, GUI runs faster than its logic part, and after opening "Menu" item, Squish considers that operation is done and kills my tool.
Could you please tell me what I can do with my tests or tools for resolving those problems?
Thanks.
I had a similar issue in the past, with clicking menus from my app.
I hope this helps you also!
Example:
I wanted to open a "File" menu, followed by a sub-menu (which is pop-up) "New". When I'm in record mode of Squish, Squish records the following code in python:
activateItem(waitForObjectItem(":MainWindowForm.m_poMainMenu_QMenuBar", "File"))
activateItem(waitForObjectItem(":MainWindowForm.menuFile_QMenu", "New..."))
Now, this didn't worked all the time, honestly I didn't managed to understand why :).
But, I found on their site, this a possible solution. So, I've replaced Symbolic names from the code above, and created a function that calls the objects after Real name properties:
def callMenu(menu_name, submenu_name):
activateItem(waitForObjectItem("{type='QMenuBar' visible='true'}", menu_name))
activateItem(waitForObjectItem("{type='QMenu' title='%s'}" % menu_name, submenu_name))
After I made this change, the tests run smooth, without anymore problems (at least from the menu side).
I've been using IAR embedded workbench for quite some time but there is still one thing I'm unable to wrap my head around. And that's the inconsistency of the breakpoint operation.
I have a quite big project which runs an RTOS (might this affect the problem?) and when I place a breakpoint there is no guarantee the debugger will stop at this breakpoint. Sometimes it does, sometimes it doesn't.
A workaround I found is manually stopping the processor and placing the breakpoint while the processor is paused. But even this has not a 100% success rate.
I'm generating debug information and I'm running in debug mode
Anyone had similar issues or anyone with some ideas?
Try to reduce number of breakpoints that you use (possibly just keep this one that causes problem), also you could use a “Log” breakpoint in order to print a message in the Debug Log window instead of stopping at that point (you may also want to try a different point in the same section of the code). If they don't help, I could say with a high degree of certainty that the debugger does not stop at the breakpoint because it simply does not hit it, and you do not enter that block of code. Consider that in an embedded project (especially when using an RTOS) some conditions are met only at the beginning or upon certain requests in certain conditions so you might want to figure out when the breakpoint is actually hit what conditions were met and what is the new state now.
See code below, for some reason it only works when I put a breakpoint on line 2 (*) is there some delay? Is it starting the next line before it finishes the 2nd one?
dp.SSLCertStoreType = nsoftware.IBizPayPal.DirectpaymentSSLCertStoreTypes.sstPEMKey
*dp.SSLCertStore = My.Computer.FileSystem.ReadAllText(Server.MapPath("\cert_key_pem.txt"))
dp.SSLCertSubject = "*"
Note: The error is thrown on the 3rd line only when the breakpoint is set on the 2nd line, after releasing the break the program executes my paypal purchase via credit card.
I will post the error again I am replicating it now...
System error: Could not acquire security credentials: error 8009030E.
There it is, while it should say "Order Confirmed!" type message if working correctly.
Almost certainly a threading issue, but nobody is going to be able to answer definitively unless they're familiar with nsoftware.IBizPayPal
Sometimes you can find that breaking can mutate an object's state, due to the locals window evaluating object properties. If they have a side-effect, then all bets are off, unfortunately :( No idea whether this is happening in your case.
I have no knowledge of ASP, so just wondering aloud: Could this be due to multithreading? You know when you put a break point you sort of freeze execution of all threads, but not so in the real execution.