Why Am I Getting Invalid Read of Size 1

#1

• 
• D.I.C Caput

Reputation: 5

• 

• Posts: 59
• Joined: 26-August 14

Valgrind report is a mess. Invalid read and write of size ane

Posted 02 Apr 2016 - 02:44 PM

hi, I am testing some regex functions for a larger programme I am working on. I take it working as I want. When I run valgrind on information technology the result is a mess. I take invalid read and write all over the identify. I plant a pocket-size regex library on github that allows perl mode regexes to be used in C. slre. My goal for the larger project is to read in an HTTP request make sure it is valid so split up up the request target and accented path and and then return them to the calling function.When I try to costless request_method and request_target I get a segfault but the http_version does non? Thank you for your help.

bool parse_request(const char* line) { 	const int HTTP_VERSION_CHAR_LENGTH = 3; //3 chars for the version number EX: 1.0, 1.1   	const char *GET_METHOD = "GET";  	//these are role of the slre lib used to shop the differnet 	//match fragemnets inside the regex 	const int NUM_OF_CAPS = iv; 	struct slre_cap caps[NUM_OF_CAPS]; 	 	// regex to friction match request  	if (slre_match("^\\s*(\\S+)\\s+(\\S+)\\s+HTTP/(\\d)\\.(\\d)", line, strlen(line), caps, NUM_OF_CAPS, 0) <= 0)  	{  		printf("400 Bad Request\northward"); 		return simulated;  	}  	  	//don't forget to free these  	char *request_method  = (char*)malloc(sizeof(char) * caps[0].len) +ane;  	char *request_target  = (char*)malloc(sizeof(char) * caps[1].len) + 1; 	char *http_version    = (char*)malloc(sizeof(char) * HTTP_VERSION_CHAR_LENGTH); 	char *absolute_path; 	char *query_string;  	 	for (int i = 0; i < caps[0].len; i++) 		request_method[i] = caps[0].ptr[i]; 	*request_method += '\0'; 	 	for (int i = 0; i < caps[ane].len; i++) 		request_target[i] = caps[1].ptr[i]; 	*request_target += '\0';  	for (int i = 0; i < HTTP_VERSION_CHAR_LENGTH; i++) 		http_version[i] = caps[ii].ptr[i]; 	*http_version += '\0';  	printf("%s\due north", request_target);  	absolute_path = strtok(request_target, "?"); 	query_string = strtok(Goose egg, "?"); 	 	printf("\n%s\northward", request_method); 	printf("%s\n", http_version); 	printf("%s\northward", absolute_path); 	printf("%s\northward", query_string);  	 	if (strcmp(request_method, GET_METHOD) != 0) 	{ 		printf("405 Method Not Immune"); 		return false; 	} 	//gratuitous(request_target); // 	gratuitous(request_method); 	free(http_version);  	return truthful; }            

valgrind --leak-check=full --track-origins=yes ./regex_tests

==8985== Memcheck, a memory fault detector ==8985== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8985== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8985== Command: ./regex_tests ==8985==  text/x-php ==8985== Invalid write of size 1 ==8985==    at 0x400EA5: parse_request (m_regex.c:60) ==8985==    past 0x400C2E: main (principal.c:33) ==8985==  Address 0x51d1043 is 0 bytes after a block of size three alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E4A: parse_request (m_regex.c:53) ==8985==    past 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid write of size 1 ==8985==    at 0x400EED: parse_request (m_regex.c:64) ==8985==    by 0x400C2E: chief (chief.c:33) ==8985==  Address 0x51d10a3 is 0 bytes after a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    past 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid read of size i ==8985==    at 0x4C2D524: strlen (vg_replace_strmem.c:412) ==8985==    by 0x4EA027B: puts (ioputs.c:36) ==8985==    past 0x400F5B: parse_request (m_regex.c:71) ==8985==    by 0x400C2E: master (principal.c:33) ==8985==  Address 0x51d10a3 is 0 bytes subsequently a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid read of size 1 ==8985==    at 0x4EA97EA: [email protected]@GLIBC_2.2.5 (fileops.c:1289) ==8985==    by 0x4EA031E: puts (ioputs.c:41) ==8985==    by 0x400F5B: parse_request (m_regex.c:71) ==8985==    by 0x400C2E: principal (primary.c:33) ==8985==  Address 0x51d10a3 is 0 bytes afterward a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (primary.c:33) ==8985==  ==8985== Invalid read of size 8 ==8985==    at 0x4EBA343: __GI_mempcpy (memcpy.South:123) ==8985==    by 0x4EA9739: [email protected]@GLIBC_2.ii.5 (fileops.c:1307) ==8985==    by 0x4EA031E: puts (ioputs.c:41) ==8985==    by 0x400F5B: parse_request (m_regex.c:71) ==8985==    past 0x400C2E: main (primary.c:33) ==8985==  Address 0x51d109c is 12 bytes within a cake of size xix alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: primary (main.c:33) ==8985==  /favicon.ico?q=gwen ==8985== Invalid read of size ane ==8985==    at 0x4EB9643: strtok (strtok.S:167) ==8985==    by 0x400F7F: parse_request (m_regex.c:74) ==8985==    by 0x400C2E: chief (chief.c:33) ==8985==  Address 0x51d10a3 is 0 bytes later a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    past 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid read of size 1 ==8985==    at 0x4EB964B: strtok (strtok.S:171) ==8985==    past 0x400F7F: parse_request (m_regex.c:74) ==8985==    by 0x400C2E: master (main.c:33) ==8985==  Address 0x51d10a4 is 1 bytes after a block of size nineteen alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    past 0x400E63: parse_request (m_regex.c:54) ==8985==    past 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid write of size 1 ==8985==    at 0x4EB9669: strtok (strtok.Due south:186) ==8985==    by 0x400F7F: parse_request (m_regex.c:74) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  Accost 0x51d10a4 is 1 bytes after a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (main.c:33) ==8985==   ==8985== Invalid read of size 1 ==8985==    at 0x4E7EADD: vfprintf (vfprintf.c:1642) ==8985==    by 0x4E84EB0: printf (printf.c:33) ==8985==    by 0x400F99: parse_request (m_regex.c:76) ==8985==    past 0x400C2E: main (main.c:33) ==8985==  Accost 0x51d1043 is 0 bytes after a block of size 3 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    past 0x400E4A: parse_request (m_regex.c:53) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid read of size 1 ==8985==    at 0x4EA97EA: [email protected]@GLIBC_2.two.five (fileops.c:1289) ==8985==    by 0x4E7EA9C: vfprintf (vfprintf.c:1642) ==8985==    by 0x4E84EB0: printf (printf.c:33) ==8985==    by 0x400F99: parse_request (m_regex.c:76) ==8985==    by 0x400C2E: principal (chief.c:33) ==8985==  Address 0x51d1043 is 0 bytes later on a block of size three alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E4A: parse_request (m_regex.c:53) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985== Invalid read of size 2 ==8985==    at 0x4EBA2FB: __GI_mempcpy (memcpy.South:83) ==8985==    by 0x4EA9739: [e-mail protected]@GLIBC_2.2.5 (fileops.c:1307) ==8985==    by 0x4E7EA9C: vfprintf (vfprintf.c:1642) ==8985==    by 0x4E84EB0: printf (printf.c:33) ==8985==    by 0x400F99: parse_request (m_regex.c:76) ==8985==    by 0x400C2E: primary (main.c:33) ==8985==  Accost 0x51d1042 is 2 bytes inside a block of size 3 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    past 0x400E4A: parse_request (m_regex.c:53) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  Go ==8985== Invalid read of size 1 ==8985==    at 0x4C2D524: strlen (vg_replace_strmem.c:412) ==8985==    by 0x4EA027B: puts (ioputs.c:36) ==8985==    by 0x400FA5: parse_request (m_regex.c:77) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  Address 0x51d10f3 is 0 bytes after a block of size 3 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    past 0x400E78: parse_request (m_regex.c:55) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  i.ane /favicon.ico ==8985== Invalid read of size ane ==8985==    at 0x4C2D524: strlen (vg_replace_strmem.c:412) ==8985==    past 0x4EA027B: puts (ioputs.c:36) ==8985==    by 0x400FBD: parse_request (m_regex.c:79) ==8985==    by 0x400C2E: main (principal.c:33) ==8985==  Address 0x51d10a3 is 0 bytes later a cake of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (master.c:33) ==8985==  ==8985== Invalid read of size ane ==8985==    at 0x4EA97EA: [email protected]@GLIBC_2.2.5 (fileops.c:1289) ==8985==    by 0x4EA031E: puts (ioputs.c:41) ==8985==    by 0x400FBD: parse_request (m_regex.c:79) ==8985==    by 0x400C2E: master (master.c:33) ==8985==  Accost 0x51d10a3 is 0 bytes after a block of size xix alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    past 0x400C2E: primary (chief.c:33) ==8985==  ==8985== Invalid read of size 4 ==8985==    at 0x4EBA30E: __GI_mempcpy (memcpy.S:95) ==8985==    past 0x4EA9739: [email protected]@GLIBC_2.2.5 (fileops.c:1307) ==8985==    by 0x4EA031E: puts (ioputs.c:41) ==8985==    by 0x400FBD: parse_request (m_regex.c:79) ==8985==    past 0x400C2E: main (main.c:33) ==8985==  Address 0x51d10a0 is 16 bytes within a block of size 19 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  q=gwen ==8985== Invalid read of size 1 ==8985==    at 0x4C2E558: strcmp (vg_replace_strmem.c:755) ==8985==    by 0x400FD0: parse_request (m_regex.c:82) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  Address 0x51d1043 is 0 bytes afterwards a block of size 3 alloc'd ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E4A: parse_request (m_regex.c:53) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985==  ==8985== HEAP SUMMARY: ==8985==     in use at get out: 22 bytes in 2 blocks ==8985==   total heap usage: 3 allocs, one frees, 25 bytes allocated ==8985==  ==8985== 3 bytes in 1 blocks are definitely lost in loss tape i of 2 ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E4A: parse_request (m_regex.c:53) ==8985==    by 0x400C2E: main (main.c:33) ==8985==  ==8985== 19 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==8985==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==8985==    by 0x400E63: parse_request (m_regex.c:54) ==8985==    by 0x400C2E: master (main.c:33) ==8985==  ==8985== LEAK SUMMARY: ==8985==    definitely lost: 22 bytes in ii blocks ==8985==    indirectly lost: 0 bytes in 0 blocks ==8985==      possibly lost: 0 bytes in 0 blocks ==8985==    all the same reachable: 0 bytes in 0 blocks ==8985==         suppressed: 0 bytes in 0 blocks ==8985==  ==8985== For counts of detected and suppressed errors, rerun with: -v ==8985== Mistake SUMMARY: 22 errors from xviii contexts (suppressed: 0 from 0)            

Is This A Good Question/Topic? 0

• 

#ii arortell

• 
• D.I.C Head

Reputation: 5

• 

• Posts: 59
• Joined: 26-Baronial fourteen

Re: Valgrind report is a mess. Invalid read and write of size ane

Posted 02 April 2016 - 03:05 PM

Ok I but read a topic that explained I should exist using sizeof(char*) instead of sizeof(char). I e'er have a hard time figuring out when to use the char or char* if some one could explain that I would really capeesh information technology. Simply now valgrind is reporting unconditional jump and information technology still segfault when I try to complimentary.

valgrind --leak-cheque=total --runway-origins=yep ./regex_tests

==12737== Memcheck, a memory mistake detector ==12737== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==12737== Using Valgrind-three.ten.i and LibVEX; rerun with -h for copyright info ==12737== Command: ./regex_tests ==12737==  text/x-php ==12737== Conditional jump or motion depends on uninitialised value(s) ==12737==    at 0x4C2D528: strlen (vg_replace_strmem.c:412) ==12737==    past 0x4EA027B: puts (ioputs.c:36) ==12737==    by 0x400F67: parse_request (m_regex.c:71) ==12737==    by 0x400C2E: primary (main.c:33) ==12737==  Uninitialised value was created by a heap resource allotment ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    past 0x400E6B: parse_request (m_regex.c:54) ==12737==    by 0x400C2E: main (main.c:33) ==12737==  /favicon.ico?q=gwen ==12737== Utilize of uninitialised value of size 8 ==12737==    at 0x4EB964E: strtok (strtok.S:172) ==12737==    by 0x400F8B: parse_request (m_regex.c:74) ==12737==    by 0x400C2E: primary (main.c:33) ==12737==  Uninitialised value was created by a heap allocation ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E6B: parse_request (m_regex.c:54) ==12737==    by 0x400C2E: principal (primary.c:33) ==12737==  ==12737== Conditional jump or motion depends on uninitialised value(south) ==12737==    at 0x4EB9651: strtok (strtok.S:173) ==12737==    by 0x400F8B: parse_request (m_regex.c:74) ==12737==    by 0x400C2E: primary (main.c:33) ==12737==  Uninitialised value was created by a heap allocation ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E6B: parse_request (m_regex.c:54) ==12737==    past 0x400C2E: main (main.c:33) ==12737==   ==12737== Conditional jump or move depends on uninitialised value(s) ==12737==    at 0x4E7EADD: vfprintf (vfprintf.c:1642) ==12737==    by 0x4E84EB0: printf (printf.c:33) ==12737==    by 0x400FA5: parse_request (m_regex.c:76) ==12737==    past 0x400C2E: main (chief.c:33) ==12737==  Uninitialised value was created past a heap resource allotment ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    past 0x400E4E: parse_request (m_regex.c:53) ==12737==    by 0x400C2E: main (main.c:33) ==12737==  Go ==12737== Conditional jump or move depends on uninitialised value(due south) ==12737==    at 0x4C2D528: strlen (vg_replace_strmem.c:412) ==12737==    by 0x4EA027B: puts (ioputs.c:36) ==12737==    by 0x400FB1: parse_request (m_regex.c:77) ==12737==    past 0x400C2E: primary (main.c:33) ==12737==  Uninitialised value was created by a heap allocation ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E84: parse_request (m_regex.c:55) ==12737==    by 0x400C2E: primary (main.c:33) ==12737==  1.1 /favicon.ico q=gwen ==12737== Conditional jump or move depends on uninitialised value(s) ==12737==    at 0x4C2E560: strcmp (vg_replace_strmem.c:755) ==12737==    by 0x400FDC: parse_request (m_regex.c:82) ==12737==    by 0x400C2E: main (main.c:33) ==12737==  Uninitialised value was created by a heap resource allotment ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E4E: parse_request (m_regex.c:53) ==12737==    by 0x400C2E: main (main.c:33) ==12737==  ==12737== Conditional jump or move depends on uninitialised value(s) ==12737==    at 0x4C2E564: strcmp (vg_replace_strmem.c:755) ==12737==    past 0x400FDC: parse_request (m_regex.c:82) ==12737==    by 0x400C2E: primary (principal.c:33) ==12737==  Uninitialised value was created by a heap allocation ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E4E: parse_request (m_regex.c:53) ==12737==    past 0x400C2E: master (main.c:33) ==12737==  ==12737==  ==12737== HEAP SUMMARY: ==12737==     in use at exit: 176 bytes in ii blocks ==12737==   total heap usage: three allocs, ane frees, 200 bytes allocated ==12737==  ==12737== 24 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    past 0x400E4E: parse_request (m_regex.c:53) ==12737==    by 0x400C2E: main (main.c:33) ==12737==  ==12737== 152 bytes in 1 blocks are definitely lost in loss tape two of 2 ==12737==    at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==12737==    by 0x400E6B: parse_request (m_regex.c:54) ==12737==    by 0x400C2E: primary (primary.c:33) ==12737==  ==12737== LEAK SUMMARY: ==12737==    definitely lost: 176 bytes in two blocks ==12737==    indirectly lost: 0 bytes in 0 blocks ==12737==      possibly lost: 0 bytes in 0 blocks ==12737==    notwithstanding reachable: 0 bytes in 0 blocks ==12737==         suppressed: 0 bytes in 0 blocks ==12737==  ==12737== For counts of detected and suppressed errors, rerun with: -v ==12737== ERROR SUMMARY: nine errors from 9 contexts (suppressed: 0 from 0)            

#3 Skydiver

Reputation: 7916

• 

• Posts: 26,433
• Joined: 05-May 12

Re: Valgrind report is a mess. Invalid read and write of size i

Posted 02 Apr 2016 - 05:40 PM

sizeof(char*) returns the number of bytes used by a pointer to a character.
sizeof(char) returns the number of bytes used by a character. It is defined to be 1 byte in standard versions of C and C++.

#4 Bench

Reputation: 945

• 

• Posts: 2,464
• Joined: twenty-August 07

Re: Valgrind study is a mess. Invalid read and write of size 1

Posted 03 April 2016 - 12:28 AM

arortell, on 02 April 2016 - xi:05 PM, said:

Ok I only read a topic that explained I should be using sizeof(char*) instead of sizeof(char). I e'er have a difficult time figuring out when to use the char or char* if some one could explain that I would actually appreciate it. But now valgrind is reporting unconditional jump and it still segfault when I attempt to costless.

Presumably you're using sizeof in the context of malloc to allocate an assortment-of char? In any case, that doesn't seem to be the biggest trouble that valgrind is complaining about.

The valgrind warnings suggest that your malloc'ed retentivity is not being initialised before yous effort to apply information technology (so when y'all're using it, it contains garbage).

Are you lot initialising your malloc'ed retentiveness? Subsequently you allocate using malloc it's a good habit to zero the retentiveness using memset.

#v arortell

• 
• D.I.C Head

Reputation: 5

• 

• Posts: 59
• Joined: 26-Baronial xiv

Re: Valgrind report is a mess. Invalid read and write of size 1

Posted 03 April 2016 - 09:35 AM

How most calloc doesn't that allocate and aught it out. I wondered why that is not used more often it seems it would always be improve to classify it and zero it out.Also if I am allocating retentivity for a string why should it be sizeof(char*) and not sizeof(char) I am storing a char assortment in there not a char* array. Thank you for your assist.

#6 kaa

• 
• D.I.C Addict

Reputation: 225

• 

• Posts: 805
• Joined: 15-April xi

Re: Valgrind written report is a mess. Invalid read and write of size ane

Posted 03 April 2016 - 09:59 AM

edit: Nevermind, that was wrong.

This mail has been edited by kaa: 03 Apr 2016 - 10:01 AM

#seven kaa

• 
• D.I.C Addict

Reputation: 225

• 

• Posts: 805
• Joined: 15-April 11

Re: Valgrind study is a mess. Invalid read and write of size 1

Posted 03 April 2016 - 10:19 AM

Duh ... no, actually it was right.

Who said you should use sizeof(char*)?

struct slre_cap is divers as

struct slre_cap {   const char *ptr;  /* Points to the matched fragment */   int len;          /* Length of the matched fragment */ };            

You take an array chosen "caps" of slre_cap structs. Now yous want to allocate a segment of memory big enough to concur the (sub)string that one slre_cap (caps[0].ptr) pointer points to, so y'all need a number of bytes equal to the length of the substring + i for the '\0' null terminator so I would think this would practice:

              char *request_method  = malloc(sizeof(char) * caps[0].len + 1);            

and since sizeof(char) is 1 by definition, why not merely

              char *request_method  = malloc(caps[0].len + one);            

Notice that the +ane goes inside the parentheses to provide infinite for the '\0' string terminator, rather than adding 1 to the address.

#8 kaa

• 
• D.I.C Addict

Reputation: 225

• 

• Posts: 805
• Joined: 15-April 11

Re: Valgrind report is a mess. Invalid read and write of size 1

Posted 03 April 2016 - ten:25 AM

Ah, but looking a little further:

for (int i = 0; i < caps[0].len; i++)     request_method[i] = caps[0].ptr[i]; *request_method += '\0';   // this line is wrong            

should probably be

for (int i = 0; i < caps[0].len; i++)     request_method[i] = caps[0].ptr[i]; request_method[i] = '\0';            

Y'all desire to store the zero char at request_method[len], not add 0 to the value of *request_method (which is request_method[0]).

edit: tried unsuccessfully to use "strikeout" within the code frame.

This post has been edited by kaa: 03 April 2016 - 10:28 AM

#9 arortell

• 
• D.I.C Head

Reputation: 5

• 

• Posts: 59
• Joined: 26-August 14

Re: Valgrind report is a mess. Invalid read and write of size 1

Posted 03 April 2016 - 02:23 PM

That did information technology guys thanks alot I actually capeesh your help. I did not realize I was calculation the 1 to the address instead of the corporeality of memory allocated. As far every bit the calloc || (malloc and memset). Why is the malloc and memset used instead of just using calloc and doing it all in one step?

#10 kaa

• 
• D.I.C Addict

Reputation: 225

• 

• Posts: 805
• Joined: xv-April 11

Re: Valgrind report is a mess. Invalid read and write of size one

Posted 03 April 2016 - 02:35 PM

I don't see where you're proposing to utilize calloc. I don't see anyplace where you're using memset, and I don't see anyplace where y'all need memset in the code yous posted.

You're allocating the exact corporeality of memory that you need and you're immediately and explicitly assigning values to every byte of that retentiveness, so what would be the reward of writing zeroes to it first?

If there was a reason to zero it showtime, and then calloc would be preferable to malloc + memset. Only in this case I see no reason for that.

#eleven arortell

• 
• D.I.C Head

Reputation: 5

• 

• Posts: 59
• Joined: 26-August xiv

Re: Valgrind written report is a mess. Invalid read and write of size i

Posted 03 April 2016 - 02:38 PM

No I was asking in general. I hardly ever come across calloc used anybody e'er simply uses malloc and so memset. Thank you for your help.

This post has been edited by arortell: 03 April 2016 - 02:39 PM

#12 Skydiver

Reputation: 7916

• 

• Posts: 26,433
• Joined: 05-May 12

Re: Valgrind report is a mess. Invalid read and write of size 1

Posted 03 Apr 2016 - 05:29 PM

Very likely, they learned C from the 1000&R book where you are more likely to encounter malloc() and memset().

lewinhady1996.blogspot.com

Source: https://www.dreamincode.net/forums/topic/391330-valgrind-report-is-a-mess-invalid-read-and-write-of-size-1/

Share this post