openCV / unhandled exception or msvcp100d.dll - exception

I do realise that this problem is pretty common, but I have spent around 4 days so far, trying to fix it on my own, using all the smart advice I found on the Internet and - unfortunately - I've failed.
I managed to make openCV2.4.6 work with my VisualStudio 2012, or at least that's what I assumed after I was able to stream a video from my webcam with this example:
#include "stdafx.h"
#include "opencv2/opencv.hpp"
int main( int argc, const char** argv )
{
CvCapture* capture;
IplImage* newImg;
while (true)
{
capture = cvCaptureFromCAM(-1);
newImg = cvQueryFrame( capture );
cvNamedWindow("Window1", CV_WINDOW_AUTOSIZE);
cvShowImage("Window1", newImg);
int c = cvWaitKey(10);
if( (char)c == 27 ) { exit(0); }
}
cvReleaseImage(&newImg);
return 0;
}
Everything worked fine, so I decided to play around with it and I made an attempt to use a simple image processing operation such as converting rgb to grayscale. I modified my code to following:
#include "stdafx.h"
#include "opencv2/opencv.hpp"
int main( int argc, const char** argv )
{
CvCapture* capture;
IplImage* img1;
IplImage* img2;
while (true)
{
capture = cvCaptureFromCAM(-1);
img1 = cvQueryFrame( capture );
img2 = cvCreateImage(cvGetSize(img1),IPL_DEPTH_8U,1);
cvCvtColor(img1,img2,CV_RGB2GRAY);
cvNamedWindow("Window1", CV_WINDOW_AUTOSIZE);
cvNamedWindow("Window2", CV_WINDOW_AUTOSIZE);
cvShowImage("Window1", img1);
cvNamedWindow("Window2", CV_WINDOW_AUTOSIZE);
int c = cvWaitKey(10);
if( (char)c == 27 ) { exit(0); }
}
cvReleaseImage(&img1);
cvReleaseImage(&img2);
return 0;
}
And that's the place where the nightmare started. I keep getting the
Unhandled exception at at 0x000007FEFD57AA7D in opencvbegginer.exe: Microsoft C++ exception: cv::Exception at memory location 0x000000000030F920.
I did some research and tried few solutions, such as exchanging opencv_core246.lib to opencv_core246d.lib, etc. For a second I hoped it might work, but the reality punched me again with msvcp100d.dll missing. I tried to update all redistributable packages, but it didn't change the fact I keep getting this error. I tried to find out how to fix it another way and I found some forum on which they tell to go to C/C++ properties and change the Runtime Library to MTd, so... I tried this as well, but - as you can notice by now - it didn't work.
At this current moment I just ran out of ideas on how to fix this, so I would be really grateful for any help.
Cheers
PS. Important thing to add: when I got the unhandled exception, opencv 'spoke to me', saying
OpenCV Error: Bad argument in
unknown function, file ......\scr\opencv\modules\core\src\array.cpp,
line 1238
However, I already assumed way back then that I'm just not clever enough with my idiot-resistant code and I tried few other pieces of code that were written by competent people - unfortunately, I keep getting exactly the same error (the rest is the same as well, after I change the things mentioned above).

If img1 == NULL, then it crashes on cvGetSize(img1). Try enclosing the code after cvQueryFrame in an if (img1 != NULL).
However, if it returns NULL for every frame, it means there is something wrong with your camera/drivers/way you capture the frames.
You should also move the cvNamedWindow outside of the loop, since there is no need for it to be recreated for every frame.

Related

Kiss FFT on TI MSP430FR6989

I am trying to run Kiss FFT (Kiss FFT github) on an MSP430FR6989 Launchpad. For now, I'm just trying to get the kiss_fftr test shown here to work. I am running into an issue with kiss_fftr_alloc(int nfft,int inverse_fft,void * mem, size_t * lenmem). My input is (16, 0, NULL, NULL). The function reaches this point in kiss_fftr.c and then returns NULL due to the !st if statement.
if (lenmem == NULL) {
st = (kiss_fftr_cfg) KISS_FFT_MALLOC (memneeded);
} else {
if (*lenmem >= memneeded)
st = (kiss_fftr_cfg) mem;
*lenmem = memneeded;
}
if (!st)
{
return NULL;
}
Malloc sets st to NULL, so it failed to allocate the memory. I am sure that there is enough memory available in my MCU. My memory allocation in CCS is 35% RAM (736/2048), 3% FRAM1 (1896/48000) and 28% FRAM2 (23144/81912).
Does anyone have advice on how to fix this, or what I should learn to fix this? I don't want to chase down the wrong rabbit hole if memory allocation is not the issue.
What I've tried: When I try running the test code given in the stack overflow link and sending the output array over UART, I get no output. I checked to see if kiss_fft_alloc is working correctly by making an if statement (st == NULL) that would throw a KISS_FFT_ERROR. The error threw at the point mentioned above, but I cannot figure out how to "fix" malloc failing to allocate memory.

