LINUX.ORG.RU

strace 4.17

 ,


1

3

strace — утилита для диагностики и отладки программ для ОС, использующих ядро Linux. Она позволяет отслеживать и (начиная с версии 4.15) вмешиваться в процесс взаимодействия программы и ядра, включая происходящие системные вызовы, возникающие сигналы и изменения состояния процесса. Для своей работы strace использует механизм ptrace. Начиная с версии 4.13 формирование выпусков strace синхронизировано с выходом новых версий Linux.

Основные изменения этого релиза:

  • Оптимизирована фильтрация системных вызовов за счёт уменьшения количества вызовов ptrace() для системных вызовов, отображение которых отключено.
  • Добавлена поддержка декодирования системного вызова statx(2), появившегося в Linux 4.11.
  • Добавлена поддержка декодирования команд ioctl(2), связанных с операциями над пространствами имён.
  • Для ioctl подсистемы Video4Linux добавлена поддержка декодирования не декодировавшихся ранее типов V4L2_BUF_TYPE_*, а также команд VIDIOC_S_TUNER и VIDIOC_G_TUNER.
  • Реализована поддержка декодирования сообщений NLMSG_ERROR протокола netlink.
  • Улучшено декодирование системного вызова sched_setattr(2), команды BPF_PROG_ATTACH системного вызова bpf(2), некорректных аргументов команд подсистемы device mapper системного вызова ioctl(2).
  • Классы системных вызовов, указываемые в аргументе -e trace= (такие как process, file, network, ipc, desc, memory), теперь должны начинаться со знака %: -e trace=%memory. Старый синтаксис без указания знака процента (-e trace=memory) всё так же поддерживается, но теперь считается устаревшим.
  • Добавлены новые классы системных вызовов для указания их фильтрации: %stat (варианты системного вызова stat(2) на разных архитектурах), %lstat (варианты системного вызова lstat(2)), %fstat (варианты системных вызовов fstat(2) и fstatat(2)), %%stat (все вызовы, возвращающие статусную информацию о файле, включая statx(2)), %statfs (варианты системного вызова statfs(2)), %fstatfs (варианты системного вызова fstatfs(2)), %%statfs (все вызовы, возвращающие статусную информацию о файловой системе, включая ustat(2)).
  • Добавлена возможность указания регулярного выражения для задания множества фильтруемых системных вызовов, например, -e trace=/sched_.*.
  • Добавлена возможность игнорирования ошибки, возникающей в случае, если множество системных вызовов, соответствующее указанному фильтру, пустое, например -e trace=?statx на архитектурах, которые не поддерживают системный вызов statx(2).
  • Добавлена поддержка декодирования маски сигналов в системном вызове rt_sigreturn(2) для архитектур alpha, arc, arm, avr32, bfin, cris, hppa, m68k, metag, microblaze, mips, nios2, or1k, powerpc, powerpc64, riscv, sh, sh64, sparc, sparc64, tile, x86 и xtensa.
  • Исправлено декодирование аргумента флагов в системных вызовах preadv2(2) и pwritev2(2) на ABI x32.
  • Исправлено декодирование старого варианта системного вызова sigsuspend(2) на архитектурах alpha, cris, mips, powerpc, powerpc64, sh, sh64, sparc и sparc64.
  • Исправлено декодирование системных вызовов sgetmask(2) и ssetmask(2) на 64-битных архитектурах.
  • Обойдена ошибка компилятора GCC, приводящая к генерации некорректного кода на ядрах для архитектуры aarch64, вследствие которой третий аргумент системного вызова sched_getattr(2) не вполне 32-битный.

