Search Results

Search found 3136 results on 126 pages for 'buffer overrun'.

Page 2/126 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Switching to some emacs shell buffers moves the cursor to the beginning of the buffer

    - by yuvilio
    I run Emacs 24 with prelude and a few shells that i invoke at the start ( e.g.: (shell "*shell*_spare") ). When i switch to some of them (C-x b), my cursor lands at the beginning of the buffer, rather than when it last left off (typically the end of the buffer after the last command I ran). The strange thing is that this does not happen for all the shell buffers that I set up in the same way but with different names. When I switch to them, the cursor is where it last left off. Any ideas how I can make the cursor always be where it last was or at the bottom?

    Read the article

  • Illustration of buffer overflows for students (linux, C)

    - by osgx
    Hello My friend is teacher of first-year CS students. We want to show them buffer overflow exploitation. But modern distribs are protected from simples buffer overflows: HOME=`perl -e "print 'A'x269"` one_widely_used_utility_is_here --help on debian (blame it) Caught signal 11, on modern commercial redhat *** buffer overflow detected ***: /usr/bin/one_widely_used_utility_is_here terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xc321c1] /lib/libc.so.6(__strcpy_chk+0x43)[0xc315e3] /usr/bin/one_widely_used_utility_is_here[0x805xxxc] /usr/bin/one_widely_used_utility_is_here[0x804xxxc] /lib/libc.so.6(__libc_start_main+0xdc)[0xb61e9c] /usr/bin/one_widely_used_utility_is_here[0x804xxx1] ======= Memory map: ======== 00336000-00341000 r-xp 00000000 08:02 2751047 /lib/libgcc_s-4.1.2-20080825.so.1 00341000-00342000 rwxp 0000a000 08:02 2751047 /lib/libgcc_s-4.1.2-20080825.so.1 008f3000-008f4000 r-xp 008f3000 00:00 0 [vdso] The same detector fails for more synthetic examples from the internet. How can we demonstrate buffer overflow with modern non-GPL distribs (there is no debian in classes) How can we DISABLE canary word checking in stack ? DISABLE checking variants of strcpy/strcat ? write an example (in plain C) with working buffer overrun ?

    Read the article

  • How to prevent buffer overflow in C/C++?

    - by alexpov
    Hello, i am using the following code to redirect stdout to a pipe, then read all the data from the pipe to a buffer. I have 2 problems: first problem: when i send a string (after redirection) bigger then the pipe's BUFF_SIZE, the program stops responding (deadlock or something). second problem: when i try to read from a pipe before something was sent to stdout. I get the same response, the program stops responding - _read command stuck's ... The issue is that i don't know the amount of data that will be sent to the pipe after the redirection. The first problem, i don't know how to handle and i'll be glad for help. The second problem i solved by a simple workaround, right after the redirection i print space character to stdout. but i guess that this solution is not the correct one ... #include <fcntl.h> #include <io.h> #include <iostream> #define READ 0 #define WRITE 1 #define BUFF_SIZE 5 using namespace std; int main() { int stdout_pipe[2]; int saved_stdout; saved_stdout = _dup(_fileno(stdout)); // save stdout if(_pipe(stdout_pipe,BUFF_SIZE, O_TEXT) != 0 ) // make a pipe { exit(1); } fflush( stdout ); if(_dup2(stdout_pipe[1], _fileno(stdout)) != 0 ) //redirect stdout to the pipe { exit(1); } ios::sync_with_stdio(); setvbuf( stdout, NULL, _IONBF, 0 ); //anything sent to stdout goes now to the pipe //printf(" ");//workaround for the second problem printf("123456");//first problem char buffer[BUFF_SIZE] = {0}; int nOutRead = 0; nOutRead = _read(stdout_pipe[READ], buffer, BUFF_SIZE); //second problem buffer[nOutRead] = '\0'; // reconnect stdout if (_dup2(saved_stdout, _fileno(stdout)) != 0 ) { exit(1); } ios::sync_with_stdio(); printf("buffer: %s\n", buffer); } Thanks, Alex

    Read the article

  • BitBlting multiple images to buffer

    - by Anonymous
    So I've made a class which draws a transparant image to a buffer. the buffer is a HDC which has been used blackness on. What I am trying to do is draw three images to this buffer. Which means I am using this function three times. After that's done, I output it to the screen (using SRCCOPYing the buffer). But what I get to see is just the third image and blackness. void draw_buffer(HDC buffer, int draw_x, int draw_y) { BitBlt(this-main, draw_x, draw_y, this-img_width, this-img_height, this-image, this-mask_x, this-mask_y, SRCAND); BitBlt(this-main, draw_x, draw_y, this-img_width, this-img_height, this-image, this-img_x, this-img_y, SRCPAINT); BitBlt(buffer, 0, 0, 800, 600, this-main, 0, 0, SRCCOPY); } At initiation, this-main becomes this: this->main = CreateCompatibleDC(GetDC(0)); this->bitmap = CreateCompatibleBitmap(GetDC(0),800,600); SelectObject(this->main, this->bitmap); What is wrong with my code?

    Read the article

  • who free's setvbuf buffer?

    - by Evan Teran
    So I've been digging into how the stdio portion of libc is implemented and I've come across another question. Looking at man setvbuf I see the following: When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained. This makes sense, your program should have a malloc in it for I/O unless you actually use it. My gut reaction to this is that libc will clean up its own mess here. Which I can only assume it does because valgrind reports no memory leaks (they could of course do something dirty and not allocate it via malloc directly... but we'll assume that it literally uses malloc for now). But, you can specify your own buffer too... int main() { char *p = malloc(100); setvbuf(stdio, p, _IOFBF, 100); puts("hello world"); } Oh no, memory leak! valgrind confirms it. So it seems that whenever stdio allocates a buffer on its own, it will get deleted automatically (at the latest on program exit, but perhaps on stream close). But if you specify the buffer explicitly, then you must clean it up yourself. There is a catch though. The man page also says this: You must make sure that the space that buf points to still exists by the time stream is closed, which also happens at program termination. For example, the following is invalid: Now this is getting interesting for the standard streams. How would one properly clean up a manually allocated buffer for them, since they are closed in program termination? I could imagine a "clean this up when I close flag" inside the file struct, but it get hairy because if I read this right doing something like this: setvbuf(stdio, 0, _IOFBF, 100); printf("hello "); setvbuf(stdio, 0, _IOLBF, 100); printf("world\n"); would cause 2 allocations by the standard library because of this sentence: If the argument buf is NULL, only the mode is affected; a new buffer will be allocated on the next read or write operation.

    Read the article

  • [ebp + 6] instead of +8 in a JIT compiler

    - by David Titarenco
    I'm implementing a simplistic JIT compiler in a VM I'm writing for fun (mostly to learn more about language design) and I'm getting some weird behavior, maybe someone can tell me why. First I define a JIT "prototype" both for C and C++: #ifdef __cplusplus typedef void* (*_JIT_METHOD) (...); #else typedef (*_JIT_METHOD) (); #endif I have a compile() function that will compile stuff into ASM and stick it somewhere in memory: void* compile (void* something) { // grab some memory unsigned char* buffer = (unsigned char*) malloc (1024); // xor eax, eax // inc eax // inc eax // inc eax // ret -> eax should be 3 /* WORKS! buffer[0] = 0x67; buffer[1] = 0x31; buffer[2] = 0xC0; buffer[3] = 0x67; buffer[4] = 0x40; buffer[5] = 0x67; buffer[6] = 0x40; buffer[7] = 0x67; buffer[8] = 0x40; buffer[9] = 0xC3; */ // xor eax, eax // mov eax, 9 // ret 4 -> eax should be 9 /* WORKS! buffer[0] = 0x67; buffer[1] = 0x31; buffer[2] = 0xC0; buffer[3] = 0x67; buffer[4] = 0xB8; buffer[5] = 0x09; buffer[6] = 0x00; buffer[7] = 0x00; buffer[8] = 0x00; buffer[9] = 0xC3; */ // push ebp // mov ebp, esp // mov eax, [ebp + 6] ; wtf? shouldn't this be [ebp + 8]!? // mov esp, ebp // pop ebp // ret -> eax should be the first value sent to the function /* WORKS! */ buffer[0] = 0x66; buffer[1] = 0x55; buffer[2] = 0x66; buffer[3] = 0x89; buffer[4] = 0xE5; buffer[5] = 0x66; buffer[6] = 0x66; buffer[7] = 0x8B; buffer[8] = 0x45; buffer[9] = 0x06; buffer[10] = 0x66; buffer[11] = 0x89; buffer[12] = 0xEC; buffer[13] = 0x66; buffer[14] = 0x5D; buffer[15] = 0xC3; // mov eax, 5 // add eax, ecx // ret -> eax should be 50 /* WORKS! buffer[0] = 0x67; buffer[1] = 0xB8; buffer[2] = 0x05; buffer[3] = 0x00; buffer[4] = 0x00; buffer[5] = 0x00; buffer[6] = 0x66; buffer[7] = 0x01; buffer[8] = 0xC8; buffer[9] = 0xC3; */ return buffer; } And finally I have the main chunk of the program: void main (int argc, char **args) { DWORD oldProtect = (DWORD) NULL; int i = 667, j = 1, k = 5, l = 0; // generate some arbitrary function _JIT_METHOD someFunc = (_JIT_METHOD) compile(NULL); // windows only #if defined _WIN64 || defined _WIN32 // set memory permissions and flush CPU code cache VirtualProtect(someFunc,1024,PAGE_EXECUTE_READWRITE, &oldProtect); FlushInstructionCache(GetCurrentProcess(), someFunc, 1024); #endif // this asm just for some debugging/testing purposes __asm mov ecx, i // run compiled function (from wherever *someFunc is pointing to) l = (int)someFunc(i, k); // did it work? printf("result: %d", l); free (someFunc); _getch(); } As you can see, the compile() function has a couple of tests I ran to make sure I get expected results, and pretty much everything works but I have a question... On most tutorials or documentation resources, to get the first value of a function passed (in the case of ints) you do [ebp+8], the second [ebp+12] and so forth. For some reason, I have to do [ebp+6] then [ebp+10] and so forth. Could anyone tell me why?

    Read the article

  • Usage of current-buffer in emacs?

    - by Zubair
    I'm using emacs and I have written a script which uses "current-buffer". However the emacs system doesn't recognise "current-buffer". When I try "M - x current-buffer" i get the response: no match : Any idea what I'm doing wrong?

    Read the article

  • function's return address is different from its supposed value, buffer overflow,

    - by ultrajohn
    Good day everyone! I’m trying to understand how buffer overflow works. I’m doing this for my project in a computer security course I’m taking. Right now, I’m in the process of determining the address of the function’s return address which I’m supposed to change to perform a buffer overflow attack. I’ve written a simple program based from an example I’ve read in the internet. What this program does is it creates an integer pointer that will be made to point to the address of the function return address in the stack. To do this, (granted I understand how a function/program variables get organized in the stack), I add 8 to the buffer variable’ address and set it as the value of ret. I’m not doing anything here that would change the address contained in the location of func’s return address. here's the program: Output of the program when gets excecuted: As you can see, I’m printing the address of the variables buffer and ret. I’ve added an additional statement printing the value of the ret variable (supposed location of func return address, so this should print the address of the next instruction which will get executed after func returns from execution). Here is the dump which shows the supposed address of the instruction to be executed after func returns. (Underlined in green) As you can see, that value is way different from the value printed contained in the variable ret. My question is, why are they different? (of course in the assumption that what I’ve done are all right). Else, what have I done wrong? Is my understanding of the program’s runtime stack wrong? Please, help me understand this. My project is due nextweek and I’ve barely touched it yet. I’m sorry if I’m being demanding, I badly need your help.

    Read the article

  • Buffer management for socket application best practice

    - by Poni
    Having a Windows IOCP app............ I understand that for async i/o operation (on network) the buffer must remain valid for the duration of the send/read operation. So for each connection I have one buffer for the reading. For sending I use buffers to which I copy the data to be sent. When the sending operation completes I release the buffer so it can be reused. So far it's nice and not of a big issue. What remains unclear is how do you guys do this? Another thing is that even when having things this way, I mean multi-buffers, the receiver side might be flooded (talking from experience) with data. Even setting SO_RCVBUF to 25MB didn't help in my testings. So what should I do? Have a to-be-sent queue?

    Read the article

  • How much buffer does NetworkStream and TcpClient have?

    - by Earlz
    Hello, We are writing a TCPServer and Client program. How much space is there in the TcpClient buffer? Like, at what point will it begin to throw away data? We are trying to determine if the TcpClient can be blocking or if it should go into it's own background thread(so that the buffer can not get full)..

    Read the article

  • Buffer size: N*sizeof(type) or sizeof(var)? C++

    - by flyout
    I am just starting with cpp and I've been following different examples to learn from them, and I see that buffer size is set in different ways, for example: char buffer[255]; StringCchPrintf(buffer, sizeof(buffer), TEXT("%s"), X); VS char buffer[255]; StringCchPrintf(buffer, 255*sizeof(char), TEXT("%s"), X); Which one is the correct way to use it? I've seen this in other functions like InternetReadFile, ZeroMemory and MultiByteToWideChar.

    Read the article

  • C# File IO with Streams - Best Memory Buffer Size

    - by AJ
    Hi, I am writing a small IO library to assist with a larger (hobby) project. A part of this library performs various functions on a file, which is read / written via the FileStream object. On each StreamReader.Read(...) pass, I fire off an event which will be used in the main app to display progress information. The processing that goes on in the loop is vaired, but is not too time consuming (it could just be a simple file copy, for example, or may involve encryption...). My main question is: What is the best memory buffer size to use? Thinking about physical disk layouts, I could pick 2k, which would cover a CD sector size and is a nice multiple of a 512 byte hard disk sector. Higher up the abstraction tree, you could go for a larger buffer which could read an entire FAT cluster at a time. I realise with today's PC's, I could go for a more memory hungry option (a couple of MiB, for example), but then I increase the time between UI updates and the user perceives a less responsive app. As an aside, I'm eventually hoping to provide a similar interface to files hosted on FTP / HTTP servers (over a local network / fastish DSL). What would be the best memory buffer size for those (again, a "best-case" tradeoff between perceived responsiveness vs. performance). Thanks in advance for any ideas, Adam

    Read the article

  • Flush kernel's TCP buffer with `MSG_MORE`-flagged packets

    - by timn
    send()'s man page reveals the MSG_MORE flag which is asserted to act like TCP_CORK. I have a wrapper function around send(): int SocketConnection_Write(SocketConnection *this, void *buf, int len) { errno = 0; int sent = send(this->fd, buf, len, MSG_NOSIGNAL); if (errno == EPIPE || errno == ENOTCONN) { throw(exc, &SocketConnection_NotConnectedException); } else if (errno == ECONNRESET) { throw(exc, &SocketConnection_ConnectionResetException); } else if (sent != len) { throw(exc, &SocketConnection_LengthMismatchException); } return sent; } Assuming I want to use the kernel buffer, I could go with TCP_CORK, enable whenever it is necessary and then disable it to flush the buffer. But on the other hand, thereby the need for an additional system call arises. Thus, the usage of MSG_MORE seems more appropriate to me. I'd simply change the above send() line to: int sent = send(this->fd, buf, len, MSG_NOSIGNAL | MSG_MORE); According to lwm.net, packets will be flushed automatically if they are large enough: If an application sets that option on a socket, the kernel will not send out short packets. Instead, it will wait until enough data has shown up to fill a maximum-size packet, then send it. When TCP_CORK is turned off, any remaining data will go out on the wire. But this section only refers to TCP_CORK. Now, what is the proper way to flush MSG_MORE packets? I can only think of two possibilities: Call send() with an empty buffer and without MSG_MORE being set Re-apply the TCP_CORK option as described on this page Unfortunately the whole topic is very poorly documented and I couldn't find much on the Internet. I am also wondering how to check that everything works as expected? Obviously running the server through strace' is not an option. So the only simplest way would be to usenetcat' and then look at its `strace' output? Or will the kernel handle traffic differently transmitted over a loopback interface?

    Read the article

  • Android depth buffer issue: Advice for anyone experiencing problem

    - by Andrew Smith
    I've wasted around 30 hours this week writing and re-writing code, believing that I had misunderstood how the OpenGL depth buffer works. Everything I tried, failed. I have now resolved my problem by finding what may be an error in the Android implementation of OpenGL. See this API entry: http://www.opengl.org/sdk/docs/man/xhtml/glClearDepth.xml void glClearDepth(GLclampd depth); Specifies the depth value used when the depth buffer is cleared. The initial value is 1. Android's implementation has two versions of this command: glClearDepthx which takes an integer value, clamped 0-1 glClearDepthf which takes a floating point value, clamped 0-1 If you use glClearDepthf(1) then you get the results you would expect. If you use glClearDepthx(1), as I was doing then you get different results. (Note that 1 is the default value, but calling the command with the argument 1 produces different results than not calling it at all.) Quite what is happening I do not know, but the depth buffer was being cleared to a value different from what I had specified.

    Read the article

  • File IO with Streams - Best Memory Buffer Size

    - by AJ
    I am writing a small IO library to assist with a larger (hobby) project. A part of this library performs various functions on a file, which is read / written via the FileStream object. On each StreamReader.Read(...) pass, I fire off an event which will be used in the main app to display progress information. The processing that goes on in the loop is vaired, but is not too time consuming (it could just be a simple file copy, for example, or may involve encryption...). My main question is: What is the best memory buffer size to use? Thinking about physical disk layouts, I could pick 2k, which would cover a CD sector size and is a nice multiple of a 512 byte hard disk sector. Higher up the abstraction tree, you could go for a larger buffer which could read an entire FAT cluster at a time. I realise with today's PC's, I could go for a more memory hungry option (a couple of MiB, for example), but then I increase the time between UI updates and the user perceives a less responsive app. As an aside, I'm eventually hoping to provide a similar interface to files hosted on FTP / HTTP servers (over a local network / fastish DSL). What would be the best memory buffer size for those (again, a "best-case" tradeoff between perceived responsiveness vs. performance).

    Read the article

  • leak in fgets when assigning to buffer

    - by monkeyking
    I'm having problems understanding why following code leaks in one case, and not in the other case. The difference is while(NULL!=fgets(buffer,length,file))//doesnt leak while(NULL!=(buffer=fgets(buffer,length,file))//leaks I thought it would be the same. Full code below. #include <stdio.h> #include <stdlib.h> #define LENS 10000 void no_leak(const char* argv){ char *buffer = (char *) malloc(LENS); FILE *fp=fopen(argv,"r"); while(NULL!=fgets(buffer,LENS,fp)){ fprintf(stderr,"%s",buffer); } fclose(fp); fprintf(stderr,"%s\n",buffer); free(buffer); } void with_leak(const char* argv){ char *buffer = (char *) malloc(LENS); FILE *fp=fopen(argv,"r"); while(NULL!=(buffer=fgets(buffer,LENS,fp))){ fprintf(stderr,"%s",buffer); } fclose(fp); fprintf(stderr,"%s\n",buffer); free(buffer); }

    Read the article

  • Reading HttpURLConnection InputStream - manual buffer or BufferedInputStream?

    - by stormin986
    When reading the InputStream of an HttpURLConnection, is there any reason to use one of the following over the other? I've seen both used in examples. Manual Buffer: while ((length = inputStream.read(buffer)) > 0) { os.write(buf, 0, ret); } BufferedInputStream is = http.getInputStream(); bis = new BufferedInputStream(is); ByteArrayBuffer baf = new ByteArrayBuffer(50); int current = 0; while ((current = bis.read()) != -1) { baf.append(current); } EDIT I'm still new to HTTP in general but one consideration that comes to mind is that if I am using a persistent HTTP connection, I can't just read until the input stream is empty right? In that case, wouldn't I need to read the message length and just read the input stream for that length? And similarly, if NOT using a persistent connection, is the code I included 100% good to go in terms of reading the stream properly?

    Read the article

  • Reading HttpURLConnection InputStream - manual buffer or BufferedInputStream?

    - by stormin986
    When reading the InputStream of an HttpURLConnection, is there any reason to use one of the following over the other? I've seen both used in examples. Manual Buffer: while ((length = inputStream.read(buffer)) > 0) { os.write(buf, 0, ret); } BufferedInputStream is = http.getInputStream(); bis = new BufferedInputStream(is); ByteArrayBuffer baf = new ByteArrayBuffer(50); int current = 0; while ((current = bis.read()) != -1) { baf.append(current); } EDIT I'm still new to HTTP in general but one consideration that comes to mind is that if I am using a persistent HTTP connection, I can't just read until the input stream is empty right? In that case, wouldn't I need to read the message length and just read the input stream for that length? And similarly, if NOT using a persistent connection, is the code I included 100% good to go in terms of reading the stream properly?

    Read the article

  • How do I get the size of the boost buffer

    - by Anonymous
    I am trying to make an asynchronised server in visual studio and I use boost::asio::async_read(m_socket, boost::asio::buffer(m_buffer), boost::bind(&tcp_connection::handle_read, shared_from_this(), boost::asio::placeholders::error)); to get the buffer to be put in m_buffer boost::array<char, 256> m_buffer; but how do I get the size of this thing, m_buffer? size() didn't work, end() didn't work.. Any help would be fantastic. Thanks in advance.

    Read the article

  • [emacs] make ibuffer-visit-buffer behave like ido-switch-to-buffer?

    - by Stephen
    Is there a way to make ibuffer-visit-buffer behave like ido-switch-to-buffer (with raise-frame option)? If there is a window/frame containing the buffer I'd like emacs to take me there rather than opening the same buffer in the current window. I guess switch-to-buffer is remapped to ido-switch-to-buffer when ido-mode is turned on, so would doing something like that work in this case (remap ibuffer-visit-buffer to ido-switch-to-buffer)? Thanks

    Read the article

  • Problems with reading into buffer using boost::asio::async_read

    - by Max
    Good day. I have a Types.hpp file in my project. And within it i have: .... namespace RC { ..... ..... struct ViewSettings { .... }; ..... } In the Server.cpp file I'm including this Types.hpp file, and i have there: class Session { ..... RC::ViewSettings tmp; boost::asio::async_read(socket_, boost::asio::buffer(&tmp, sizeof(RC::ViewSettings)), boost::bind(&Session::Finish_Reading_Data, shared_from_this(), boost::asio::placeholders::error)); ..... } And during the compilation i have an errors: error C2825: 'F': must be a class or namespace when followed by '::' : see reference to class template instantiation 'boost::_bi::result_traits<R,F>' being compiled with [ R=boost::_bi::unspecified, F=void (__thiscall Session::* )(void) ] : see reference to class template instantiation 'boost::_bi::bind_t<R,F,L>' being compiled with [ R=boost::_bi::unspecified, F=void (__thiscall Session::* )(void), L=boost::_bi::list2<boost::_bi::value<boost::shared_ptr<Session>>,boost::arg<1>> ] error C2039: 'result_type' : is not a member of '`global namespace'' And the code like this works in proper way: int w; boost::asio::async_read(socket_, boost::asio::buffer(&w, sizeof(int)), boost::bind(&Session::Handle_Read_Width, shared_from_this(), boost::asio::placeholders::error)); Please, help. What's the problem here? Thanks in advance.

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >