C++ Amp GPU Data is'nt free after deleting the Data of pointer array GPU (dynamic allocation) - c++-amp

#include "stdafx.h"
#include <amp.h>
#include <assert.h>
#include <iostream>
#include <vector>
#include <iostream>
#include <ppl.h>
#include<stdio.h>
#include<conio.h>
using namespace ::Concurrency;
using std::vector;
static array<double, 1> *P_GPU;
int _tmain(int argc, _TCHAR* argv[])
{
accelerator default_device(accelerator::default_accelerator);
accelerator_view acc_v = default_device.default_view;
int N = 4*4096*4096;
double *xdata = new double[N];
memset(xdata,0,N);
extent<1> e_b(N);
P_GPU = new array<double, 1>(e_b, acc_v); // dynamic allocation of array
array<double, 1> bb(e_b, xdata, acc_v);
array_view<double, 1> dest(*P_GPU);
dest.discard_data();
parallel_for_each(dest.extent, [=,&bb](index<1> idx) restrict(amp)
{
dest[idx]=bb[idx];
});
dest.synchronize();
std::cout << "before delete .." << std::endl;
std::cin.get();
delete [] xdata; // the DATA of xdata pointer is deleted ..
delete P_GPU; // the DATA GPU of P_GPU is not deleted ???
std::cout << "Hit any key to exit..." << std::endl;
std::cin.get();
return 0;
}
The binary Code was tested by Microsoft Process Explorer v16.04.
I tested a problem of dynamic allocation of array (or array_view) in C++ AMP..
I see The GPU memory was not free after deleting the P_GPU pointer !!
This program was tested on Matlab ... (mexFunction)-> I have the same problem... ..
delete P_GPU;
I need to make a dynamic allocation (GPU C++AMP) of matrix in matlab.
I find the trick but i have complication when I do a deallocation
(delete) matrix in GPU memory ....
????
deallocate GPU memory ...

I just solved this problem following: Using pointers in C++Amp
please use: std::shared_ptr<>
class FrameProcessorAmpBase
{
private:
std::shared_ptr<array<float, 2> m_frame;
public:
FrameProcessorAmpBase()
{
}
void ConfigureFrameBuffers(int width, int height)
{
m_frame = std::make_shared<array<float, 2>>(height, width));
}

Related

why setuid fails after capset is used?

trying to figure out the linux capabilities interface, i came across with an unexpected issue (for me at least). When seting the capabilities of a process with the capset syscall the kernel rejects a change of userid with the setuid syscall. Does anybody know why setuid fails?
This is code i wrote to test this behavior:
#undef _POSIX_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/capability.h>
#include <sys/capability.h>
#include <string.h>
int main(int argc, char** argv){
struct __user_cap_header_struct cap_header;
struct __user_cap_data_struct cap_data;
int cap_res;
FILE *file;
int sockfd;
cap_header.pid = getpid();
cap_header.version = _LINUX_CAPABILITY_VERSION_1;
__u32 cap_mask = 0;
cap_mask |= (1 << CAP_DAC_OVERRIDE);
cap_mask |= (1 << CAP_SETUID);
printf("You selected mask: %x\n", cap_mask);
cap_data.effective = cap_mask;
cap_data.permitted = cap_mask;
cap_data.inheritable = cap_mask;
cap_res = capset(&cap_header, &cap_data);
if(cap_res < 0){
printf("Trying to apply mask: FAIL\n", cap_mask);
} else {
printf("Capability set correctly\n");
}
int uid = atol(argv[1]);
int setuid_res = setuid(uid);
if (setuid_res == -1){
printf("7w7\n");
} else {
printf("UID set correctly\n");
}
}
compiled with:
$ gcc -g test1.c -o test1
Output is (for user id: 1000)
$ # ./test1 1000
You selected mask: 2
Capability set correctly
7w7
I think you might be missing a couple of steps in your question:
How do you give the binary some privilege?
It looks like you are trying to use cap_dac_override to achieve what cap_setuid is intended for.
Rewriting the program as follows:
#undef _POSIX_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/capability.h>
#include <sys/capability.h>
#include <string.h>
int main(int argc, char** argv){
struct __user_cap_header_struct cap_header;
struct __user_cap_data_struct cap_data;
int cap_res;
// need to start from known data. C does not guarantee these are
// zero filled by default. You could declare them static to get
// that.
memset(&cap_header, 0, sizeof(cap_header));
memset(&cap_data, 0, sizeof(cap_data));
cap_header.pid = getpid();
cap_header.version = _LINUX_CAPABILITY_VERSION_1;
__u32 cap_mask = 0;
cap_mask |= (1 << CAP_SETUID);
printf("You selected mask: %x\n", cap_mask);
cap_data.effective = cap_mask;
cap_data.permitted = cap_mask;
// not needed: cap_data.inheritable = cap_mask;
cap_res = capset(&cap_header, &cap_data);
if(cap_res < 0){
printf("Trying to apply mask: FAIL\n", cap_mask);
exit(1);
} else {
printf("Capability set correctly\n");
}
if (argc != 2) {
printf("usage: %s <uid>\n", argv[0]);
exit(1);
}
int uid = atol(argv[1]);
int setuid_res = setuid(uid);
if (setuid_res == -1){
printf("7w7\n");
} else {
printf("UID set correctly to %d\n", uid);
}
}
You can run the program like this:
$ sudo ./test1 1000
You selected mask: 80
Capability set correctly
UID set correctly to 1000
Or, using a file capability:
$ sudo setcap cap_setuid=p ./test1
$ ./test1 1000
You selected mask: 80
Capability set correctly
UID set correctly to 1000
This will work if you want to use the first 32 capabilities. However, there are ~40 of them under Linux at present, so I'd suggest you look into using the libcap API instead which figures out all of the kernel ABI details for you.

