I am getting syntax error in search in rotated sorted array problem of leetcode (C language) [closed] - arrays

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 hours ago.
Improve this question
I am encountering syntax error in my code. If you spot the error please let me know. Thank you so much.
int search(int* nums, int numsSize, int target){
int i;
for (i=0;i<numsSize;i++){
if (*(nums+i+1)>*(nums+i)){
break;
}
}
//k=i
int l,r,mid,flag=0;
if (target>=*nums){
for (l=0,r=i;l<=r;){
mid=(l+r)/2;
if(target==*(nums+mid)){
flag=1;
break;
}
else if (target>=*(nums+mid)){
l=mid+1;
}
else {
r=mid-1;
}
}
}
else if(target>*(nums+i+1)){
for (l=i+1,r=numsSize-1;l<=r;){
mid=(l+r)/2;
if(target==*(nums+mid)){
flag=1;
break;
}
else if (target>*(nums+mid)){
l=mid+1;
}
else {
r=mid-1;
}
}
}
if (flag==1){
return mid;
}
return -1;
}
I first went to the the index holding the largest integer of the array. Then I ran binary searches separately for the two separate arrays(index 0 to i) and (index i+1 to numsSize-1). But the compiler is throwing the following message.
==31==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000054 at pc 0x55b640346b9f bp 0x7fffa3c88ae0 sp 0x7fffa3c88ad0
READ of size 4 at 0x602000000054 thread T0
#2 0x7f5add2b10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
0x602000000054 is located 0 bytes to the right of 4-byte region [0x602000000050,0x602000000054)
allocated by thread T0 here:
#0 0x7f5addef6bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#3 0x7f5add2b10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 04 fa fa fa 04 fa fa fa[04]fa fa fa fa fa
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==31==ABORTING

Related

Runtime Error "heap-buffer-overflow" when returning array

I recently started developing C. And I can't find any error in the code, I would appreciate it if you could point it out to me (thanks in advance)
int* decode(int* encoded, int encodedSize, int first, int* returnSize){
*returnSize=encodedSize+1;
int *arr=malloc(encodedSize * sizeof(int) + 1);
arr[0] = first;
for (int i=0;i<encodedSize;i++){
arr[i+1]=encoded[i] ^ arr[i];
}
return arr;
}
I really don't understand what the problem is because I dynamically allocated memory for the array.
error:
==31==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000038 at pc 0x55c6f70c693c bp 0x7ffcc2336140 sp 0x7ffcc2336130
READ of size 4 at 0x602000000038 thread T0
#2 0x7f2acc57b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
0x60200000003b is located 0 bytes to the right of 11-byte region [0x602000000030,0x60200000003b)
allocated by thread T0 here:
#0 0x7f2acd1c0bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#3 0x7f2acc57b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 00 04 fa fa 00[03]fa fa fd fa fa fa fd fa
0x0c047fff8010: fa fa fd fa fa fa 00 fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==31==ABORTING
I think you mean
(encodedSize + 1) * sizeof(int)
not
encodedSize * sizeof(int) + 1
you want an extra int , not an extra byte (I think)
Becaase of this
arr[i+1]=encoded[i] ^ arr[i];
^^

why does this error being shown mostly when i try to return string?