Также, среди изменений, вошедших в предыдущий релиз 4.16, можно отметить следующие:

  • В механизм подмены системного вызова добавлена поддержка указания возвращаемого значения (-e inject=SET:retval=) и возбуждения сигнала (-e inject=SET:signal=)
  • Добавлена поддержка декодирования системного вызова ustat(2).
  • Реализована поддержка декодирования команд BPF_OBJ_PIN, BPF_OBJ_GET, BPF_PROG_ATTACH и BPF_PROG_DETACH системного вызова bpf(2).
  • Существенно доработана поддержка декодирования команд SCSI системного вызова ioctl(2): добавлена поддержка декодирования всех не доекодировавшихся ранее команд SG_*, а также структур sg_io_hdr и sg_io_v4.
  • Улучшено декодирование системных вызовов get_robust_list(2), getrandom(2), io_submit(2), set_robust_list(2).
  • Исправлено декодирование структур ifconf, ifreq, and loop_info для ABI, отличающихся от ABI ядра.
  • Исправлено декодирование системных вызовов kexec_file_load(2), mprotect(2), pkey_mprotect(2), prctl(2), preadv(2)/preadv2(2), pwritev(2)/pwritev2(2) на ABI x32.

>>> Полный список изменений

>>> Сайт проекта (sourceforge)

>>> Репозиторий (sourceforge)

>>> Сообщение в списке рассылки

★★

Проверено: shell-script ()
Последнее исправление: sudopacman (всего исправлений: 9)

Самая годная утилита. Иногда на работе аналога под Windows просто катастрофические не хватает.

h4tr3d ★★★★★
()
Ответ на: комментарий от val-amart

стрейс вроде тогда и небыло еще

[76baf7] by Wichert Akkerman Wichert Akkerman Initial revision
1999-02-19 00:21:36

selivan ★★★
()
Ответ на: комментарий от h4tr3d

аналога под Windows просто катастрофические не хватает.

Хм, странно. Я ещё в 2007-м году на презентации windows server 2008 видел что у них есть встроенные средства даже покруче strace. Подробности не скажу, мне тема вендов не интересна.

true_admin ★★★★★
()

Одна из тех вещей, которые, когда увидел впервые, подумал «как, черт побери, это возможно?!»

anonymous
()
Ответ на: комментарий от anonymous

https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Wi... Restrictions ... reverse engineer, decompile, or disassemble the software

И это в EULA появилось давно, еще до 10ки, а дебаггер без просмотра кусков ассемблерного кода, то бишь без дизассемблирования, это не дебаггер, имхо.

Аналогов strace под Windows увы нет, есть инструментарий от Руссиновича, теперь уже от Microsoft, но опять таки, GUI с вкладками зачастую сводит все на нет.

Samsky
()
Ответ на: комментарий от SZT

32-bit

Currently, Dr. Memory does not yet support uninitialized read detection for 64-bit applications, so we recommend compiling your target application as 32-bit.

Имхо, не совсем, или я что-то не понял?

anonymous
()
Ответ на: комментарий от anonymous

Это «uninitialized read detection» не относится к функционалу «System Call Tracer („strace“) for Windows». «uninitialized read detection» это то, чем занимается например valgrind. А «System Call Tracer» должен и на 64-битных нормально работать

SZT ★★★★★
()
Ответ на: комментарий от h4tr3d

Иногда на работе аналога под Windows просто катастрофические не хватает.

Когда-то для DOS был Turbo Debugger борландовский. Сделали ли они его для Windows - это вот не знаю.

AS ★★★★★
()
Ответ на: комментарий от Samsky

Был в составе cygwin, но может не дружить с 64битными процессами

mittorn ★★★★★
()

Эта утилита не раз облегчачала мне жизнь, когда все остальные варианты уже были перепробованы.

das_tier ★★★★★
()

Использование strace требует некоторого хакерского инстинкта. Это не для всех. Большинству простых пользователей, вероятно, никогда не понадобится strace, хотя они и могут. С другой стороны, системных администраторов, особенно занимающихся технической поддержкой, вряд ли придется уговаривать воспользоваться strace.
Однако, если вы любопытны, или хотите лучше понять, как работает система, или копание в системе является частью вашей работы, strace может стать хорошей отправной точкой. В любом случае время не будет потрачено зря.
Strace не является единственной утилитой, способной трассировать системные вызовы. Есть еще ltrace, которая умеет работать не только с системными, но и с библиотечными вызовами, а также популярный Gnu Debugger (gdb), который представляет собой полнофункциональный отладчик программного кода.
Важно помнить, что хотя strace не столь мощная утилита, как две вышеуказанные, она намного безопаснее и проще в использовании. ltrace имеет склонность обрушивать процессы, которые она отслеживает. gdb намного более сложен и требует глубокого знания кода. Лучше всего с ним работать, если доступны исходные коды, что бывает не всегда. strace можно назвать легкой артиллерией, но он удобен и всегда под рукой.