Read SPI Eeprom using a pointer does not work but works when not using a pointer

I am new to programming and I am trying to read a page (64Bytes) from an SPI Eeprom and I got it working when reading to an array[67] (3 transmitted Bytes to start the read process via SPI + 64 Bytes data).
I am using IAR Workbench working on a STM32L475.
When I try to use pointers it does not work, probably a stupid no brainer of a beginners mistake, but I appreciate some help to solve this.
I am using a union like this (I know I am wasting mem but for the test it is like this):
//Production Data union
union Production_Data_union
{
struct
{
uint8_t Dummy_Array[3];
char Xxxx_Sn[16];
char Yyyy_Sn[16];
char Prod_Date[8];
char Firmware_Ver[8];
};
uint8_t Eeprom_Page0_Buffer[67];
};
union Production_Data_union Prod_Data;
uint8_t *Eeprom_Page0_Ptr;
uint8_t Read_Cmd[3] = {0x03, 0x00, 0x00};
uint8_t Buff[67];
uint8_t Eeprom_Page_Size = 64;
void Eeprom_Page_Read(uint8_t *Data, uint8_t Page_No);
My Main looks like this:
Eeprom_Page0_Ptr = (uint8_t*)&Prod_Data.Eeprom_Page0_Buffer;
Eeprom_Page_Read(Eeprom_Page0_Ptr, 0);
The Eeprom_Page_Read function:
void Eeprom_Page_Read(uint8_t *Data, uint8_t Page_No)
{
uint16_t Address;
Address = Page_No * Eeprom_Page_Size;
Read_Cmd[2] = Address & 0xFF;
Read_Cmd[1] = (Address >> 8) & 0xFF;
//Send READ command to Eeprom
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET);
if(HAL_SPI_TransmitReceive(&hspi3, (uint8_t*)Read_Cmd, (uint8_t *)&Data, (Eeprom_Page_Size +3), 5000) != HAL_OK)
{
Error_Handler();
}
printf("Prod_Data:\n - Xxxx SN %s\n - Yyyy SN %s\n - Prod date %s - Firmware %s\n - Cmd - %d - %d - %d\n",
Prod_Data.Xxxx_Sn,
Prod_Data.Yyyy_Sn,
Prod_Data.Prod_Date,
Prod_Data.Firmware_Ver,
Read_Cmd[0],
Read_Cmd[1],
Read_Cmd[2]);
//Wait for SPI transfer to complete
while (HAL_SPI_GetState(&hspi3) != HAL_SPI_STATE_READY)
{
}
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
Read_E2prom = 0;
}
I know the content of the Eeprom is ok and I can read it if I replace “&Data” with “Buff” (Array[67]) in the HAL_SPI_TransmitReceive(...) call.
Pointer value is the start address of the structure (0x20000090).
So addressing a.s.o. should be ok but the struct is empty when using a pointer.
I am mostly interested in why this does not work and a fix to this, not so much in comments like "why don't you do it like this instead, I want to learn what I have done wrong cause this approach, I believe, should work.
Please remember that I AM NEW at programming so please explain "for Dummies".
I am not sure why that is ?
The function HAL_SPI_TransmitReceive wants a pointer to know where to store the data it receives. It essentially wants an address of where to go place the bytes. In your case, according to line
void Eeprom_Page_Read(uint8_t *Data, uint8_t Page_No){...}
Data is already a pointer, because it's denoted with a *. This means that Datais a pointer pointing to some uint8_t number/array somewhere. That somewhere is where you want your SPI to write to.
When you added the & you basically gave the SPI the pointer to the pointer of where you want to write. So the SPI is writing the received data over the pointer, instead of at where the pointer points?
If that doesn't make sense then ask me again. It's a hard thing to explain.
Update:
This is as I understand it, not a pointer but an array?
The compiler only see's it as an pointer. In your case the pointer happen to point to an array, but it could have been to anywhere (almost) in memory. I implore you to rather think in terms of a pointer pointing to the first element of an array (*ptr==array[0]), and not in terms of an array.
Is it somehow implicit so the compiler knows what I want to do so it just accepts and compiles correctly?
I'm not sure if the compiler should compile successfully or not. But you should not rely on that. It's happens often where one could send pointers of pointers around (**ptr), so the compiler is just going to assume you know what you are doing. So you must take great care of how you work with your pointers.
Ok, after trying to solve this for a day or so, I finally found the mistake, it should not be &Data but just Data so it must look like this:
if(HAL_SPI_TransmitReceive(&hspi3, (uint8_t*)Read_Cmd, (uint8_t *)Data, (Eeprom_Page_Size +3), 5000) != HAL_OK)
{
/* Transfer error in transmission process */
Error_Handler();
}
I am not sure why that is ?

