For the following C++ and ActionScript3 code, my AIR application crashes when the getBytes2 method is called. Why is this happening? Solution suggestions would be appreciated.
C++ Code:
FREObject getBytes2(FREContext ctx, void* funcData, uint32_t argc, FREObject argv[])
{
FREObject result;
FREByteArray actualBytes;
FREAcquireByteArray(argv[0], &actualBytes);
uint8_t* nativeString = (uint8_t*) "Hello World from C++";
memcpy(actualBytes.bytes, nativeString, sizeof(nativeString));
FREReleaseByteArray(&actualBytes);
FRENewObjectFromBool(1, &result);
return result;
}
ActionScript3 Code:
public function getBytes2():ByteArray {
var ba:ByteArray = new ByteArray();
this._ExtensionContext.call("getBytes2", ba);
ba.position = 0;
return ba;
}
See FREImageProcessor.cpp for a working example of dynamically setting the length. Basically you set the length the same way you would in ActionScript.
FREObject length;
FRENewObjectFromUint32(sizeof(nativeString), &length);
FRESetObjectProperty(argv[0], (const uint8_t*) "length", length, NULL);
Are you getting any particular error or crash message? Which IDE are you using -- is it possible to attach the debugger on that process? I would put my money on the crash being during the memcpy function...
My only though it that while you are sending the string, you are not copying the null terminator from the string to your BA. I don't think that should matter however (you may experience extracting the data on the AS3 side, but that shouldn't cause an issue).
There were actually some people reporting similar issues when they were getting the byteArrays. I have a kludgy fix I haven't posted in the ArduinoConnector code for it yet. Pretty much involves seeding a 4096 byte byteArray on the AS3 side and sending that in. I also tried by just creating a new byteArray in the c side with similar results. According to the AIR engineers, we shouldn't have this problem, but I don't know if they accounted for how the memcpy function works.
Related
I'm working on making some Spotify API calls on an ESP32. I'm fairly new to C++ and while I seem to got it working how I wanted it to, I would like to know if it is the right way/best practice or if I was just lucky. The whole thing with chars and pointers is still quite confusing for me, no matter how much I read into it.
I'm calling the Spotify API, get a json response and parse that with the ArduinoJson library. The library returns all keys and values as const char*
The library I use to display it on a screen takes const char* as well. I got it working before with converting it to String, returning the String with the getTitle() function and converting it back to display it on screen. After I read that Strings are inefficient and best to avoid, I try to cut out the converting steps.
void getTitle()
{
// I cut out the HTTP request and stuff
DynamicJsonDocument doc(1024);
DeserializationError error = deserializeJson(doc, http.getStream(), );
JsonObject item = doc["item"];
title = item["name"]; //This is a const char*
}
const char* title = nullptr;
void loop(void) {
getTitle();
u8g2.clearBuffer();
u8g2.setDrawColor(1);
u8g2.setFont(u8g2_font_6x12_tf);
u8g2.drawStr(1, 10, title);
u8g2.sendBuffer();
}
Is it okay to do it like that?
This is not fine.
When seeing something like this, you should immediately become suspicious.
This is because in getTitle, you are asking a local object (item) for a pointer-- but you use the pointer later, when the item object no longer exists.
That means your pointer might be meaningless once you need it-- it might no longer reference your data, but some arbitrary other bytes instead (or even lead to crashes).
This problem is independent of what exact library you use, and you can often find relevant, more specific information by searching your library documentation for "lifetime" or "object ownership".
FIX
Make sure that item (and also DynamicJsonDocument, because the documentation tells you so!) both still exist when you use the data, e.g. like this:
void setTitle(const char *title)
{
u8g2.clearBuffer();
u8g2.setDrawColor(1);
u8g2.setFont(u8g2_font_6x12_tf);
u8g2.drawStr(1, 10, title);
u8g2.sendBuffer();
}
void updateTitle()
{
DynamicJsonDocument doc(1024);
DeserializationError error = deserializeJson(doc, http.getStream(), );
JsonObject item = doc["item"];
setTitle(item["name"]);
}
See also: https://arduinojson.org/v6/how-to/reuse-a-json-document/#the-best-way-to-use-arduinojson
Edit: If you want to keep parsing/display update decoupled
You could keep the JSON document "alive" for when the parsed data is needed:
/* "static" visibility, so that other c/cpp files ("translation units") can't
* mess mess with our JSON doc directly
*/
static DynamicJsonDocument doc(1024);
static const char *title;
void parseJson()
{
[...]
// super important to avoid leaking memory!!
doc.clear();
DeserializationError error = deserializeJson(doc, http.getStream(), );
// TODO: robustness/error handling (e.g. inbound JSON is missing "item")
title = doc["item"]["name"];
}
// may be nullptr when called before valid JSON was parsed
const char* getTitle()
{
return title;
}
I am trying to create custom tcl channel and use it to get the output of tcl Interpreter. I added the implementation of few function of Tcl_ChannelType but I am getting segfault.
#include <tcl.h>
#include <iostream>
int driverBlockModeProc(ClientData instanceData, int mode) {
std::cout << "driverBlockModeProc\n";
return 0;
}
int driverCloseProc(ClientData instanceData, Tcl_Interp *interp) {
std::cout << "driverCloseProc\n";
return 0;
}
int driverInputProc(ClientData instanceData, char* buf, int bufSize, int *errorCodePtr) {
std::cout << "driverInputProc\n";
return 0;
}
int driverOutputProc(ClientData instanceData, const char* buf, int toWrite, int *errorCodePtr) {
std::cout << "driverOutputProc\n";
return 0;
}
int main() {
Tcl_ChannelType *typePtr = new Tcl_ChannelType;
typePtr->blockModeProc = driverBlockModeProc;
typePtr->outputProc = driverOutputProc;
typePtr->closeProc = driverCloseProc;
typePtr->inputProc = driverInputProc;
typePtr->seekProc = NULL;
typePtr->setOptionProc = NULL;
typePtr->getOptionProc = NULL;
typePtr->watchProc = NULL;
typePtr->getHandleProc = NULL;
typePtr->close2Proc = NULL;
typePtr->blockModeProc = NULL;
typePtr->flushProc = NULL;
typePtr->handlerProc = NULL;
typePtr->wideSeekProc = NULL;
typePtr->threadActionProc = NULL;
ClientData data = new char[200];
Tcl_CreateChannel(typePtr, "im_chanel", data, TCL_WRITABLE | TCL_READABLE);
}
I cant debug the segfault because its source are not available. I think the segfault is because a function is called which is NULL. I only need to use the channel to get the output of interpreter. Which functions I needn't implement here and is it right direction to solve the problem.
You're advised to download the source to Tcl when working at this level. I'm not sure what version you're using, but all official distributions of the source going back a very long way are on the SourceForge file distribution system; pick the exact match for the version you've got.
Creating a custom channel driver is not easy. There's a significant amount of complexity involved, and it isn't especially well-documented what “methods” within the channel driver type are mandatory and what are optional. (They're not C++ methods in a class — Tcl is pure C code for reasons too long to go into here — but they function in a conceptually similar way.)
If we look at the documentation for Tcl_CreateChannel, we see (quite a long way down that page) a definition of the channel type structure. The channel type structure should be statically allocated (Tcl's implementation assumes very strongly that it never changes location) and the following fields must be set to something meaningful:
typeName — This is the name of the channel type, useful for debugging!
version — This is the version of the channel type; you should set it to the latest version supported by your target source level. (You're recommended to use at least TCL_CHANNEL_VERSION_2 or things get rather more complex.)
closeProc or close2Proc — Channels must be closeable, but you have two choices for ways to do it. Bidirectional channels ought to use the close2Proc, but aren't strictly required to.
inputProc — Only needed if you're reading; take care to handle this correctly.
outputProc — Only needed if you're writing; take care to handle this correctly.
watchProc — Called to tell the channel driver to install itself into the event system so as to receive suitable events (as instructed by the supplied bitmask). Channels that don't have backing OS handles use timer events, or simply never actually generate events (in which case they'll never become readable or writable from the perspective of fileevent).
Looking at your code, I see that you're missing a watchProc. I know it's hard to see (not many people write channel drivers, to be honest, so the documentation isn't very hard “tested”) but it's really necessary.
In my understanding, DeviceIOControl and ioctl are the same functions. They both send control codes to the hardware and return the responses. In an effort to reuse code, I am trying to create a function which will work in a cross-platform manner. Therefore, I've decided to use the DeviceIOControl api since it is fixed and specific. The problem is: how do I map ioctl to that?
I currently have:
int DeviceIoControl_issueCommand(DeviceHandle handle, int command, void *input, ssize_t sizeof_input, void *output, ssize_t sizeof_output, uint32_t *bytes_written){
#if SYSTEMINFORMATION_ISWINDOWS
int result = DeviceIoControl(handle,command,input,sizeof_input,output,sizeof_output,bytes_written,0);
if (result == 0){
result = -1; //-1 is the new error return
}
return result;
#else
int result = ioctl(handle, command, input); //this doesnt work!
return result;
#endif
}
Any help is greatly appreciated!
What you are asking is not possible without a lot of internal translation in DeviceIoControl_issueCommand. The function calls are completely different and expect different parameters and data. You can work around this by declaring an IOControl class and adding member functions for each type of IO functionality you want to support.
class IOControl
{
public:
void DoIoControlX();
void DoIoControlY(int param1, int param2);
};
Then provide an impelementation for each platform you need to support. One for Windows DeviceIOControl calls and one for systems that support ioctl
I actually found that there is an IOCTL which does pass raw data to and from the driver (at least for the hard drive): HDIO_DRIVE_TASKFILE (http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt)
I have a win32 console application with ruby 1.9.3 embedded, and I am having problems with ruby GC and objects with wrapped C structs that include a pointer to big data.
After some testing, ruby seems to run the GC when the orphaned objects are taking up some memory. The problem is that ruby does not take into account the memory size the struct pointer is taking up, so it won't start the GC as it thinks that those orphaned objects are too small and do not take up much memory.
I have made an example app that will crash as it creates lots of objects with big data in their wrapped struct, here is the code:
#include <ruby.h>
typedef struct TestClassStructS {
byte* bytes;
} TestClassStruct;
static void testClassFree(TestClassStruct *p) {
delete p->bytes;
delete p;
}
VALUE testClassNew(VALUE klass) {
TestClassStruct* ptr = new TestClassStruct();
ptr->bytes = new byte[1024 * 1024 * 5]();
VALUE obj = Data_Wrap_Struct(klass, NULL, testClassFree, ptr);
rb_obj_call_init(obj, 0, 0);
return obj;
}
VALUE testClassInitialize(VALUE self) {
return self;
}
typedef VALUE (*rubyfunc)(...);
VALUE require_wrap(VALUE arg)
{
return rb_eval_string("GC.enable; loop do; TestClass.new; end");
}
int main(int argc, char** argv[])
{
RUBY_INIT_STACK;
ruby_init();
//freopen("CON", "w", stdout);
ruby_init_loadpath();
ruby_sysinit(&argc, argv);
VALUE testClass = rb_define_class("TestClass", rb_cObject);
rb_define_singleton_method(testClass, "new", (rubyfunc)testClassNew, 0);
rb_define_method(testClass, "initialize", (rubyfunc)testClassInitialize, 0);
int error;
VALUE result = rb_protect(require_wrap, 0, &error);
if (error)
{
VALUE lasterr = rb_gv_get("$!");
VALUE message = rb_obj_as_string(lasterr);
printf(StringValuePtr(message));
}
return ruby_cleanup(0);
}
This is not a real case scenario, but makes me worry that in some cases my app could take too much memory if the GC is not started.
I could fix this problem making regular calls to GC.start, but it seems like a dirty solution for me.
If there was a way for making ruby to prioritize garbage collection when some objects are orphaned or to tell ruby the real size the c struct occupies in memory, would be a nice solution, but I do not know if ruby api includes something like this, I could not find anything like that.
If you can, use xmalloc (from ruby.h I think) to allocate the memory. That is, so far, the only way to make sure that the allocated memory gets accounted for the next GC trigger.
There is a new dsize function registered with wrapped C structs, but it seems that it is not (yet ?) used in ruby 1.9.3
I know this has been asked before, and I tried to implement the solution, but I just get exception errors when I call ps->executeUpdate(). Has anyone got an explicit example?
This post is a bit old, but I ran across the same question. I employed the method above and it didn't quite work right for my case, which was trying to take a vector and use that for the stream. What I was doing was taking a UUID and converting it into a 16 byte binary version to use in the table. Using the method above, I found that only half my buffer was being populated.
I ended up using a stringstream.
std::vector<unsigned char> convertedId;
std::stringstream stream;
// convertedId has been populated with the 16 byte binary version
stream = std::stringstream(std::string(convertedId.begin(), convertedId.end()));
// Parameter 1 is BINARY(16)
pStatement->setBlob(1, &stream);
A few other things to keep in mind. The stream is not accessed until one of the execute variants is called. So you'll need to keep the stream around until you have run execute.
Hopefully this will help someone and save them time.
Sorry Matthew - I assumed the previous answer to this question (by elrohin). Maybe I should have replied to that. Anyway heres the code he suggested:
class DataBuf : public streambuf
{
public:
DataBuf(char * d, size_t s) {
setg(d, d, d + s);
}
};
// prepare sql update statement etc. and set the data pointer
string* pData = ; // ...not part of the original answer
DataBuf buffer((char*)pData->data(), pData->length());
istream stream(&buffer);
ps->setBlob(1, &stream);
ps->executeUpdate(); // This causes an exception in free.c
I'm using VS9 with the latest (beta) connector/cpp debug libs. I've also tried using char* instead of string.
This code works fine for me:
Driver *driver;
Connection *conn;
driver = get_driver_instance();
conn = driver->connect("tcp://127.0.0.1:3306", "root", "root");
std::auto_ptr use_stmt(conn->createStatement());
use_stmt->execute("USE world");
std::auto_ptr stmt(conn->prepareStatement("INSERT INTO terrain_texture_tiles_0 (data) VALUES(?)"));
std::string value("A\0B", sizeof("A\0B") - 1);
std::istringstream tmp_blob(value);
stmt->setBlob(1, &tmp_blob);
stmt->execute();
hope it helps ... Jaroslav Pribyl