I used to have the following configuration with Xdebug 2:
xdebug.default_enable=1
Xdebug did not slow down execution when no debug client was listening but when I needed to debug something then I only had to enable the listening in PhpStorm and refresh the page. No browser extension was needed for this. The same applied for debugging CLI applications, it just worked.
I tried to achieve the same with Xdebug 3 with the following configuration:
xdebug.mode=debug
xdebug.start_start_with_request=yes
It works the same BUT every time when I disable debug listening in PhpStorm and run a CLI command I get the following message with error severity:
Xdebug: [Step Debug] Could not connect to debugging client. Tried: 172.17.0.1:9003 (through xdebug.client_host/xdebug.client_port) :-(
This is something that I could live with but it also makes PHPUnit tests fails beStrictAboutOutputDuringTests="true" is enabled.
The upgrade guide suggest to use xdebug.module=develop if I used xdebug.default_enable=1 but that is not a valid replacement.
Completely silencing ALL Xdebug logs or even disabling error reporting in PHP suggested by this comment looks a dirty hack to me with possible drawbacks instead of a valid solution.
How can I keep the expected behavior without this message?
Xdebug 3 now warns when it is instructed (through xdebug.start_with_request=1 or with a COOKIE, or GET parameter) and it can not connect to your IDE. Previously a lot of people were having issue with getting Xdebug to work, and having this warning is really useful to them to point out that something is going wrong.
The correct way of not showing an error message is to not instruct Xdebug to make a connection to your IDE at all.
I recommend to use xdebug.start_with_request=trigger and then use either a browser extension as a trigger (https://xdebug.org/docs/step_debug#browser-extensions), or by exporting export XDEBUG_SESSION=yourname on the command line.
Setting xdebug.log_level=0 means you hide all warnings and errors, which makes it impossible to debug anything. Don't do that.
thanks for sharing your thoughts about this Derick.
Setting xdebug.log_level=0 means you hide all warnings and errors, which makes it impossible to debug anything. Don't do that.
I do not want to do this at all, but currently I do not see an another way around to keep the old behavior as I explained in the issue description.
Previously a lot of people were having issue with getting Xdebug to work, and having this warning is really useful to them to point out that something is going wrong.
I totally understand the motivation behind this new behavior and I also see it could be useful for many people. Although, the fact that this warning cannot be suppressed can cause problems to those who knows what they are doing.
Well, "what they are doing" is maybe an inappropriate phrase, what they want is probably better...
We had a workflow in our company with xDebug 2 that did not require any additional browser extension or environment variable (see above), just the listening to xDebug connection had to be enabled in the IDE and magic... It is a documented solutation and our Docker based developer stack made sure that xDebug worked OOTB for every developer. (Again, without any additional dependency)
Are you suggesting that this workflow is not supported anymore in xDebug 3?
Is there any chance to add a new configuration to xDebug 3 that would allow suppressing only these new warnings and enabling "expert mode"?
Related
Not sure what I did and I can't seem to see my RPC Services anymore. They are there and I can see them and get responses to their paths, but I can't see them through the Apigility/Admin screen.
The error is telling that either the config files are missing or may be even the code itself. When the code is missing normally you see "Unable to fetch code" or similar, so most probably you are missing config files.
It could also be a simple markup problem due to a strange char.
Since the Apigility GUI uses the Apigility API, you can use Firebug to check what is wrong.
Open Firefox and check the tab "Network". Now try to create a service and check the requests, you will probably find a dump with the Exception / Error that you are looking for.
I currently have a Plone 4.3.8 site where editing a portlet causes a deadlock.
I'm trying to find tools to fix this, but most deadlock tools don't work & I'm not getting good information (IMO) from those that at least run.
I've tried:
z3c.deadlockdebugger => can't get to a stacktrace
ZopeHealthWatcher => can't see the results on command line (or webpage)
Products.LongRequestLogger => perhaps the best so far, gives me some log output - but it's stack traces focus on Diazo code, but the problem still occurs when Diazo isn't in scope (running against 127.0.0.1)
gdb attach - just landed me in C code
winpdb => it can't attach to running processes in the same way that gdb can (only to processes started with the intention of attachment by winpdb)
Products.signalstack (OR Products.signalstacklogger) => USR1 signal just shuts down a zope process!
Note: z3c.deadlockdebugger (and things that depend on it) needs checked out source code to drop the threadframe dependency.
My situation seems to be linked to product upgrades - probably one or both of either plone.app.contenttypes or plone.app.multilingual, an empty site doesn't have this issue, but I obviously I need my site data!
What should I do to progress this?
EDIT:
I believe Maurits answer to be the most correct one, but it didn't work in my case. What I ended up doing was using pdb to track down the point at which the code was hanging (in plone.app.debugtoolbar as it happens)
You say that using the USR1 signal shuts down Zope when using Products.signalstack. But no special packages should be necessary, so I wonder if adding signalstack has this side effect of shutting down Zope.
At least for me, a few weeks ago, this worked fine on a Plone 4.3.something site:
kill -USR1 $(cat var/zeoclient.pid)
Although the #maurits answer is right (and the simplest ones) sometimes I had issues seeing the traceback resulting from the kill command: sometimes is found on the event log, sometimes on the shell.
I prefer the integration of the buildout with haufe.requestmonitoring, configuring also the monitor long running requests feature.
You will see the deadlocked traceback in your event log and also you activate a tool for monitoring low performance on your Plone.
I am using a third party module called Zlog for fast and more effective log printing. But now i keep getting the error message:worker process 50161 exited on singal 11(core dump). Then I used gdb backtrace, but it showed no problems. So does anyone know if Zlog is the cause of it? And if it is, is there a way to fix it? Or maybe recommend another good logging module thats supported by nginx.
Thank you
I have a custom http proxy that one worked. I have made some changes to its authentication process. And now when I try to launch an applet I get "Incompatible magic value 1012089682 in class file ...". Regular html files are transferred without any errors.
In my other web research I found this article http://arstechnica.com/civis/viewtopic.php?t=313827 discussing an ascii vs binary transfer issue.
My problem with debugging this is that the get of the jar file doesn't show up in tamper data on the browser nor in the access log of the webserver containing the proxy, nor in my proxy error log. So I am some what baffled. any help in how to get more information to solve this would be appreciated.
The technology is antique, but the company doesn't want to pay for upgrades. The proxy is an NSAPI plugin running in IWS 6 (SunOne webserver)
Thank you.
There was indeed a bug in my proxy code. I am not exactly sure what caused the symptoms described above, but fixing the code so that it didn't re-authenticate every time fixed my issue.
I'm trying to debug some server-side JavaScript code running in Aptana Jaxer and I'm not having any success. I haven't even been able to find any tutorials or posts about this issue. Does anyone know if it's possible and if so, what am I missing?
You can set you Jaxer.Config.DEV_MODE = true; to get some error information in your browser.
Also use the Jaxer.Log to debug.
Hope this helps a bit.
Jaxer and Aptana Studio do not yet have the ability to debug remote scripts from the client side. That is, you can't single-step into a callback and have your code window show you the first line of code in the remote method. This is on their wishlist, of course, but it'd be pretty tricky to do well.
Personally, I use logging. Jaxer has strong facilities for this, in Jaxer.Log.*.
A lot of people sneer at "printf() debugging", but the fact is, it works, and it's often less trouble to set up than an interactive debugger, especially for server applications and remote method invocation. You just sprinkle logging messages wherever you want to know the state of the system at that point, then make your app try to do the thing that's failing. Study the logs, rinse, repeat.
tail -f /opt/AptanaJaxer/logs/jaxer.log