Running Lucee server 5.2.1.9 (hosted at Vivio), and I'm unable to get it to show any run-time errors.
I have debugging enabled
I have enabled all debug info types
I've set a debug template (for all IPs); currently set to "Classic", but I've tried "Comment" and "Modern" as well.
When an error occurs, I get an empty page. If a debug template set, I get dumps of all the appropriate scopes and DB activity, as well as execution times... but no error message/details or stack trace.
Is there a setting I'm missing?
How do I insure Lucee displays my run-time errors during development?
I'm not sure if you every figured this out (kind of a necro). If you are in Dev disect your application.cfc. I had an issue in my onRequest section. Someone threw a cftry around the target page include. This ran Lucee into the catch and it showed a blank page.
If that doesn't help try removing your OnError function in there. There might be something in there that is trying to serve up a friendly error page which could prevent error output.
Also, look in Lucee server administrator and check that it is pointing to the native error.cfm that comes with the Lucee package.
I have to add it even though it isn't likely the cause. Search your code for any abort. It could be someone was testing a routine and was aborting to see how far Lucee was processing.
Hope these suggestions help.
Related
I'm getting started with Sylius. Symfony version is 3.2.7. On some pages I have some errors. The pages show text:
Oops! An Error Occurred
The server returned a "500 Internal Server Error".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.
I want the errors to be displayed in browser, with full stacktrace.
I know I can see the error in var/prod.log, but it doesn't show the whole stacktrace, only the last frame. And seeing the error in browser would be more convenient: that's what I'm used to after a lot of working with Yii and Magento.
Is that possible with Symfony/Sylius?
I added /app_dev.php to the url to run the website in development environment, and there I can see the stack trace.
That is, https://[my_domain]/app_dev.php/[page] instead of https://[my_domain]/[page]
By default Symfony show trace in dev environment. In prod environment it show simple error message. For running your project in dev you can use built-in PHP Web Server or Web Server Bundle
Also you can use symfony installer app to serve request
Use symfony serve --no-tls in symfony folder.
It will show you requests and errors in red.
I'm migrating from a Hybris 5.2 to Hybris 6.5, so far we managed to get rid of compilation errors and erros when running the server, but so far we have been unable to access the storefront.
When we try to access it we get a server error, but the log doesn't show anything that could give us a hint. Even the Chrome console doesn't show any errors.
I include the logs generated from the ant clean all and the hybris server startup in this link.
I have even debugged the home page controller, but no exceptions are being thrown, and my guesses are small since I have no feedback on the possible issue at hand.
What do we have to look at in these kind of situations? Is there a way to track the issue? Any tool in Hybris or an external one that could help me sniff the problem?
The issue was due to a missing configuration for JCO and SMTP, our client had a local.properties that had this configuration commented, after setting a configuration for these two the storefront was visible, still we don't understand how this missing configuration could not throw any error on console and we reached to this solution after a lot of trial and error.
I have a problem when placing an App module(v 8.4.8) on a page. When I placed an App module on a page I got a pop up saying "Had an error talking to the server (status 404). if you are an advanced user you can learn more about what went wrong - discover how on 2sxc.org/help?tag=debug".
This error happens on whatever action I try to do: trying to add and app, refresh page etc.
I checked a communication to the server using Firebug and seems that one of APIs are missing:
~/desktopmodules/2sxc/api/view/Module/GetSelectableApps
Referer: ~/desktopmodules/tosic_sexycontent/dist/dnn/ui.html?sxcver=8.4.8.19191
Did I missed something? Should I make some configuration after SexyContent module install (v 8.4.8)?
I just checked a video by Daniel Mettler where he showed how to install a module and seems that process is simple. Nothing to worry about.
Does anybody has any idea what might went wrong here?
The same actually happens when I install and Content module: Error about missing APIs:
~/desktopmodules/2sxc/api/view/Module/GetSelectableContentTypes
~/desktopmodules/2sxc/api/view/Module/GetSelectableTemplates
Thanks a lot for your time
My best guess is that it's an issue with the dnn domain/path configuration. So basically my guess is that
you have multiple domains, and if this is configured incorrectly, the paths in the js-calls won't fully match the original one
you have sub-portal (with paths like /products/) or something, and this isn't configured correctly in dnn
languages in portal-paths are causing similar issues.
So please compare EXACTLY the full base path and see if that's the issue.
I keep reading that an ASP.NET based web site should have custom errors enabled in the web.config because exceptions will show a stack trace.
I may have a faulty memory (currently don't have access to an ASP.NET website under development), but I thought as long as Compilation debug="false" in the web.config file, then the stack trace will not be displayed.
Is my understanding correct about the debug flag and display of the stack trace? If so, then even if custom errors are not enabled, then won't the only message displayed to remote users for an exception be a the non-descriptive message:
"The page cannot be displayed because an internal server error has occurred."
If so then wouldn't it be OK, from a security perspective, to not display a custom error page for the exception?
No, a stack trace will still be shown even if the debug flag is off, but it will not have line numbers for each call in the stack.
The non-descriptive message is what the browser usually shows instead of the actual error message from the server, unless you change the configuration. Anyone wanting to expose information by causing error messages would know how to do this.
Displaying the stack trace isn't a security risk in itself, but it does expose some information that could potentially make it easier to hack the site. A hacker might for example get a clue as to what's done to sanitase the input and find a way around it.
Custom error messages should almost always be prefered over the default error thrown. It gracefully sends your user to a location where they can keep browsing your site without having to go back and try again.
Turning DEBUGGING off in your web.Config is VERY important and goes beyond just not showing the line numbers and stack trace... it also tells the compiler to build in release mode which optimizes performance dramatically. As soon as your app goes to production, all debugging should be disabled.
I enabled tracing in IIS7.
I set those properties to true in the ASP tab of the IIS management tool:
appAllowClientDebug,
appAllowDebugging,
errorsToNTLog,
scriptErrorSentToBrowser;
To test it, I wrote a small classic ASP test page in wich I voluntary include a bug (bad activeX name).
My asp test page is rendered until the bug line is reached. The rest of the page is not rendered. I was expecting a 500 error code, but code is always 200. There is no error file in the FailedReqLogFiles folder.
Any idea someone?
OK, i think the issue is actually with Enable Server Side Debugging. You may have it enabled, but you should disable it instead.
The server thinks it should start debugging and tries to fire up a debugger, and then doesn't find one and just gives up! I'm sure this never happened prior to IIS7.
Glood Morning,
This problem was slowing our development significantly, because sql server errors were not displayed on the browser. Our Application Service Provider tried some settings, but couldn't get it to work. They sent me the settings and I accidentally did just two at once and our problem was fixed. They told me that asp was giving return code 200 instead of the error code.
Here is what worked for us:
The combination of "Send to Browser = True" and "Enable Server Side Debugging" = False" works.
I hope that helps others.
Tom Armstrong
Look at this and see if this is stopping you from getting the 500 error. Also, If the bug is handled through an exception handler in the activeX then you might not be seeing an error on the asp response.
http://classicasp.aspfaq.com/general/why-do-i-get-a-500-internal-server-error-for-all-asp-errors.html
200 OK is a Standard response for successful HTTP requests. The status code indicates that the client's request was successfully received, understood, and accepted.
We had this same IIS7 error happening. It was not returning any kind of error. There was no error message on the screen and no 500. The page just stopped rendering.
Is that what you are seeing? I can't remember what it was unfortunately, i think it was like something was handling the error. (If this is what you are seeing, i will keep trying to remember!)
I don't think this is it but it might be: go into Error Pages > Edit Feature Settings (hidden on the right panel) and select Detailed Error? That setting is also required and you didn't mention it.