1

I am doing a function that reads a line from a file. Inside this function I use the function read (man 2 read) and the number of bytes from the read function is set by the user. This function is a exercise from my school. The prototype is something like this

get_next_line(int fd, char **line);

And the read function I´m using this way:

read(fd, buf, BUFFER_SIZE)

To compile this program the user should use the flag -D BUFFER_SIZE=xx. The BUFFER_SIZE is a macro to define the nbytes from the read function.

I have no issues about how to do this exercise. My main problem is to understand how many bytes does a read function can handle.

I have noticed that if I input 10000000 in my BUFFER_SIZE I get a segmentation fault, and using the sanitize flag it brings me this error:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==84594==ERROR: AddressSanitizer: stack-overflow on address 0x7ffee85a0f20 (pc 0x000106cd68f7 bp 0x7ffee8f2a710 sp 0x7ffee85a0e40 T0)
    #0 0x106cd68f6 in ft_readfile (a.out:x86_64+0x1000018f6)
    #1 0x106cd6fba in get_next_line (a.out:x86_64+0x100001fba)
    #2 0x106cd7a7a in main (a.out:x86_64+0x100002a7a)
    #3 0x7fff652af3d4 in start (libdyld.dylib:x86_64+0x163d4)

SUMMARY: AddressSanitizer: stack-overflow (a.out:x86_64+0x1000018f6) in ft_readfile
==84594==ABORTING
[1]    84594 abort      ./a.out

The ft_readfile is where I use the read function. I have tried to find this info but i couldn´t find anywhere.

Is there a max size of bytes that the read function can read? If so, how many bytes can it handle and why does it have this limit?

EDIT

Those are the information asked:

The buf is defined like this:

char        buf[BUFFER_SIZE + 1];

The function that it reads the file is like this:

int         ft_readfile(int fd, t_list *lst)
{
    int         res;
    char        buf[BUFFER_SIZE + 1];
    char        *tmp;

    tmp = lst->content;
    if (lst->content == NULL)
        lst->content = ft_strdup("");
    else
        lst->content = ft_substr(lst->content, ft_strlen_char(lst->content,
                    '\n') + 1, ft_strlen_char(lst->content, '\0'));
    free(tmp);
    buf[0] = '\0';
    while (!(ft_haschr(buf, '\n')) && (res = read(fd, buf, BUFFER_SIZE)))
    {
        if (res == -1)
            return (-1);
        buf[res] = '\0';
        tmp = lst->content;
        lst->content = ft_strjoin(lst->content, buf);
        free(tmp);
    }
    return (res);
}
  • 2
    How is `buf` defined? – Fiddling Bits Feb 17 '20 at 14:08
  • You need to show more code. Read this: [ask] and this: [mcve]. Please [edit] your question. – Jabberwocky Feb 17 '20 at 14:09
  • 1
    The error message tells you what the problem is: `stack-overflow`. Your stack is less than 10,000,000 bytes. Try defining `buf` to be global. – Fiddling Bits Feb 17 '20 at 14:10
  • Did you declare buf as a local variable? It seems your local variable's size is too big. – John Park Feb 17 '20 at 14:10
  • Does it work if you compile with `-D BUFFER_SIZE=5000`? – Jabberwocky Feb 17 '20 at 14:12
  • @Jabberwocky , yes it works with this size. – Wincenty Bertoni Lech Feb 17 '20 at 14:14
  • @FiddlingBits , I can´t use globals in this exercise. – Wincenty Bertoni Lech Feb 17 '20 at 14:16
  • @JohnPark , yes it´s a local variable. O can´t define globals in this exercise. – Wincenty Bertoni Lech Feb 17 '20 at 14:17
  • 2
    @WincentyBertoniLech: Can you use dynamic memory allocation, such as `malloc()` ? That way, you will be allocating memory on the heap instead of the stack, and you will not be getting a stack overflow. However, you should check the return value of `malloc()`, as that function can fail if you ask for too much memory. – Andreas Wenzel Feb 17 '20 at 14:17
  • Better duplicate: https://stackoverflow.com/questions/571945/getting-a-stack-overflow-exception-when-declaring-a-large-array – Jabberwocky Feb 17 '20 at 14:17
  • @Jabberwocky , tkz that question was indeed the answer. When i use a calloc it fixed the problem. Didn´t realize that the issue was in the memory allocation of buf. – Wincenty Bertoni Lech Feb 17 '20 at 14:35
  • @WincentyBertoniLech don't forget to free the memory abtained with `calloc`. BTw: afre you sure you need a buffer that big anyway? – Jabberwocky Feb 17 '20 at 14:55
  • 1
    @Jabberwocky, I will free, tkz for the tip. The size it´s because of the exercise. It says to input very big numbers. It´s good because now I know that if the input it´s a huge number I will have to use malloc or calloc instead of buf[something]. – Wincenty Bertoni Lech Feb 17 '20 at 15:12
  • 2
    Is puting 9 space between return type and function name an specific coding style? – EsmaeelE Feb 17 '20 at 17:03
  • Closed so can't answer, but look within stat(2) to use the definition of st_blksize. This provides the specific block size of a device, which is often BUFSIZ. BUFSIZ is what the implementation considers proper and st_blksize the actual device. . http://man7.org/linux/man-pages/man2/stat.2.html – Gilbert Feb 18 '20 at 00:54

0 Answers0