I am using PolyML compiler 5.6 Release on Mac OS. I'm compiling and running some code which raises an exception (Fail "undefined"). I am expecting my compiled app to exit with a stack trace when the exception is raised; but instead it exits silently.
How can I get PolyML to show stack traces or at least line numbers where the exception is raised?
Running your application under the debugger is the best way to find out where the exception is happening.
If you can't or don't want to use the debugger you can get line number and source file information by adding a handler and using PolyML.Exception.exceptionLocation to get the location from the exception packet. See http://polyml.org/documentation/Reference/PolyMLException.html
In Poly/ML 5.6 you can also use PolyML.exception_trace to get a trace of the calls that led to the exception but that's likely to be removed in the next release,
Related
Laravel Version: 5.7.28
PHP Version: 7.2.15
Database Driver & Version: MariaDB 10.2.23
I am struggling with a bug on my production server using Horizon.
ErrorException: Warning: PDO::prepare(): MySQL server has gone away
[internal] in unserialize
You can see a stack trace of the error here: https://sentry.io/share/issue/b105b7946b524a9e841f56f44445ea14/
As far as I can tell, this error should be caught by the Laravel framework. I'm not sure why it's not being caught and turned into a QueryException which would then trigger the reconnection and/or killing the worker.
See: https://github.com/laravel/framework/blob/9fb420cc29a7dd5de5051f09c523ffc3ea01b969/src/Illuminate/Database/Connection.php#L663
And then: https://github.com/laravel/framework/blob/9fb420cc29a7dd5de5051f09c523ffc3ea01b969/src/Illuminate/Database/Connection.php#L735
My understanding is that any Exception should be caught and then re-thrown as a QueryException, which would then be properly caught by the framework and then reconnected to the database.
This is an occasional error so it's difficult to reproduce; I've tried to manually throw a similar error but it is caught properly and handled properly.
Any general guidance on why this error might be different in production and ideas on how I can isolate the error would be appreciated.
In case anyone else runs into this, the current theory is that Sentry is catching errors that are still being handled properly by the framework.
Essentially, the job still completes correctly, because MySQL connection errors are handled automatically by the framework. However, Sentry still catches an error in that error handling process, though the reason is currently unknown.
For reference, see this discussion on Github:
https://github.com/laravel/horizon/issues/583
I applied Glog to output some runtime information in my code, and I want to disable the stack trace function to protect the detail of the code. But I find the Glog is default to track the stack trace and log it to std err or log file, and there is no FLAGS_xx to disable it.
And I tried to #undef some of the stack trace related macro such as HAVE_STACKTRACE, but it doesn't work.
Do you have any elegant method to do this?
I use the GOOGLE_GLOG_DLL_DECL void InstallFailureFunction(void (*fail_func)()); to install a customized function to output some customized information instead of the stack trace.
But in the std output there is still a line *** Check failure stack trace: *** to remind the user, and I don't know how to shut it down. It's not elegant enough.
I've been trying to get StackDriver Error Reporting working on my golang project.
I'm running the logging agent on a vm in GCE. No matter what patterns I try it does not seem to pick it up, though it has picked up random bits of some of the stack traces, that seem to be something like
/^go:.*/
Below is an example of an error that Stack Driver picked up, and how it was mangled.
Raw Tab
router.go:16: goroutine 47 [running]:
github.com/org/repo/baserouter.RecoverFromPanic.func1.1(0x15267e0, 0xc420056340)
/home/myuser/go/src/github.com/org/repo/baserouter/router.go:14 +0xe2
panic(0xf6c320, 0xc4200120b0)
/opt/go-1.7.1/src/runtime/panic.go:458 +0x271
Title
go: 16
Parsed Stack Trace Tab
"not available"
How can I log out an error and a stack trace via the agent so StackDriver picks it up and parses it properly?
I'm looking to do some kind of debugging on windows where the state of the service appears to be a deadlock. Perhaps the approach would be to do a dump. How can you do a program dump of a Go service? And then analyze that dump?
I've done this using the runtime.Stack function. Its output is equivalent to what you get from a panic(), but without halting the program. You can set up a signal handler to dump the stack to a file/stdout, or start a goroutine to dump the stack at regular intervals, if you prefer.
You could also check out the runtime/debug package.
Goroutine deadlock analysis is handled well using the trace command.
First, you need to get data to run a trace against, which you want at any point. You can get this by using the pprof package or the trace package.
https://golang.org/pkg/net/http/pprof/
https://golang.org/pkg/runtime/trace/
The pprof package will add its HTTP handlers to a web server and let you collect trace data while the app is running, while the trace package lets you write out a trace to a stream (e.g. a file), but I haven't tried that myself.
Once you've collected trace data, you can run the trace command against the data you've collected to produce a web view of the state:
https://golang.org/cmd/trace/
There's an example output here:
https://talks.golang.org/2015/dynamic-tools.slide#30
is there any component in Delphi7 to show more information about an exception in runtime like:
exception message and class
".pas" file name
line number of exception
This information is very important when running the application on customer site.
The Delphi 7 compiler does not include the filename or line number in the DCU. (Later versions make the filename available through RTTI, but it's not present in D7.)
You could use an exception handling package such as MadExcept (free for non-commercial use, and reasonably priced for a commercial version), EurekaLog (commercial, but I have no info on cost), or the JEDI JclDebug unit (Open Source), which can use the debugging information and information from a linker map file to provide a stack trace from the exception back. That stack trace includes the unit and line number (as well as the method or procedure name) where the exception occurred.