I ran into this error while trying to compile my overleaf latex;
"Server Error Sorry, something went wrong and your project could not be compiled. Please try again in a few moments".
Your response will be helpful. Thanks
This problem may arise as a result of the internet connection. The simple way to resolve this problem is to reload the Overleaf editor by refreshing your browser.
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"?
How can I write exceptions in a text file using C# & webdriver?
This is for creating logs whenever a script fails.
You are probably looking for log4Net. This is a very feasible solution for logging. This gives you the opportunity to create .txt files as well as lot others. You may need to understand the configuration little bit which is not too bad either. Here is the details. This gives you the opportunity of multiple level logging Such as fatal, error, info etc.
Speaking about logging and Selenium:
There is a logging feature going to be introduced to Selenium soon. It's still in progress. See this
There is also a native class exist for java. Unfortunately not for c# as per my knowledge.
A step by step description here
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
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.