1. bash / Говнокод #28947

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    48. 48
    49. 49
    50. 50
    51. 51
    52. 52
    53. 53
    54. 54
    // Таких warning куча целая.
warning: Can't open file /dev/hugepages/rtemap_72 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_73 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_70 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_71 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_68 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_69 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_64 during file-backed mapping note processing

warning: Can't open file /dev/hugepages/rtemap_67 during file-backed mapping note processing


warning: Can't open file /usr/lib/x86_64-linux-gnu/libpthread-2.31.so during file-backed mapping note processing

warning: Can't open file /usr/lib/x86_64-linux-gnu/libdl-2.31.so during file-backed mapping note processing

warning: Can't open file /usr/lib/x86_64-linux-gnu/ld-2.31.so during file-backed mapping note processing
[New LWP 3742003]
[New LWP 3742078]
[New LWP 3742050]
[New LWP 3742068]
[New LWP 3742356]
[New LWP 3742094]
[New LWP 3742095]
[New LWP 3742315]
[New LWP 3742316]
[New LWP 3742322]
[New LWP 3742338]
[New LWP 3742354]
[New LWP 3742355]
[New LWP 3768784]

(gdb) bt
#0  0x00007fbcdb6c92ab in ?? ()
#1  0x0000000000004203 in ?? ()
#2  0x00007fbcdabadf90 in ?? ()
#3  0x00007fbcdabb136e in ?? ()
#4  0x000055f0507c881a in ?? ()
#5  0x00007fbcdb5abdb4 in ?? ()
#6  0x000055f0507c908e in ?? ()
#7  0x000055f0507ab565 in ?? ()
#8  0x000055f0507abad0 in ?? ()
#9  0x000055f0507ac1f1 in ?? ()
#10 0x000055f0507aece7 in ?? ()
#11 0x000055f050795ca5 in ?? ()
#12 0x00007fbcd893b083 in ?? ()
#13 0x000055f050798f9e in ?? ()
#14 0x0000000000000000 in ?? ()

    С корками вообще не работал ни разу. И сейчас gdb показывает знаки вопроса, дебажные символы прогрузились, в чем может быть дело?

    Запостил: YpaHeLI_, 20 Июня 2024

    Комментарии (13) RSS

    • ava guest6 20.06.2024 16:41 # 0

      >дебажные символы прогрузились
      откуда это видно?

      Что ты дебажишь? Как ты собрал то, что ты дебажишь? С какими ключами? Как запущен gdb?
      Ответить

    • ava guest6 20.06.2024 18:07 # 0

      хз что у тебя не работает, у меня всё работает
      $ cat 1.c
#include <stdio.h>

static foo() {
        char    *a = 0;
        *a = 1;
}

int main() {
        foo();
}
$ gcc 1.c -O0
1.c:3:8: warning: return type defaults to ‘int’ [-Wimplicit-int]
    3 | static foo() {
      |        ^~~
$ ulimit -c unlimited
$ ./a.out
Segmentation fault (core dumped)
$ gdb a.out core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
(No debugging symbols found in a.out)
[New LWP 100]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055a7adf14139 in foo ()
(gdb) bt
#0  0x000055a7adf14139 in foo ()
#1  0x000055a7adf1414d in main ()
      Ответить

      • ava guest6 20.06.2024 21:13 # 0

        На мой взгляд лучше явно указывать -g при компиляции, потому что иначе можно нарваться на то, что в каком-нибудь окружении по умолчанию дебажные символы не создаются.
        Ответить

      • ava guest6 20.06.2024 21:15 # 0

        Смотри, что ещё нашёл:

        If you are not using some other optimization option, consider using -Og (see Options That Control Optimization) with -g. With no -O option at all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may result in a better debugging experience.

        Итого: -g -Og
        Ответить

        • ava guest6 20.06.2024 22:27 # 0

          да, лучше -g, иначе может не вкомпайлить в эльфа дварфа (хотя обычно надо явно отключать чтоб не вкомпалил)

          я сделал -O0 чтобы мне мастер UB не заменил весь код на `return`, но твой вариант лучше

          Почему в прыще принято вкомпаливать дебажные символы в бинарь, а в сперме делать отдельные pdb?
          Ответить

          • ava guest6 20.06.2024 22:44 # 0

            Да, в мире gcc (и, вероятно, LLVM) принято по умолчанию включать символы, а если они потом не нужны, стрипать их утилитой strip.

            Почему на одних платформах pdb, на други всё сшито, не знаю. Вероятно, потому что в Винде большинство ПО (по крайней мере, раньше так было) — коммерческое, так что отправлять юзеру отладочные символы нежелательно. Когда они в отдельном pdb-файле, их распространением проще управлять.

            Gcc же в основном используется для свободного ПО, поэтому всё для отладки из коробки.
            Ответить

            • ava guest6 21.06.2024 01:44 # 0

              А может потому, что Win95 занимал 50 мегабайт на диске?
              Ответить

              • ava guest6 21.06.2024 03:12 # 0

                И поэтому тоже. MS предлагает отдельно скачать символы для системных DLL, и они вроде весят больше 50 МБ.
                Ответить

                • ava guest6 21.06.2024 03:18 # 0

                  Они сами как-то качаются, кстати. Там надо поставить переменную окружения, и dbghlp.dll сам их скачает. А у dbghlp (или как-то так) фронтом работают уже и windbg и соснольный (забыл как зовут) и VS и бывшеядерный и вся хуйня

                  Да, они весят больше.

                  А еще раньше была тн "checked' версия винды: винда собранная с ключами дебага. ее выдавали только доверенным партнёрам, чтобы им было удобнее отлаживать свое говно
                  Ответить

                  • ava guest6 21.06.2024 04:37 # 0

                    Причём формат каталога менялся. Раньше был плоский список, а потом к именам файлов стали добавлять контрольные суммы, чтобы можно было одновременно держать символы от нескольких версий dll (сайд бай сайд).

                    Про checked откуда-то знаю. Из Windows DDK?
                    Ответить

                    • ava guest6 21.06.2024 05:06 # 0

                      Я у Руссиновича читал еще в книжке про W2K, хотя могло быть и в DDK и у Walter Oney, который про писание драйверов под винду писал
                      Ответить

    • ava guest6 21.06.2024 02:49 # 0

      зурги-и-лурги блядь ;))
      https://x.com/666_mancer/status/1803769377424019676
      Ответить

    • ava guest6 21.06.2024 05:23 # 0

      Упустил невесту
      https://x.com/DNusina/status/1803017185809281119
      Ответить

    Добавить комментарий