Linux received signal 11

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux RADV — Compiles fine but getting «Received Signal 11, aborting» when starting new game in rtx mode. #163

Linux RADV — Compiles fine but getting «Received Signal 11, aborting» when starting new game in rtx mode. #163

Comments

As title says, I can compile the game fine from source however upon attempting to start a new game in rtx mode I get «Received Signal 11, aborting». There’s no indication of what may be causing it. I’ve tried both Demo and Full game, same issue happens.

Switching the game to OpenGL mode works fine though.

Mesa version: 21.3.0
Game being compiled as of commit: 53c23b1
Log file: Log.txt

I can also confirm the environment variable to enable RT «RADV_PERFTEST=rt» is on.

I’ve tried the pre-compiled builds but my libc is too old (2.24) to run them.

I ran the game in gdb and got the following line:

«Thread 1 «q2rtx» received signal SIGSEGV, Segmentation fault.
0x0000555555523c9c in compute_sky_visibility ()»

I’m at a loss where to go next.

The text was updated successfully, but these errors were encountered:

Ok so I rebuilt the game in debug mode, ran «gdb ./q2rtx», then when the error occurred I typed in «bt». Got the below output:

Thread 1 "q2rtx" received signal SIGSEGV, Segmentation fault. 0x00005555555218cb in compute_sky_visibility (wm=0x8000555555b1b710, bsp=0x555557b19d20) at /home/jojo/1/Q2RTX/src/refresh/vkpt/bsp_mesh.c:1596 1596 for (int i = 0; i < (wm->world_sky_count + wm->world_custom_sky_count) / 3; i++) (gdb) bt #0 0x00005555555218cb in compute_sky_visibility (wm=0x8000555555b1b710, bsp=0x555557b19d20) at /home/jojo/1/Q2RTX/src/refresh/vkpt/bsp_mesh.c:1596 #1 0x0000555555523521 in bsp_mesh_create_from_bsp ( wm=0x555555b1b710 , bsp=0x555557b19d20, map_name=0x555556713c80 "demo1") at /home/jojo/1/Q2RTX/src/refresh/vkpt/bsp_mesh.c:1996 #2 0x000055555553a56c in R_BeginRegistration_RTX ( name=0x555556713c80 "demo1") at /home/jojo/1/Q2RTX/src/refresh/vkpt/main.c:4017 #3 0x000055555544a5dd in CL_PrepRefresh () at /home/jojo/1/Q2RTX/src/client/precache.c:344 #4 0x000055555543fe2b in CL_Begin () at /home/jojo/1/Q2RTX/src/client/main.c:1771 #5 0x000055555542a86d in CL_RequestNextDownload () at /home/jojo/1/Q2RTX/src/client/download.c:749 #6 0x000055555543ff21 in CL_Precache_f () at /home/jojo/1/Q2RTX/src/client/main.c:1827 #7 0x00005555554416de in exec_server_string (buf=0x555556727360 , text=0x7fffffffd080 "precache 4193349") at /home/jojo/1/Q2RTX/src/client/main.c:2582 #8 0x000055555547d85d in Cbuf_Execute (buf=0x555556727360 ) at /home/jojo/1/Q2RTX/src/common/cmd.c:200 #9 0x0000555555442df6 in CL_ProcessEvents () ---Type to continue, or q to quit--- at /home/jojo/1/Q2RTX/src/client/main.c:3406 #10 0x0000555555442a3a in CL_Frame (msec=1) at /home/jojo/1/Q2RTX/src/client/main.c:3232 #11 0x0000555555485fe0 in Qcommon_Frame () at /home/jojo/1/Q2RTX/src/common/common.c:1162 #12 0x00005555554d1153 in main (argc=1, argv=0x7fffffffe228) at /home/jojo/1/Q2RTX/src/unix/system.c:532 

Sorry this gdb stuff is all new to me, I’m learning as I go.

Hm, this gives some more information, but unfortunately nothing conclusive yet.
If I had to guess wildly, I’d say maybe cluster on line 1600 receives a negative value, which would make the condition on line 1601 pass, and cause an out-of-bound write on line 1602.
But that’s really just guessing. Though if you want, you could test that theory by strategically placing some checks.

Also, could you provide some additional information on your environment?
E.g. what Linux distro are you using? Which compiler? What flags did you pass to cmake?

In the stack trace above, I find the wm=0x8000555555b1b710 part suspicious — why 0x800. My first guess here is that something went wrong but an error check was skipped, and that something led to memory corruption.