MYSQL UDF sockets

I've created a MySQL User defined function to open a unix domain type socket.
My problem is that if I call my function directly like so:
SELECT socketOpen("/path/to/file", "message");
It always executes in <10ms. So that is nice. But since I don't want to manually call this function everytime, I've created a stored procedure which does an insert into database and then calls this function.
The problem I'm facing is that the stored procedure usually takes <10ms, but somestimes takes over 1s. Even 5s. I don't understand how this happens. Is there a caching problem or something ?
Below is the code is use, stripped of error checking for clarity:
char *socketOpen(UDF_INIT *initid __attribute__((unused)),
UDF_ARGS *args, char *result, unsigned long *length,
char *is_null, char *error __attribute__((unused)))
{
int sockfd, portno, n, servlen;
struct sockaddr_un serv_addr;
struct hostent *server;
char socket_path[100];
char message[100];
memcpy(socket_path,args->args[0],args->lengths[0]);
socket_path[args->lengths[0]] = 0;
memcpy(message,args->args[1],args->lengths[1]);
message[args->lengths[1]] = 0;
sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sun_family = AF_UNIX;
strcpy(serv_addr.sun_path, args->args[0]);
servlen=strlen(serv_addr.sun_path) + sizeof(serv_addr.sun_family);
connect(sockfd,(struct sockaddr *) &serv_addr, servlen);
n = write(sockfd, message, strlen(message));
bzero(message,100);
n = read(sockfd, message, 100);
close(sockfd);
strcpy(result, message);
*length = strlen(message);
return result;
}
I would appreciate your insight into this problem. Thank you.
Since I've got no replies and I've fixed the problem I would like to share my solution to the problem.
The cause of the problem was quite different than I ancipated.
The machine of running the above code was Raspberry pi, which slowness I did not take into account. As it turns out most of the delay was caused by the UPDATE statement in the procedure. As soon as I changed the table ENGINE to MyISAM everything went smooth from then on.
Altough while testing the code there was sometimes still a slight delay. I've fixed that with making the socket non-blocking. That means that if something will go wrong the socket will never be opened, but I figure that is better than blocking indefinetely.

Connect to mysql in a c script?

I'm new to using the gwan server(link) and for that matter programming in c. I wanted to know what was the easiest way to use mysql in a c script for the gwan server?
I've experimented with dbi.c as used here and the project page can be found here, but also found that there is a c API for mysql itself which you can find here.
Anyone have experience using either or both? What are some of the pros/cons? Are there other libraries that make connecting to mysql easy for a noob like myself?
Any help appreciated.
Thanks!
[EDIT]
Also is libdbi thread safe? it appears to not be.
[EDIT 2]
It appears that the mysql lib itself is the easy way to go unless you think might be switching database types later as libdbi appears to be able to have different drivers which is nice for abstraction.
Relating to GWAN for me if i had any "mysql code" in the main function of a handler it appeared to be unsafe and caused random errors intermittently, but if i put the "mysql code" in the init function and put any data i need in a kv store accessed off of one of the global pointers the random errors went away completely. (I was using libdbi i assume it would be the same for the mysql api)
Hope this helps
I always prefer using the native c api...
#pragma link "/usr/lib/libmysqlclient.so"
#include "gwan.h"
#include <mysql/mysql.h>
int
main (int argc, char **argv)
{
MYSQL_RES *result;
MYSQL_ROW row;
MYSQL conn, *conn_h;
conn_h = mysql_init (&conn);
if (!conn_h)
{
return 200;
}
if (!mysql_real_connect (conn_h, "localhost", ctx->usr, ctx->psw, NULL, 0, NULL, 0))
{
mysql_close (conn_h);
return 200;
}
mysql_select_db (conn_h, "");
char *query = "";
if (mysql_query (conn_h, query))
{
mysql_close (conn_h);
return 200;
}
result = mysql_store_result (conn_h);
if (!result)
{
mysql_close (conn_h);
return 200;
}
if (mysql_num_rows (result) == 0)
{
return 200;
}
while ((row = mysql_fetch_row (result)))
{
/* do something with row[i] */
}
mysql_free_result (result);
mysql_close (conn_h);
return 200; // Ok
}
Keep in mind you need to initialize the mysql library if you plan to spawn threads (this code is not thread safe).
Hope this help you someway.

