JVM has an inbuilt try and catch block and in catch block there is a pointer of "Throwable class". In try block what code does JVM write to form string array and to call the main and pass the formed string array?
Related
I'm working with the NativeCall interface.
The library is going to call my callback function a bunch of times.
That works fine. I can just declare my callback with the right
signature, pass it in as &callback and the library calls the sub just
fine.
It also has the capability to set a payload void *pointer to anything
I want, and it will include that in the call to my callback function.
Can I hide a Perl Str, for example, in the payload and successfully round trip it?
sub set_userdata(Pointer) returns int32 is native { ... }
sub set_callback(&callback(Pointer $userdata --> int32)) returns int32 is native { ... }
sub callback(Pointer $userdata) returns int32 {
my Str $mystring = ???
...
}
my Str $my-userdata-string;
set_userdata(???);
set_callback(&callback);
It seems like it could work with some incantation of binding, "is rw", nativecast() and/or .deref.
You can only use a native representation in such a case (such as CStruct, CArray, and CPointer), or alternatively a Blob. You are also responsible for ensuring that you keep a reference to the thing you pass as userdata alive from Perl 6's perspective also, so the GC doesn't reclaim the memory that was passed to the C function.
Memory management is the reason you can't pass any old Perl 6 object off to a C function: there's no way for the GC to know whether the object is still reachable through some C data structure it can't introspect. In a VM like MoarVM objects are moved around in memory over time as part of the garbage collection process also, meaning that the C code could end up with an out-dated pointer.
An alternative strategy is not not pass a pointer at all, but instead pass an integer and use that to index into an array of objects. (That's how the libuv binding inside of MoarVM tracks down the VM-level callbacks, fwiw.)
I got around this by just ignoring the userdata and making a new closure referencing the Perl object directly for every callback function. Since there is a new closure created every time I set the callback, I think this will leak memory over time.
I am writing a jvmti agent for java programs.I am trying to read objects on the stack.Using jnienv pointer received on VMinit/vmstart event.
I succeeded in reading objects upon methodexit event using the foll:
get varaible (slot) from getlocalvariableentry() ;
from the variable signature use jni functions to get object, use getlocalobject function for a reference object/subclass of object.Then if its a subclass of object; jni::getobjectclass(); use returned class and obtain fields in the class;
using getclassfields(); then get field signature from getfieldname(); then call appropriate function for the field as per its signature eg getintfield() for int field.
Howver once I try this upon Objects created within a try block within the function for which methodexit event is raised; I get a crash(SIGSEGV) everytime at Getobjectclass() .Is this because the object has gotten destroyed being out of scope; If so how to read values of variables in a try block of a function at function exit.
obtain crash when upon reading a jobject for Integer (from localvariabletableentry) object , I call getintfield() for its int field member MIN_VALUE which is its first member.If I just try to read member "value" of Integer class then calling getintfield() does not crash.
Is this crash because Im trying to read a static final member of a class ie. member MIN_VALUE Of integer class.
How to come around this and avoid the crashes?
When calling a block, I can print its address by doing "po block" in the debug console. What can I do to print the address of a block I am currently in (i.e. when the debugger hits a breakpoint within the block)?
Note that the block can be anonymous block.
I haven't tested this, but you can get the address of a label using the && GNU extension, so you might be able to do something like this in any block, named or otherwise:
block_start:
// Some code
NSLog(#"Block at 0x%p", &&block_start);
Typing frame variable lists all the parameters and local variables in the frame along with their values, which when executing a block, includes the pointer to the block object itself as an entry called .block_descriptor. The value of the pointer (the address of the block object it points to) is printed next to it. You can then do po on that address if you like.
I haven't found a way to use this .block_descriptor thing by itself in the debugger (e.g. it is not accepted as a valid expression).
The program is used in the context of MPI.It's a MPI implementation of fortran.
I declare an array within a module.like
module var
real,save ::arr(8)
end module
Then use a subroutine like init to initialize the array arr.
In the main program unit,first call init to initialize the array arr.And then call another
subroutine like algo to do some computations.At the beginning of subroutine algo,the value of arr is correct.During the process of computation,the value of arr changed weirdly on some processors though there is no code changing the value of arr while on the other processors the value is correct.
I check the code and I am pretty sure no code change the value of arr during computation.
By the way,numbers of variables declared within the module var are numerous.
Thanks for all of you who give suggestions.The error is due to the access of array element out
of boundary.In my program there is a line of code accessing the index 0 element in array like
arr(0)=... which is beyond the range of fortran array.And this code leads to the value of another variable in the module to be changed which is quite unexpected to me.arr(0)=.. leads to the change of another variable like parm defined in the module.
Since you are using MPI, you must also broadcast the variable to all processors if the initialization is being done only on one processor
In a MATLAB class I am writing, if the constructor is given 0 arguments, the user is asked to provide a file using uigetfile. If the user cancels the prompt, uigetfile returns 0. In that case it makes no sense to make the object. Is there some way of cancelling the object construction without throwing an exception? If I do an early return I get a malformed object that cannot be used. Here is what the code looks like:
classdef MyClass
methods
function self = MyClass(filename)
if nargin == 0
filename = uigetfile;
if filename == 0
%cancel construction here
return; %I still get a MyClass object with self.filename == []
end
end
self.filename = filename;
end
end
properties
filename;
end
end
However I am unsure if using uigetfile in the constructor is the right thing to do. Maybe it should be the resposibility of another part of my code.
In modern Matlab objects, I don't think it's possible to get out of the constructor without either returning a constructed object or throwing an error. (In the old style classes, the constructor was actually allowed to return whatever it wanted, including objects or primitives of other types, and oh man could that turn in to a mess.) When a constructor is called, the output argument is already intialized with an object with the default property values, so when you call return there, it just skips the rest of initialization and returns the object. If you try to replace out with something besides a MyClass object, that's an error.
Just reorganize the control flow to pull the GUI code out of the constructor, like you're speculating on at the end. Mixing it in to the constructor, especially conditionally, can cause problems. In particular, Matlab expects the zero-arg constructor to always return a scalar object with some sort of default values, because the zero-arg gets called implicitly when filling in elements during array expansion and so on. It's basically used as a prototype.