I can try to repro this sometime later.

Источник

14.1.1. Система выдает ошибки Signal 11?

Ошибка signal 11, часто называемая сбоем сегментации, означает, что программа обращается к неизвестной ячейке памяти. Если во время установки вы получаете критическую ошибку «signal 11» , скорее всего это связано с ошибкой кода установленного программного обеспечения или сбоем оборудования.

Если во время установки вы получаете критическую ошибку «signal 11», возможно, это связано с аппаратной ошибкой памяти шины компьютера. Аппаратные сбои памяти могут быть вызваны ошибками программ или сбоями оборудования. Так же, как и другие операционные системы, Red Hat Enterprise Linux выдвигает свои требования к оборудованию. Некоторые типы оборудования могут не соответствовать этим требованиям, даже если они корректно работали с другой операционной системой.

Убедитесь в том, что вы используете последние обновления программы установки и образы от Red Hat. Обратитесь к разделу исправлений в Интернет для проверки последних вышедших обновлений. Если вы не можете загрузиться и с последними образами дисков, скорее всего причиной проблемы является ваше оборудование. Чаще всего это дефекты оперативной памяти или кэша процессора. Можно попытаться исправить эту ошибку, отключив кэш процессора в BIOS. Вы также можете переставить модули памяти в другие слоты, чтобы определить, связана ли проблема с памятью или слотами.

Кроме этого, выполните проверку установочных компакт-дисков. Программа установки Red Hat Enterprise Linux имеет возможность проверки целостности носителей. Это можно сделать при установке с CD, DVD или ISO-образа, расположенного на жестком диске или в сети. Red Hat рекомендует проверять все носители до начала процесса установки и не спешить сообщать об ошибках (большое количество ошибок на самом деле связано с неверно записанными компакт-дисками). Чтобы выполнить проверку, введите в приглашении boot: или yaboot: следующую команду (на компьютере Itanium добавьте перед ней elilo ):

За дальнейшей информацией об ошибках «signal 11» обратитесь к:

Источник

C++ How to identify SIGNAL 11 error location

I´m running a multi-threaded C++ program in a Linux system (Kernel 2.6.23). My code is compiled using G++ version 4.7.4. I added the following code to catch segmentation faults:

void segFaultHandler(int sig)

Error: signal 11: /home/cross/bin/aeirtu[0x807406e] [0xffffe420] /lib/libc.so.6(memcpy+0x2f)[0xb7d9bcbf] /usr/gcc-4.7.4/lib/libstdc++.so.6(_ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKci+0x73)[0xb7f26933] 

It is not a easy debug as my program crashes only sometimes, so I need a tool to get the crash source and fix it. From the given output, how can I trace back the function and piece of code that caused the crash ?

First, remove your signal handler. Second, set up your system to produce core files. Third, use a debugger on a core file. It helps if you build with debugging information, and with no optimizations.

You can’t open the core file with gdb and get the exact point it crashed? Don’t see the need for the signal handler if you can generate a core file. The core file will contain all the information you are trying to print out.

2 Answers 2

You can use valgrind to locate the source of a segfault. If you binary is compiled with debug symbols it will give you the exact source location:

==12834== Invalid write of size 4 ==12834== at 0x4004FD: main (test.cc:3) ==12834== Address 0x0 is not stack'd, malloc'd or (recently) free'd 

You can use Address Sanitizer (ASAN) by google to detect segmentation faults as well as other common programming errors related to memory (including heap use after free, buffer overflow, buffer underflow, freeing memory twice, memory leaks, etc). If an error is detected, it will give a stack trace of exactly where the error occurred (and if you use -g to include debug symbols, the stack trace is fairly understandable).

ASAN gets linked into your binary at compile time and checks your heap at run time with very little overhead (code runs about 2x slower). This is significantly faster than valgrind and has the advantage that it can run in a live environment and give valuable messages if a 2x slow down is acceptable for your use case.

Furthermore, if your segmentation fault is caused by one of the aforementioned programming errors, it will be caught by ASAN before the code even seg faults. For example, let’s say you buffer overflow, corrupting the state of the heap. When you go to malloc memory later, malloc seg faults because the heap is corrupted. Any signal handler would detect the corruption at this point, even though the real problem was a heap buffer overflow. ASAN would give you a stack trace at the time of heap buffer overflow.

Источник