Behavior of select() on stdin when used on a pipe

I am trying to understand an observation on behavior of select() when used on stdin, when it is receiving data from a pipe.
Basically I had a simple C program using the following code:
hello.c:
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <signal.h>
#include <termios.h>
int main(int argc, char *argv[])
{
int flags, opt;
int nsecs, tfnd;
fd_set rfds;
struct timeval tv;
int retval;
int stdin_fileno_p1 = STDIN_FILENO+1;
char c;
int n;
/* Turn off canonical processing on stdin*/
static struct termios oldt, newt;
tcgetattr( STDIN_FILENO, &oldt);
newt = oldt;
newt.c_lflag &= ~(ICANON);
tcsetattr( STDIN_FILENO, TCSANOW, &newt);
while (1)
{
FD_ZERO(&rfds);
FD_SET(STDIN_FILENO, &rfds);
tv.tv_sec = 0;
tv.tv_usec = 0;
retval = select(stdin_fileno_p1, &rfds, NULL, NULL, &tv);
if ( retval && (retval!=-1) )
{
n = read(STDIN_FILENO, &c, 1);
write(STDOUT_FILENO, &c, 1);
}
else printf("No Data\n");
usleep(100000);
}
tcsetattr( STDIN_FILENO, TCSANOW, &oldt);
}
If I ran the program as follows I could see characters echoing when I type keys on while the program is running. When keys are not pressed, it displays "No Data" as expected.
./hello
However, if use the program as follows, the program never gets to a state where is displays "No Data". Instead last character "c" is repeatedly displayed.
echo -n abc | ./hello
I'm a bit puzzled by this observation, and would be grateful if you could help me to understand the observed behavior.
The problem is that your program does not detect an end-of-file condition when it reads from the STDIN_FILENO descriptor. After echo has written the c character it will close its end of the pipe, which will cause the select in your program to return immediately and your read to return 0 as an indication that no more data will ever be available from that descriptor. Your program doesn't detect that condition. Instead it just calls write with whatever character was left in the buffer by the last successful read and then repeats the loop.
To fix, do if (n==0) break; after the read.

CodeBlocks throwing exception c0000005 APPCRASH on C++ code

