If luaL_load function fails, then, according to the documentation (Lua5.1), the error message is pushed on the stack and can be retrieved with lua_tostring(L, -1), but if I want to print a customized error message, I don't think I can use lua_Debug (because that is for active function). Is there any other way (other than parsing the string) to get the file, line number and what error occured ?
--
Thanks.
The error code returned by luaL_loadfile tells you what kind of error happened. You're mostly likely only interested in LUA_ERRSYNTAX, in which case there is a detailed error message left on the stack. This is the only record of the error. If you need to reformat it, you need to parse it.
During a luaL_load(), there is nothing techinally on the stack that is relavant to the loading of the script. No functions are performed or executed in the script. Its just a compilation step, returning a function that encapsulates the whole file or the error found during compilation.
If you get a function back, you execute this to actually run the script, which sounds like what you are really interested in. In which case you can use a lua_pcall() and provide an error handler. In your handler you would then have your expected stack trace available via lua_Debug.
Related
I have encountered an issue recently while processing a CICS transaction. My CICS transaction is calling a chain of dynamically linked COBOL modules. The transaction runs fine for the first time after the PGM-A load is new copied into the region. When I try to process the transaction for the second time, I keep getting CEE3DD abend saying the module not found for PGM-B which is being called from PGM-A. IF I do a new copy for PGM-A in CICS, the transaction again runs fine.
Something is wrong with the CICS setup or memory but I am not able to figure it out. PGM-A is working fine in batch processing. PGM-B has no issues when it is called from any other PGMs except PGM-A.
Can someone share some thoughts on what may be wrong with this?
To invoke your program via CICS, it must be compiled with the NODYNAM option.
It admittedly seems counter-intuitive, but using the DYNAM option will cause CICS stubs to be loaded, instead of your intended programs, and result in the CEE3501S condition.
So, compile your programs with the NODYNAM option to avoid this error condition.
See the following links for additional info:
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3_cobol_subprog_rules.html
http://www-01.ibm.com/support/docview.wss?uid=swg21054079
Does PGM-A use "CALL VARIABLE" to invoke PGM-B? If so check the contents of VARIABLE on the second run (the contents of that variable will probably be reported in the error message. The contents of the variable may be overwritten by a bug in PGM-A. That might explain why the program always fails after the (seemingly) succesful run and after a newcopy.
Converting this from dynamic to static worked. But the question remains why it was not working with dynamic linking.
I've been trying to write a script-fu script for GIMP 2.6+ that uses one of the built-in script-fu methods, namely the script-fu-add-bevel method. My problem is that whenever I call it, either in the console or in my script, I get:
Error: Procedure execution of gimp-drawable-type-with-alpha failed on invalid input
arguments: Procedure 'gimp-drawable-type-with-alpha' has been called with an
invalid ID for argument 'drawable'. Most likely a plug-in is trying to work on a layer that
doesn't exist any longer.
This is really strange because I can clearly see by calling gimp-image-get-active-drawable with my image ID as the parameter that the layer ID that I'm passing to the script-fu method exists. The script is erroring while calling gimp-drawable-type-with-alpha, but I can call this method with the same ID in the console with no error. How can I fix this problem?
From this forum post, I learned that when calling a script-fu method, you shouldn't pass in the run-mode argument. This is done behind the scenes, and if you pass anything for that value, it will be interpreted as the second argument! This means that every argument you send in will be one parameter off, and it's only a matter of time before the script crashes.
So calling script-fu-add-bevel from another script-fu would look something like this:
(script-fu-add-bevel img layer bevel-width FALSE FALSE)
I am getting these errors in flat file connection manager.
Error: [SSIS.Pipeline] Error: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on Flat File Source returned error code 0xC0202091. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure.
I am reletively new to ssis and I am finding it quite hard to figure out the issue. Please let me know your views.
On your flat file connection properties - Look for the property "AlwaysCheckForRowDelimeters" - SET it to FALSE.
Hope that helps.
"An error occurred while skipping data rows" - I had this error in a package and found the problem was reading files inside a for loop. More files matched the criteria than intended, so a file with an invalid schema was also matched.
More generally I think this is related to either the file not matching the connection definition, I have also seen people online saying it is related to the flat file using a text qualifier (i.e. " in a csv) but having no closing quote.
I had this error today, and my package was looking for more files than existed based on the conditions of the for each loop. The text qualifier wasn't the issue causing this particular error.
near the Start button press drop-down menu arrow
choose package_name Debug Properties
than under Configuration Properties open Debugging
than under Debug Options choose Run64BitRuntime and turn it to False
When an unhandled exception happens while debugging some code in any procedure/function/method, the debugger stops there and shows the message.
If I now continue debugging step by step, the execution jumps directly from the line that created the exception to the end of the current procedure (if there is no finally block).
Woulnd't it be just as good to continue with the next line of the current procedure?
Why jump to the end of the proc and continue with the calling procedure?
Is this just by design or is there a good reason for it?
An exception is a unexpected situation, that why processings is stopped.
The jump to the end of the procedure is an invisible finally statement to release any locally "allocated" memory, like strings, interfaces, records etc.
If you want to handle a exception the you have to incapsulate the call that can give an exception with try .. except statement, and use an "on" clause to only handle that particular exception that you want to handle.
In the except you can inspect variables in the debugger and in code you can raise the exception again if needed.
In general, an uncaught exception will execute a hidden "finally" in each function on the stack, as it "unwinds" up to an exception handler. This cleans up local variables in each stackframe. In languages like C++ with the Resource Acquisition Is Initialization paradigm, it will also cause destructors to run.
Eventually, somewhere up the callstack, the exception will be caught by a handler. If there's no explicit one, the system-provided one will kill the process, because what else can it reasonably do?
Throwing an exception is a way of saying "Something unexpected happening. I don't know how to handle this". In such case it it better not to do anything (other than throwing the exception) than to try to continue, not knowing if what you're doing is correct.
In real life you have the same kind of thing: If someone asks you to count to 10 in Hebrew (or some language you don't know), you just say you don't know. You don't go ahead and try anyway.
I would expect it to jump to the end of the proc, and then jump to the except or finally block of the calling proc. Does it really continue in the calling proc as if nothing had happened? What does it use as the return value (if it's a function call)?
Continuing with the next line in the original proc/function would be a very bad thing - it would mean the code executing radically differently in a debugger to in release (where the exception would indeed cause execution to exit that proc/function unless there's an except/finally block). Why should debugging let you ignore exceptions completely?
It has to unwind the stack to find a handler.
I do agree it's very annoying behavior. Continuing isn't an option but it sure would make life easier if the debugger was pointing to the spot that threw it with the local variables still intact. Obviously, the next step would be to the hidden finally, not to the next line.
I just want to be able to examine everything I can about what caused it. I was just fighting this not very long ago. Text parsing, I KNEW the offending string contained no non-numeric characters (sanity limits mean the overflow case should never happen, it's my data file, all I'm worried about is oopses) and so I didn't put an exception handler around the StrToInt--what's this nonsense about it not being a valid number????? Yup--the routine wouldn't call it with anything non-numeric in the buffer--but an empty string has nothing non-numeric in it!
When exception generated I want to show some additional information (source code) for particular exception. But grails have very hairy exceptions (it's all about groovy dynamic nature). It's my problem where to get and how to display source code. All I need is file/line information.
So... Is there any possibility to get file and line where exception were generated in grails/groovy?
Hmm, you aren't already getting this? All my grails exceptions have file/line information in them by default. The only difficulty is that if the exception is in a closure, it doesn't show the actual closure name. Could you post a sample stacktrace?