kto_tama ★★★★★
()
Последнее исправление: kto_tama (всего исправлений: 1)
Ответ на: комментарий от kto_tama

Важно помнить, что хотя strace не столь мощная утилита, как две вышеуказанные, она намного безопаснее и проще в использовании.

гогно это ваше strace, которое в проде нельзя использовать потому что тормозить всё люто начинает. use systemtap/dtrace/ luke.

anonymous
()
Ответ на: комментарий от anonymous

в проде нельзя использовать потому что тормозить всё люто начинает

В большинстве случаев мы используем strace чтобы понять почему приложение «тупит» или глючит (=неработоспособно), поэтому тормоза strace ни разу не были проблемой в нашей практике. У нас замедление программ под трасировкой где-то 2-5раз что для глючащего приложение допустимо.

true_admin ★★★★★
()
Ответ на: комментарий от I_one

А Вы бы рассказали

Увы, мне нечего сказать, я windows-системами не занимаюсь.

true_admin ★★★★★
()
Ответ на: комментарий от kto_tama

Он просто незаменим, когда нужно быстро понять - какого файла не хватает программе. С учётом всяких поделок от XDG с хреновой или никакой документацией - очень актуально.

h4tr3d ★★★★★
()
Ответ на: комментарий от DELIRIUM

LOR торт. Не думал, что столько рекомендаций вылезет. Что-то и вышеперечисленного, ЕМНИП, пробовал, но не совсем подошло. Задача была в конце концов решена и забыта :)

h4tr3d ★★★★★
()
Ответ на: комментарий от true_admin

А теперь представь, что ты дебажишь долгий sql в базе со 100к tps. Вопрос: как скоро юзеры заметят и манагеры прибегут тебя нагибать? Не, так-то и у нас даже фронт-энд всякий strace балуется, но использование в проде жестоко карается.

anonymous
()
Ответ на: комментарий от eSyr

Долгий sql дебажится посредством explain/analyze

Этого бывает недостаточно, я для примера привёл, подставь туда всё что нравится. dtrace и ко даёт тебе полную картину происходящего в системе.

но никак не strace.

это точно.

anonymous
()
Ответ на: комментарий от anonymous

Сложнее сделать чтобы было невозможно если чуть подумать ))

anonymous
()
Ответ на: комментарий от anonymous

тормозить всё люто начинает

Всю систему целиком трассировал c ДЕ и прочим запуская strace из инита, особого торможения не заметил (лог писал в tmpfs). Кому-то пора апгрейдиться.

anonymous
()
Ответ на: комментарий от anonymous

Кому-то пора апгрейдиться.

Кому-то пора прочитать, как же работает этот strace.

anonymous
()
Ответ на: комментарий от anonymous

Думаешь самый умный? Бывают ситуации, когда аномалии происходят уже после всех этих dev, stg, tst этапов. Даже элементарно железо глючить начать может. Так что выпендрится у тебя не получилось.

anonymous
()
Ответ на: комментарий от anonymous

dtrace и ко

DTrace ядерный модуль хочет в Linux, ftrace/perf тогда уж. Но они не решают проблему декодинга структур по указателям, например.

eSyr ★★
() автор топика
Ответ на: комментарий от true_admin

Во-первых, вычленить - это вообще не вопрос, хоть по transaction id, хоть по каким-то определённым действиям, во-вторых, проблема может быть и не в самом запросе.

anonymous
()
Ответ на: комментарий от eSyr

DTrace ядерный модуль хочет в Linux

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

Но они не решают проблему декодинга структур по указателям, например.

зато dtrace вполне себе.

anonymous
()
Ответ на: комментарий от true_admin

Зависит от того, что за пробы предоставили разрабы базы и какие параметры передают эти пробы в аргументах. По вопросам реализации обращаться в раздел документации «динамическая трассировка» соответствующей базы.

anonymous
()
Ответ на: комментарий от true_admin

Вот пример почему strace, да и вообще линуксовый ptrace(), лучше не использовать. В конце ссылка на продолжение истории.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.