Segfault Copy Constructor

My code is as follows:
void Scene::copy(Scene const & source)
{
maxnum=source.maxnum;
imagelist = new Image*[maxnum];
for(int i=0; i<maxnum; i++)
{
if(source.imagelist[i] != NULL)
{
imagelist[i] = new Image;
imagelist[i]->xcoord = source.imagelist[i]->xcoord;
imagelist[i]->ycoord = source.imagelist[i]->ycoord;
(*imagelist[i])=(*source.imagelist[i]);
}
else
{
imagelist[i] = NULL;
}
}
}
A little background: The Scene class has a private int called maxnum and an dynamically allocated Array of Image pointers upon construction. These pointers point to images. The copy constructor attempts to make a deep copy of all of the images in the array. Somehow I'm getting a Segfault, but I don't see how I would be accessing an array out of bounds.
Anyone see something wrong?
I'm new to C++, so its probably something obvious.
Thanks,
I would suggest that maxnum (and maybe imagelist) become a private data member and implement const getMaxnum() and setMaxnum() methods. But I doubt that is the cause of any segfault the way you described this.
I would try removing that const before your reference and implement const public methods to extract data. It probably compiles since it is just a reference. Also, I would try switching to a pointer instead of pass by reference.
Alternatively, you can create a separate Scene class object and pass the Image type data as an array pointer. And I don't think you can declare Image *imagelist[value];.
void Scene::copy(Image *sourceimagelist, int sourcemaxnum) {
maxnum=sourcemaxnum;
imagelist=new Image[maxnum];
//...
imagelist[i].xcoord = sourceimagelist[i].xcoord;
imagelist[i].ycoord = sourceimagelist[i].ycoord;
//...
}
//...
Scene a,b;
//...
b.Copy(a.imagelist,a.maxnum);
If the source Image had maxnum set higher than the actual number of items in its imagelist, then the loop would run past the end of the source.imagelist array. Maybe maxnum is getting initialized to the value one while the array starts out empty (or maxnum might not be getting initalized at all), or maybe if you have a Scene::remove_image() function, it might have removed an imagelist entry without decrementing maxnum. I'd suggest using an std::vector rather than a raw array. The vector will keep track of its own size, so your for loop would be:
for(int i=0; i<source.imagelist.size(); i++)
and it would only access as many items as the source vector held. Another possible explanation for the crash is that one of your pointers in source.imagelist belongs to an Image that was deleted, but the pointer was never set to NULL and is now a dangling pointer.
delete source.imagelist[4];
...
... // If source.imagelist[4] wasn't set to NULL or removed from the array,
... // then we'll have trouble later.
...
for(int i=0; i<maxnum; i++)
{
if (source.imagelist[i] != NULL) // This evaluates to true even when i == 4
{
// When i == 4, we're reading the xcoord member from an Image
// object that no longer exists.
imagelist[i]->xcoord = source.imagelist[i]->xcoord;
That last line will access memory that it shouldn't. Maybe the object still happens to exist in memory because it hasn't gotten overwritten yet, or maybe it has been overwritten and you'll retrieve an invalid xcoord value. If you're lucky, though, then your program will simply crash. If you're dealing directly with new and delete, make sure that you set a pointer to NULL after you delete it so that you don't have a dangling pointer. That doesn't prevent this problem if you're holding a copy of the pointer somewhere, though, in which case the second copy isn't going to get set to NULL when you delete-and-NULL the first copy. If you later try to access the second copy of the pointer, you'll have no way of knowing that it's no longer pointing to a valid object.
It's much safer to use a smart pointer class and let that deal with memory management for you. There's a smart pointer in the standard C++ library called std::auto_ptr, but it has strange semantics and can't be used in C++ containers, such as std::vector. If you have the Boost libraries installed, though, then I'd suggest replacing your raw pointers with a boost::shared_ptr.