I am using the lua C-API to read in configuration data that is stored in a lua file.
I've got a nice little table in the file and I've written a query C-function that parses out a specific field in the table. (yay it works!)
It works by calling a few of these kinds of functions over and over:
...
lua_getglobal (...);
lua_pushinteger (...);
lua_gettable (...);
lua_pushstring (...);
lua_gettable (...);
lua_lua_getfield (...);
...
you get the idea.
After I am done querying my data like this, do I have to clean up the stack?
As long as your stack doesn't grow without bound, you'll be fine. When you return integer N from the C API into Lua, two things happen:
The Lua engine takes the top N values from the stack and considers them as the results of the call.
The Lua engine deallocates (and reuses) everything else on the stack.
David Seiler mentions the possibility of your C code being called from other C code and not from the Lua engine. This is an advanced technique, and if you are asking this question, you are unlikely to have to worry about that particular issue. (But the way it happens from Lua's perspective is the same—when all the C code finishes executing, it has to return an integer, and Lua peels that many values off the stack and then deallocates the rest.)
If you use too many stack slots, your program will halt with a sane and sensible error message (as I know from experience).
It depends.
If your C function is called from Lua, the values you leave behind will be the values that your C function returns to Lua. If your C function is called by another C function that uses the Lua stack, then those values will still be on the stack, and you can do anything or nothing with them.
But if after you've called your C function you're done with Lua altogether, and from your question it sounds as though you are, then you don't have to clean up your Lua stack. Just close the Lua context, and it will clean up your stack for you.
additionally, instead of using pushstring or pushinteger followed by a gettable, use lua_getfield and lua_rawgeti respectivly (the raw will not invoke metamethods though, incase you wanted that...)
Related
Say I have the address of a table - how would I "cast" a table variable to it? I'm not concerned about "bad practice" or crashes because this is just an individual problem.
I want to do something like
lua_table tab = *(lua_table*)0xaddr
...but within the Lua global environment.
I understand how bad this is but I really need to know if this is possible. It may not be the best way to do what I'm trying to do, but I'm quite certain it's the easiest and that it will work if this is possible. I am using Lua 5.1.4.
Lua exposes no API for doing this.
It would be easier and much more robust to fix your design rather than trying to force this to work.
In order to do what you're attempting, you must:
Get a pointer to the Lua table's data structure. I'm sure you believe that you already have such a pointer. But there's nothing in Lua that guarantees that the pointer you have obtained (through some means) is actually a pointer to the table data structure. It could be a pointer to something else. So you need to hunt through Lua's internals to make sure that wherever you're getting this pointer from is giving you a pointer to the actual object.
Find the correct type, declared within Lua's internals. There is some C type (Lua's written in C, not C++) that Lua uses to represent the main table data structure. You will have to track down this struct definition and use that.
A cursory examination of the Lua library suggests that the main table data structure is defined in lobject.h, under the name Table.
Find the internal APIs that Lua uses to manipulate this table correctly. It's obviously some kind of hash table, but you're going to need to use Lua's functions to actually do anything with it.
A cursory examination of Lua's internals suggests that this code would be found in ltable.h. However, there are probably more APIs than that. Also, do note that many of those APIs take a lua_State, so they may be doing some stack fiddling.
You will also need to look through Lua's API so that you can learn how to use them without breaking the table. Lua may have certain expectations about when certain functions are called or the order between them or whatever. Break these at your own peril.
Even then, this:
Table tab = *(Table*)0xaddr
Will never work. Or at least, not the way you mean for it to. Lua is written in C. Which means that Table is not going to work like a C++ value type. Copying it will only do a bitwise copy. So modifying tab will only modify your local copy of those values. If those are pointers to other data structures, that may be OK, since your pointers and the original pointers point to the same data structures. But if you perform some operation that changes the Table::flags field on the table, for example, the table stored in Lua will not be affected, only your local tab copy will be.
You have to manipulate the object as a pointer, not a copy of the original.
Table *tab = reinterpret_cast<Table*>(0xaddr);
This is a terrible idea, but i'm seeing if it's even feasible before I walk down this road.
I have to write a Win32 C++ program that can dynamically load a library based on a file that has serialized information on what dll, function, signature, and arguements to use. Loading the library is trivial (LoadLibraryEx works fine). Then getting the function pointer is easy (not a big deal, the GetProcAdderss takes care of this). However the rest is tricky.
Here's my plan of attack, feel free to let me know if this isn't the best approach:
Open the serialized information from a file on what DLL to load, and what function to execute.
LoadLibraryEx to bring in the DLL
GetProcAddress to get the function pointer (after casting the byte array to a string)
Write the arguments (which are read in as a byte array) to memory in bytes.
Get the address to the beginning of each argument (i'll know from serialization what the size of each argument is).
Using assembly jump to the beginning of the function pointer, push the addresses on the heap to the arguments in the stack (in reverse order).
Execute and get back the return value address (as a void * ?)
Use the memory address of the return value (that I got from assembly) and the size (which I got from the serialization) of the return type value and write the raw bytes back to a file.
Keep in mind my limitations:
I will never know except for run-time what the signature, dll, function name is.
It is always read in from a file.
Is there a better approach, will this approach even work?
Update
For anyone who comes poking in this thread to learn more, I found a solution. In C you can dynamically load a library using dlopen (there's a winlib of this for ease of use). Once loaded you can dynamically execute functions using libffi (supports mac/ios/win 64 and 32bit). This only gets you to C functions and primitive types (pointer,uint,int,double,float) and thats about it. However using macosx objective-c bridge you can access objective-c by loading libobjc (osx's native obj-c to c "toll free" bridge). Then through that dynamically create obj-c and c++ classes. A similar technique can be done on windows using C# and its marshaling capabilities.
This ends up with HIGH overhead, and you must be VERY careful about your memory, in addition don't mix pointers from C/C#/C++. Finally, whatever you do, at runtime. BE ABSOLUTELY SURE YOU KNOW YOUR TYPES.... seriously. BTW, libffi/cinvoke, amazing libraries.
There are existing libraries that can do what you describe, such as C/Invoke:
http://www.nongnu.org/cinvoke/
General rule, that if you have a terrible idea, drop it and find a good one.
If the signature is not known at all, what you describe will fall on face. Suppose your call works for my function as it is. I change the function from __stdcall to __cdecl or back, and you will crash.
Also you don't handle the return.
If you relax the "unknown" to allow some limitations, like fixing a return type and calling convention, you are somewhat ahead -- then really you can emulate the call but what is it good for? This whole thing sounds like a self-service hack-me engine.
The normal way is to publish some fixed interface (using function signatures), and make the DLL support it. Or arrange some uniform data transfer mechanism.
I'd suggest you to describe what you're after really and post ask that, maybe on Programmers SE.
Infinite recursion is most often not desired, and when it happens it usually causes a stack overflow or segfaults.
But for theory's sake, and plain curiosity, I've been thinking if it'd be possible to create actual infinite recursion, intentionally.
Working in C++ and C where the stack, usually, grows for each function call, and each function returns and pops the part of the stack it handled.
Here's the thought. Would it be possible to force a function to clear out it's own stack space and then call another function so that the new function effectively replaces the first function, without the first function needing to return and then fire again via a loop.
I'm not only thinking about plain loops as a possible use for this, if there would be any. Loops usually do a good job at what they do. But what if you were to use it for sending signals through a node network, that carry on indefinitely in their own process threads until they reach a certain condition. It might be a tool that could be used for some problems.
Remember, I'm not really asking if it's practical, only if it's possible to do. For science!
Would it be possible to force a function to clear out it's own stack
space and then call another function so that the new function
effectively replaces the first function
This is used for tail-call-optimization, so yes, it is possible and used in practice. In languages like C++ this a nice feature, because sometimes algorithms are simpler to express using recursion, but more efficiently implemented using a loop. The transformation can in some cases be done automatically by the compiler.
There is a technique called trampolining that is used to implement continuation-passing style programming without the use of tail-call optimization. If you consider any language without support for TCO, such as JavaScript, and research solutions for CPS in that language, then it is likely that the solution involves trampolining.
Essentially, with trampolining there is a function called a trampoline which iteratively calls thunk-returning functions.
I know that you said "without the first function needing to return and then fire again via a loop"—that's what trampolining is—but considering that this is C++, leaving scopes by, for example, returning is central to the core design of C++'s automatic resource management via destructors (see: RAII). You could alternatively use C's setjmp()/longjmp() functions to wipe out stack, but then you would need to be very careful in making sure that all resources are released properly.
This does remind me of an optimisation that can be done in assembler code. Say you have this:
call FuncA
call FuncB
you can replace it with:
push ReturnAddress
push FuncB
jmp FuncA
ReturnAddress:
This causes the ret at the end of FuncA to jump to FuncB directly rather than back to the caller and then onto FuncB. Not really possible in higher level languages.
There's also this:
call FuncA
ret
which can be changed to:
jmp FuncA
I'm having problems with luabind. I define a std::map to allocate objects created in lua. I publish this map as a global object in lua in this way:
luabind::globals(L)["g_SceneManager2D"] = this;
After that, this object is used into a function into lua, where many objects are created and inserted into this map. The problem comes when lua function ends and luabind returns the control to C++ side program, because automatically all contents of the map are lost.
I was looking for the error. I keep the lua context alive, so this object must exists.
Could you helpme??
Many thanks :)
I suggest use a shared_ptr<>(this) rather than raw this. boost::shared_from_this might help. Make sure your class is registered using Luabind too, and that the class_ is specified as held by a shared_ptr.
Another fun idea might be to make your Lua function just generate the "map" as a Lua table, return it, and you can iterate over it in C++ to build your std::map.
If I understand your problem correctly, it seems you are creating objects in Lua, which you then insert into the map (either through Lua or C++) and subsequently lose. Without some more code, it's hard to tell exactly what the problem is. However, I would first look to make sure that those objects are indeed being created (double check it) and then I would check to see that Lua isn't garbage collecting them. If Lua is indeed garbage collecting those objects, then you won't see them on the C++ side because they're, well, gone.
If it helps, I'm finishing up a project which does something similar. I had to create and retrieve C++ objects from Lua, but instead of creating the objects in Lua, I just called C++ functions to do it for me, sending any necessary data in the Lua call (bound by Luabind). Those (C++) functions indexed the objects by IDs into hash tables and the IDs were returned to Lua in case it needed to retrieve the object script-side for operations. This setup makes it easier (and safer) to handle memory stuff correctly and prevents Lua from garbage collecting your objects.
I have just started at a new job. Here we are new to using JNI ( for bridging C++ / Java ). I am new to JNI so please forgive my noobness :)
In our (win32) Java app we are loading a C++ DLL. On the Java side we have several instances of "SomeJClass" each of these instances needs access to corresponding instance of "SomeCClass" on the DLL side.
The DLL exposes entry-points such as GlobalDoSomethingInC(). Here I must call the instance method of Doer::DoSomethingInC(). So I need a smooth way to map the respective this-pointers.
I also need to do the same mapping when a DLL thread discovers something interesting that it needs to notify the corresponding Java-instance of.
I can think of several solutions, but I do not like them too much. My question is, is there a better way than this ?
1 Java calls C:GetNewInstance(). This returns an int that is actually a pointer to the new C instance. Java stores it in m_myCInstance. Then Java calls GlobalDoSomethingInC(), and
1a
// DLL global
void GlobalDoSomethingInC()
{
// retrive this pointer
//calling back to Java:
jobj tmpJ = NewGlobalRef( env, obj );
Doer* myDoer = <reinterpret_cast>( Doer )tmpJ->GetMyCInstance();
myDoer->DoSomething();
DeleteGlobalRef( env, tmpJ );
// Arrrrgh
}
1b or:
// for **every call** that Java adds a parameter,
//which is the stored int:m_myCInstance, and
Doer* myDoer = <reinterpret_cast>( Doer )instanceParam->DoSomethingInC();
// Can we do better that this?
2 For calling from C to Java, things look, maybe, better
In the constructor C calls back into Java and stores
the Java instance reference
in a member variable. m_myJInstance.
In all subsequent calls m_myJInstance can be used to call back Java.
In the destructor we need to call DeleteGlobalRef( env, m_myJInstance );
Not too bad I suppose. But it really safe to store the jobject reference.
I mean: What happens when the GC moves the object around?
3 Our present solution does "work". But it belongs on rather on http://www.codinghorror.com/blog/ :)
Thanx
Typically this will depend on your environment somewhat. I've only used KNI, which is even more primitive than JNI. I think a fair bit of ugliness is unavoidable, as you're mixing memory tracking across two systems, only one of which has GC.
In general, I found it best to wrap all of the calls out the C code in functions that took care of the nasty casting, which I think is unavoidable. (BTW, I'll use C to mean non-Java code here)
On the C side, movement of Java objects is definitely a potential problem. It will depend on your platform, but I would expect that as long as you are within the lib, you can expect no Java GC to occur, so your objects are stable. YOU NEED TO BE SURE OF THIS. On the other hand, if it's not the case, you're pretty much screwed. Assuming it is the case, you want to do the same thing of isolating dereferencing/casting to the function that's exposed to JNI, so that you can happily work with normal C objects in all of your called functions.
Where it can get really ugly is if you can have objects go out of scope on either side, as then potentially either side can be holding a reference to your object. Here we used finalizers on the Java side, as well as destructors on the C side. It wasn't pretty, but I think that what somewhat unavoidable.
So, short answer, it will be somewhat ugly, isolate the ugliness around the interface between the two languages, so that for the bulk of the work, in either language, you don't have to worry about such things.
It's also worth having a base class for objects that exist over this interface, as here you can also isolate some ugliness.
jobject is an opaque handle to an object. May vary in runtime implementation (see Android 2.x vs 4.x), but just trust that it is an opaque object.
The current solution is probably correct. If you must stash a jobject in native code, you must convert it to a Global reference -- If you call NewGlobalRef, the object's refcount has increased, and will not be disposed until you call DeleteGlobalRef (and the GC has noticed it is unreachable otherwise)