You are given a string s consisting of lowercase English letters. A duplicate removal consists of choosing two adjacent and equal letters and removing them.
We repeatedly make duplicate removals on s until we no longer can.
Return the final string after all such duplicate removals have been made. It can be proven that the answer is unique.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct stack{
char *items;
int top;
};
#define max 100000
typedef struct stack st;
void push(st *stk,char c){
if(stk->top==max-1){
return;
}
else{
stk->items[++stk->top]=c;
}
}
void pop(st *stk){
if(stk->top==-1){
return;
}
else{
stk->top--;
}
}
char * removeDuplicates(char * s){
st *str;
int l=strlen(s);
str=malloc(sizeof(st));
str->items=malloc(l*sizeof(char));
int i;
str->top=-1;
for(i=0;i<l;++i){
int flag=0;
int j=i+1;
while(s[j]==s[i]){
j++;
flag=1;
}
if(s[i]==str->items[str->top]){
pop(str);
}
else if(flag==0){
push(str,s[i]);
}
else{
i=j-1;
}
}
str->items[str->top + 1]='\0';
return str->items;
}
=================================================================
==31==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000004f at pc 0x560f21617b67 bp 0x7fff66262090 sp 0x7fff66262080
READ of size 1 at 0x60200000004f thread T0
#2 0x7f93db0310b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
0x60200000004f is located 1 bytes to the left of 6-byte region [0x602000000050,0x602000000056)
allocated by thread T0 here:
#0 0x7f93dbc76bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#3 0x7f93db0310b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 07 fa fa fa 00 00 fa[fa]06 fa fa fa fa fa
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==31==ABORTING
One error I see:
char * removeDuplicates(char * s){
st *str;
int l=strlen(s);
str=malloc(sizeof(st));
That last line should be malloc sizeof(*st).

When I was doing the leetcode problem, I found it overflowed after typing the code

When I was doing the leetcode problem, I found it overflowed after typing the code. Here is the code
I think it's malloc creating the pointer, but I don't know why it's wrong,
I think the details are enough, why need the details
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
char * longestCommonPrefix(char ** strs, int strsSize){
int i = 0;
int p = 0;
char flag;
char *str = (char*)malloc(200);
while(1){
flag = strs[i][p];
for(;i<strsSize;i++)
{
if(strs[i][p] != flag || strs[i][p] == '\0'){
strncpy(str,strs[0],p);
return str;
}
}
p++;
i=0;
}
return str;
}
This is an error message
=================================================================
==28==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000000108 at pc 0x55578ee68187 bp 0x7fff10f58390 sp 0x7fff10f58380
READ of size 1 at 0x611000000108 thread T0
#0 0x55578ee68186 in __jsonstrserialize__ /leetcode/__SerializerHelper__.inl:94
#1 0x55578ee6c365 in _serialize_string /leetcode/__Serializer__.c:272
#2 0x55578ee672e5 in main /leetcode/user_code/prog_joined.c:54
#3 0x7f069515b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#4 0x55578ee629ad in _start (/leetcode/user_code/prog+0x3d9ad)
0x611000000108 is located 0 bytes to the right of 200-byte region [0x611000000040,0x611000000108)
allocated by thread T0 here:
#0 0x7f0695da0bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x55578ee66a51 in longestCommonPrefix /leetcode/user_code/prog_joined.c:8
#2 0x55578ee672cf in main /leetcode/user_code/prog_joined.c:52
#3 0x7f069515b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
SUMMARY: AddressSanitizer: heap-buffer-overflow /leetcode/__SerializerHelper__.inl:94 in __jsonstrserialize__
Shadow bytes around the buggy address:
0x0c227fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c227fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c227fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c227fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c227fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c227fff8020: 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==28==ABORTING

C pointer to pointer and queue

I have method that accepts a pointer to pointer
typedef struct message_struct_t {
struct mystruct_t **obj; //not sure if this correct
char name[50];
};
int server(mystruct _t **obj) {
//i am able to push this to a queue
//but first i store this in my temp struct
message_struct_t *message = malloc(sizeof(message_struct_t));
message->obj = obj;
message->name = "Jaime";
myqueue_enqueue(message);
//some mutex and locking mechanism here
for(int i = 0; i < num_threads; i++)
pthread_create(&threads[i], NULL, send_message, NULL);
}
I need to get this object and pass it to a method i will be processing in thread pool
int send_message() {
//i check and there is an item in my queue, but when i try to assign it to a new struct for
//handling i get errors
struct message_struct *received = malloc(sizeof(message_struct)); //ERROR HERE
printf("did I get here ? \n", received->name"); //ERROR
free(received);
}
The error i am getting is this
==20730==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d0000102b0 at pc 0x55bab7c01cf5 bp 0x7f4d8a2fe980 sp 0x7f4d8a2fe0f8
READ of size 2089 at 0x61d0000102b0 thread T1
#0 0x55bab7c01cf4 in printf_common(void*, char const*, __va_list_tag*) (/project_main+0x5ccf4)
0x61d0000102b0 is located 0 bytes to the right of 2096-byte region [0x61d00000fa80,0x61d0000102b0)
allocated by thread T1 here:
#0 0x55bab7c6c7b0 in malloc
in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
0x0c3a7fffa000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fffa010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fffa020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fffa030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fffa040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c3a7fffa050: 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa
0x0c3a7fffa060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fffa070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fffa080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fffa090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fffa0a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Now I am new to C and I may be making some obvious mistake somewhere, I would appreciate some advice as to where I could be assigning wrong (maybe pointers?).
Your send_message should look like following:
void *send_message(void *args) {
struct message_struct *received = *((struct message_struct *) args);
// ....
free(received );
}
If you cannot change send_message prototype, you will have to wrap it inside a void * func(void *args) somehow, which I believe would be too much of maintaining states for the received message.
Also, you need to make sure you correctly release the acquired resource.

Updated Merge Intervals Question #56 on Leetcode (Specifically in C)

The Leetcode question #56 "Merge Intervals" was updated in April 2019 and now takes an input/output parameter int** returnColumnSizes. Why is the returned column size even a double pointer when a single pointer/array would do just fine (all the lengths of the returned arrays should be 2, so there would be *returnSize number of 2s). This double pointer parameter is causing heap-buffer-overflows, preventing my program from running to completion.
If my returned array of arrays is only of size 1, and I do what's shown in the code at the bottom, it passes without problems. Once I increase the number of arrays (and the rows of returnColumnSizes) I get the error pasted below.
returnColumnSizes[0] = (int*)malloc(sizeof(int));
returnColumnSizes[0][0] = 2;
/* Below code causes overflow
for (int i = 0; i < *returnSize; i++)
{
returnColumnSizes[i] = (int*)malloc(sizeof(int));
returnColumnSizes[i][0] = 2;
}
*/
=================================================================
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000b8 at pc 0x000000405644 bp 0x7ffc16dbf5c0 sp 0x7ffc16dbf5b8
READ of size 4 at 0x6020000000b8 thread T0
#3 0x7f1287f2e2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
0x6020000000b8 is located 0 bytes to the right of 8-byte region [0x6020000000b0,0x6020000000b8)
allocated by thread T0 here:
#0 0x7f12893b82b0 in malloc (/usr/local/lib64/libasan.so.5+0xe82b0)
#3 0x7f1287f2e2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
Shadow bytes around the buggy address:
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff8000: fa fa 00 00 fa fa 00 fa fa fa 00 fa fa fa 00 fa
=>0x0c047fff8010: fa fa 00 fa fa fa 00[fa]fa fa 04 fa fa fa fd fa
0x0c047fff8020: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
0x0c047fff8030: fa fa fd fd fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==30==ABORTING
There maybe some factors that has a certain influence on the situation:
1. The allocation problem: You're saying that whenever you try to get to the other objects in the array, they are unreachable. That may occur in a situation where there wasn't allocated more than one object in the array.
2. A compiler problem which you can't do anything about it but it mostly unlikely to happen.
So let's go with the first option.

Resources