Hello everyone first question here, but I get a lot of help from reading your responses now I have an issue that is getting the best of me.
I have a simple program:
#include <iostream>
#include <ctime>
#include <stdlib.h>
#include "room.h"
#include "area1.h"
using namespace std;
void game_engine();
int main()
{
game_engine();
cout << "The end" << endl;
return 0;
}
void game_engine()
{
area1 nw;
nw.welcome();
};
I also have an ADT base class called room and a child class called area1.
#include <iostream>
#include <ctime>
#include <stdlib.h>
#include "room.h"
#include "area1.h"
using namespace std;
area1::area1()
{
this->description = "You are now in the North-West corner of the island. You have water to the North and the West, and this area is hard to navigate because of all the vegetation. I hope you find something that you need. ";
this->name = "NORTHWEST";
this->odds = 25;
this->random = 100;
this->visited = false;
}
void area1::welcome()
{
cout << name << endl;
cout << description << endl;
}
void area1::treasure()
{
}
void area1::navigate()
{
}
area1::~area1()
{
delete north;
delete east;
delete west;
delete south;
}
What I don't understand is why it is crashing when all I am doing is calling a simple function from main, that calls a function in my area1 class. No parameters are passed and the output is correct in the console for the function calls, but it crashes before it returns to main to call output "the end" . I have done similar stuff without error quite often so this one is driving me nuts. Any help is appreciated.

Single inotify read makes infinite loop

As of title.
The program will wait for the first event, and then go into an infinite loop - why doesn't it just process one event at a time?
#include <stdio.h>
#include <stdlib.h>
#include <sys/inotify.h>
#include <unistd.h>
int main (int argc, char **argv)
{
int id, wd;
int a;
struct inotify_event e;
id = inotify_init ();
wd = inotify_add_watch (id, "/home/andrea/Downloads", IN_CREATE);
puts ("waiting...");
while (read (id, &e, sizeof (struct inotify_event)))
{
printf ("created %s\n", e.name);
puts ("waiting...");
}
return 0;
}
Firstly, the events reported by inotify aren't of the size inotify_event, since there is an additional name reported as well. Use ioctl with FIONREAD to get the amount of bytes available for reading.
int avail;
ioctl(id, FIONREAD, &avail);
Secondly, you used blocking I/O. If you instead use inotify_init1(O_NONBLOCK) to initialise inotify, read() will immediately return and set errno to EAGAIN if no data is available. Of course, this is optional if you first used FIONREAD to check if there is data available in the first place.

a program that allocates huge chunks of memory using mmap(say 1GB) [duplicate]

I am writing a program that allocates huge chunks of memory using mmap and then accesses random memory locations to read and write into it.
I just tried out the following code:
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
int main() {
int fd,len=1024*1024;
fd=open("hello",O_READ);
char*addr=mmap(0,len,PROT_READ+PROT_WRITE,MAP_SHARED,fd,0);
for(fd=0;fd<len;fd++)
putchar(addr[fd]);
if (addr==MAP_FAILED) {perror("mmap"); exit(1);}
printf("mmap returned %p, which seems readable and writable\n",addr);
munmap(addr,len);
return 0;
}
But I cannot execute this program, is there anything wrong with my code?
First of all, the code won't even compile on my debian box. O_READ isn't a correct flag for open() as far as I know.
Then, you first use fd as a file descriptor and the you use it as a counter in your for loop.
I don't understand what you're trying to do, but I think you misunderstood something about mmap.
mmap is used to map a file into the memory, this way you can read / write to the created memory mapping instead of using functions to access the file.
Here's a short program that open a file, map it the the memory and print the returner pointer :
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main() {
int fd;
int result;
int len = 1024 * 1024;
fd = open("hello",O_RDWR | O_CREAT | O_TRUNC, (mode_t) 0600);
// stretch the file to the wanted length, writting something at the end is mandatory
result = lseek(fd, len - 1, SEEK_SET);
if(result == -1) { perror("lseek"); exit(1); }
result = write(fd, "", 1);
if(result == -1) { perror("write"); exit(1); }
char*addr = mmap(0, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (addr==MAP_FAILED) { perror("mmap"); exit(1); }
printf("mmap returned %p, which seems readable and writable\n",addr);
result = munmap(addr, len);
if (result == -1) { perror("munmap"); exit(1); }
close(fd);
return 0;
}
I left out the for loop, since I didn't understood its purpose. Since you create a file and you want to map it on a given length, we have to "stretch" the file to the given length too.
Hope this helps.