Segmentation fault (core dumped)

[Jonathan100]

Hi,
I get strange segfault error when working with hierarchy of c programs (3 stages)

I can give a link to the sources, but first i will describe the issue:
i am working with pcie cards on ubuntu 18.04 and trying to access the, (read/write)

main ---> API ---> Driver

in Driver.c i have a function which open the pci bar resource file
in main.c i munmap the bar

I got segmentation error right after return 0 in main.c
basically I can't assign a local variable in main.c
even if i write:

int i;
i++;

it gives the error
This is what is get in the end of valgrind command:
''
==17660== Jump to the invalid address stated on the next line
==17660== at 0x81A003CD: ???
==17660== Address 0x81a003cd is not stack'd, malloc'd or (recently) free'd
==17660==
==17660==
==17660== Process terminating with default action of signal 11 (SIGSEGV)
==17660== Access not within mapped region at address 0x81A003CD
==17660== at 0x81A003CD: ???
==17660== If you believe this happened as a result of a stack
==17660== overflow in your program's main thread (unlikely but
==17660== possible), you can try to increase the size of the
==17660== main thread stack using the --main-stacksize= flag.
==17660== The main thread stack size used in this run was 8388608.
==17660==
==17660== HEAP SUMMARY:
==17660== in use at exit: 0 bytes in 0 blocks
==17660== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==17660==
==17660== All heap blocks were freed -- no leaks are possible
==17660==
==17660== For counts of detected and suppressed errors, rerun with: -v
==17660== ERROR SUMMARY: 11 errors from 5 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
''

any suggestions?

[Peter87]

Compile the program with -g for better valgrind error messages.

[kigar64551]

Quite possible a previous error corrupted the stack and now it will crash on return.

Try running the program in a debugger and step trough the code in order to see what exactly is going on.

In addition to -g you may want to give -fsanitize=address -fno-omit-frame-pointer a try.

https://github.com/google/sanitizers/wiki/AddressSanitizer
https://www.osc.edu/resources/getting_started/howto/howto_use_address_sanitizer

[Jonathan100]

After adding this flag:

-fsanitize=address -fno-omit-frame-pointer

I got an error even without declaring local variables in main:

*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)

Question: if i call mmap from inside a function:
bar0 = mmap(NULL,BUFFER,PROT_READ | PROT_WRITE, MAP_SHARED,fd,0);
do i need to 'munmap' the bar in the same function?

[jonnin]

No. The map will be killed when your process exits, but that is not ideal unless your program is like a 1 page utility or homework.
You should call unmap when you are done with it. So when you no longer need bar0, you should get rid of it. I am not sure if bar0 can become invalid somehow, but if that is the case, you should also unmap it if that happens.

basically my understanding is that it works just like a pointer ... get it, use it, when done with it or if it becomes invalidated, release it. That may or may not be in the same function where it was mapped ... you could for example be making a memory mapped file class that called unmap in the destructor.

[kigar64551]

*** stack smashing detected ***: <unknown> terminated

So, yeah, this confirms that you have some sort of memory error (e.g. buffer overwrite) that corrupts the stack!
https://www.educative.io/answers/what-is-the-stack-smashing-detected-error

BTW: mmap() is like the "low-level" (syscall) variant of malloc(). It returns a pointer to the mapped memory area. This memory area will remain valid until it is de-allocated using munmap() – which doesn't need to happen in the same function and it certainly must not happen as long as the memory area is still in use somewhere. You normally don't call m[un]map() directly though, but use malloc() and friends instead. On Linux, the C memory manager internally uses mmap() to request memory blocks from the operating system, if needed.

[Jonathan100]

Thanks folks, the error was due to a buffer overflow of char array

I came across nice thread that explain debug techniques:

https://stackoverflow.com/questions/1345670/stack-smashing-detected

see:
Minimal reproduction example with disassembly analysis