¿Por qué agregar un archivo cpp para ser compilado con Cmake podría llevar a una violación de segmentación en medio de la ejecución de un programa?
Compile y ejecuto el programa normalmente de la siguiente manera:
set(A_SRC a.hpp a.cpp)
Cuando agrego un segundo objetivo de compilación de la siguiente manera:
set(A_SRC a.hpp a.cpp b.hpp b.cpp)
conduce a un SegFault durante la ejecución Segmentation fault (core dumped), el coredump no tiene información valiosa sobre la causa.
b.hpp no se usa en ningún lugar, todo el código / funciones dentro de b están dentro de un espacio de nombres separado. b.hpp comparte similitud con una de las bibliotecas vinculadas.
¿Cuál podría ser la causa del SegFault? ¿Cómo se puede causar un SegFault simplemente compilando más código?
Más información por si acaso:
0 0x00007f489ba27550 en ?? ()
1
2 0x00007f489ba27550 en ?? ()
3
4 0x00007f495daf87b1 en pthreadcondtimedwait@@GLIBC_2.3.2 ()
de /usr/lib/x86_64-linux-gnu/libpthread.so.0
5 0x00007f465c8e9c66 en gthreadcondtimedwait (cond=0x55fdf3180b88,
__mutex=0x55fdf3180b60, __abs_timeout=0x7ffe36106dd0)
en /usr/include/x86_64-linux-gnu/c++/9/bits/gthr-default.h:872
6 0x00007f465c8eb676 en std::conditionvariable::waituntilimpl > > (this=0x55fdf3180b88, _ lock=…, __atime=…)
en /usr/include/c++/9/condition_variable:188
7 0x00007f465c8eab4a en std::conditionvariable::waituntilV2::steadyclock, std::chrono::duration > > (this=0x55fdf3180b88,
__lock=..., __atime=...) en /usr/include/c++/9/condition_variable:121
8 0x00007f465c8ea1c5 en std::conditionvariable::waitfor > (
this=0x55fdf3180b88, __lock=..., __rtime=...)
…
“`
Y los otros hilos no son útiles:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7f495d78c740 (LWP 18) 0x00007f489ba27550 en ?? ()
2 Thread 0x7f4661aea700 (LWP 121) 0x00007f495d86f3bf en clock_nanosleep ()
desde /usr/lib/x86_64-linux-gnu/libc.so.6
3 Thread 0x7f480bcac700 (LWP 138) 0x00007f495daf8376 en pthread_cond_wait@@GLIBC_2.3.2
desde /usr/lib/x86_64-linux-gnu/libpthread.so.0
4 Thread 0x7f48a1cc6700 (LWP 128) 0x00007f495d8a4aff en poll ()
desde /usr/lib/x86_64-linux-gnu/libc.so.6
5 Thread 0x7f47bdc9f700 (LWP 145) 0x00007f495daf8376 en pthread_cond_wait@@GLIBC_2.3.2
desde /usr/lib/x86_64-linux-gnu/libpthread.so.0
6 Thread 0x7f4885cc1700 (LWP 130) 0x00007f495d8b2c90 en accept4 ()
desde /usr/lib/x86_64-linux-gnu/libc.so.6
davy.ai
La adición del segundo objetivo de compilación pudo haber causado un SegFault porque el vinculador pudo haber incluido algunos elementos de b.cpp que causaron conflictos con elementos en a.cpp que ya se habían compilado. Este conflicto es probable que suceda cuando hay una colisión de nombres (como dos funciones con el mismo nombre) o debido a alguna creación de objeto implícita en b.hpp.
Una posible forma de causar un SegFault simplemente compilando más código es invocando un comportamiento indefinido. Por ejemplo, acceder a un puntero nulo o escribir más allá del final de una matriz puede provocar un SegFault. Otra posibilidad es la corrupción de la memoria causada por un error en el código.
Para solucionar el problema de SegFault, es necesario analizar cuidadosamente el código, verificar la presencia de cualquier comportamiento indefinido o corrupción de memoria, y asegurarse de que no haya conflictos de nombres o problemas de creación de objetos implícitos entre diferentes objetivos de compilación. También se puede intentar reducir el problema ejecutando el código con un depurador, examinando la traza de la pila y los hilos.