Trace error opening trace file no such file or directory

I am getting the above error: error opening trace file: No such file or directory (2) when I run my android application on the emulator. Can someone tell me what could be the possible reason ...

I think this is the problem

A little background

Traceview is a graphical viewer for execution logs that you create by using the Debug class to log tracing information in your code. Traceview can help you debug your application and profile its performance. Enabling it creates a .trace file in the sdcard root folder which can then be extracted by ADB and processed by traceview bat file for processing. It also can get added by the DDMS.

It is a system used internally by the logger. In general unless you are using traceview to extract the trace file this error shouldnt bother you. You should look at error/logs directly related to your application

How do I enable it:

There are two ways to generate trace logs:

  1. Include the Debug class in your code and call its methods such as startMethodTracing() and stopMethodTracing(), to start and stop
    logging of trace information to disk. This option is very precise
    because you can specify exactly where to start and stop logging trace
    data in your code.

  2. Use the method profiling feature of DDMS to generate trace logs. This option is less precise because you do not modify code, but rather
    specify when to start and stop logging with DDMS. Although you have
    less control on exactly where logging starts and stops, this option is
    useful if you don’t have access to the application’s code, or if you
    do not need precise log timing.

But the following restrictions exist for the above

If you are using the Debug class, your application must have
permission to write to external storage (WRITE_EXTERNAL_STORAGE).

If you are using DDMS: Android 2.1 and earlier devices must have an SD
card present and your application must have permission to write to the
SD card. Android 2.2 and later devices do not need an SD card. The
trace log files are streamed directly to your development machine.

So in essence the traceFile access requires two things

1.) Permission to write a trace log file i.e. WRITE_EXTERNAL_STORAGE and READ_EXTERNAL_STORAGE for good measure

2.) An emulator with an SDCard attached with sufficient space. The doc doesnt say if this is only for DDMS but also for debug, so I am assuming this is also true for debugging via the application.

What do I do with this error:

Now the error is essentially a fall out of either not having the sdcard path to create a tracefile or not having permission to access it. This is an old thread, but the dev behind the bounty, check if are meeting the two prerequisites. You can then go search for the .trace file in the sdcard folder in your emulator. If it exists it shouldn’t be giving you this problem, if it doesnt try creating it by adding the startMethodTracing to your app.
I’m not sure why it automatically looks for this file when the logger kicks in. I think when an error/log event occurs , the logger internally tries to write to trace file and does not find it, in which case it throws the error.Having scoured through the docs, I don’t find too many references to why this is automatically on.
But in general this doesn’t affect you directly, you should check direct application logs/errors.
Also as an aside Android 2.2 and later devices do not need an SD card for DDMS trace logging. The trace log files are streamed directly to your development machine.

Additional information on Traceview:

Copying Trace Files to a Host Machine

After your application has run
and the system has created your trace files .trace on
a device or emulator, you must copy those files to your development
computer. You can use adb pull to copy the files. Here’s an example
that shows how to copy an example file, calc.trace, from the default
location on the emulator to the /tmp directory on the emulator host
machine:

adb pull /sdcard/calc.trace /tmp Viewing Trace Files in Traceview To
run Traceview and view the trace files, enter traceview
. For example, to run Traceview on the example files
copied in the previous section, use:

traceview /tmp/calc Note: If you are trying to view the trace logs of
an application that is built with ProGuard enabled (release mode
build), some method and member names might be obfuscated. You can use
the Proguard mapping.txt file to figure out the original unobfuscated
names. For more information on this file, see the Proguard
documentation.

I think any other answer regarding positioning of oncreate statements or removing uses-sdk are not related, but this is Android and I could be wrong. Would be useful to redirect this question to an android engineer or post it as a bug

More in the docs

Источник

This question has been asked no less than 17 times previously and to my great surprise, has never been answered! It has been closed, marked as duplicate and used to solve all manner of unrelated problems. I still cannot find an answer to the actual question in the title.

What seems to happen is that someone unfamiliar with Android runs a program, triggers an error, and gets a series of LogCat error messages. At the front of the LogCat trace appears the above, which they promptly post here. It is completely unrelated to the problem they are interested in solving. Once their problem is solved, they go away. The most popular answer of this kind is here: error opening trace file: No such file or directory (2).

My question is: what exactly does this message in LogCat actually mean? When does it happen, why does it happen, and is there anything I can (reasonably) do to make it go away? [My apps may have other errors, but they are not relevant here.]

Please do not vote to close this question as a duplicate unless or until you can point to another question that provides a sufficient explanation of this actual error message.

It should be said that we are developers (of course) writing code for the Android platform (of course) and we make extensive use of the Log class in our code. It seems that this message appears somewhere after the program starts and somewhere before the first use of the Log class.

The obvious answer would be that Log is expecting to find a specific folder or path, which happens not to exist. The answer may simply be to ensure that path exists, if we knew what it was or where it is set. We’re using ADT, as it happens.

So I picked a small app at random and ran it. Here is the LogCat.


05-23 18:22:10.948: D/dalvikvm(27917): Late-enabling CheckJNI
05-23 18:22:11.057: E/Trace(27917): error opening trace file: No such file or directory (2)
05-23 18:22:11.590: D/libEGL(27917): loaded /system/lib/egl/libEGL_mali.so
05-23 18:22:11.598: D/libEGL(27917): loaded /system/lib/egl/libGLESv1_CM_mali.so
05-23 18:22:11.613: D/libEGL(27917): loaded /system/lib/egl/libGLESv2_mali.so
05-23 18:22:11.677: D/OpenGLRenderer(27917): Enabling debug mode 0

There are no calls to Log in this one. It’s just Hello World.

Источник

Problem

You instrument an application with IBM® Rational® Test RealTime™. After that, you run the application from a command line or debugger. Then you get an error as follows.

[]"Cannot open traces file: No such file or directory"[]

Cause

Most likely this error appears, when you create the instrumented executable with Test RealTime GUI, and run it from a command line or in a debugger. The Test RealTime GUI creates the executable in the directory, that the target deployment port has specified; usually the directory is: <project>/<target>. The executable runs in the <project> directory and creates the trace files in the ./<target> directory.

The executable cannot create any trace files, when you run the executable in this directory: <project>/<target>. This is the directory, where it resides. The reason is, that the following directory does not exists: <project>/<target>/<target>. In that case the above error appears.

It is also possible, that the error comes up, when the user does not have write permissions in the trace directory. Although this directory does exists.

Resolving The Problem

In most cases, you can fix this error, by switching the execution of the application to the correct working directory.

[{«Product»:{«code»:»SSSHUF»,»label»:»Rational Test RealTime»},»Business Unit»:{«code»:»BU053″,»label»:»Cloud & Data Platform»},»Component»:»Not Applicable»,»Platform»:[{«code»:»PF002″,»label»:»AIX»},{«code»:»PF010″,»label»:»HP-UX»},{«code»:»PF016″,»label»:»Linux»},{«code»:»PF027″,»label»:»Solaris»},{«code»:»PF033″,»label»:»Windows»}],»Version»:»2003.06.00;2003.06.01;2003.06.12;2003.06.13;2003.06.15;7.0″,»Edition»:»»,»Line of Business»:{«code»:»LOB45″,»label»:»Automation»}}]

Источник

Моя основная работа — это, по большей части, развертывание систем ПО, то есть уйму времени я трачу, пытаясь ответить на такие вот вопросы:

  • У разработчика это ПО работает, а у меня нет. Почему?
  • Вчера это ПО у меня работало, а сегодня нет. Почему?

Это — своего рода отладка, которая немного отличается от обычной отладки ПО. Обычная отладка — это про логику кода, а вот отладка развертывания — это про взаимодействие кода и среды. Даже если корень проблемы — логическая ошибка, тот факт, что на одной машине все работает, а на другой — нет, означает, что дело неким образом в среде.

Поэтому вместо обычных инструментов для отладки вроде gdb у меня есть другой набор инструментов для отладки развертывания. И мой любимый инструмент для борьбы с проблемой типа «Почему это ПО у меня не пашет?» называется strace.

Что же такое strace?

strace — это инструмент для «трассировки системного вызова». Изначально создавался под Linux, но те же фишки по отладке можно проворачивать и с инструментами для других систем (DTrace или ktrace).

Основное применение очень просто. Надо лишь запустить strace c любой командой и он отправит в дамп все системные вызовы (правда, сперва, наверное, придется установить сам strace):

$ strace echo Hello
...Snip lots of stuff...
write(1, "Hellon", 6)                  = 6
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Что это за системные вызовы? Это нечто вроде API для ядра операционной системы. Давным-давно у ПО был прямой доступ к «железу», на котором оно работало. Если, например, нужно было отобразить что-нибудь на экране, оно играло с портами иили отображаемыми в память регистрами для видео-устройств. Когда стали популярны многозадачные компьютерные системы, воцарился хаос, потому что различные приложения дрались за «железо». Ошибки в одном приложении могли обрушить работу прочих, если не всю систему целиком. Тогда в ЦПУ появились режимы привилегий (или «кольцевая защита»). Самым привилегированным становилось ядро: оно получало полный доступ к «железу», плодя менее привилегированные приложения, которым уже приходилось запрашивать доступ у ядра для взаимодействия с «железом» — через системные вызовы.

На бинарном уровне системный вызов немного отличается от простого вызова функции, однако большинство программ используют обертку в стандартной библиотеке. Т.е. стандартная библиотека POSIX C содержит вызов функции write(), которая содержит весь зависящий от архитектуры код для системного вызова write.

Если вкратце, то любое взаимодействие приложения со своей средой (компьютерными системами) осуществляется через системные вызовы. Поэтому когда ПО на одно машине работает, а на другой нет, хорошо бы заглянуть в результаты трассировки системных вызовов. Если же конкретнее, то вот вам список типичных моментов, которые можно проанализировать при помощи трассировки системного вызова:

  • Консольный ввод-вывод
  • Сетевой ввод-вывод
  • Доступ к файловой системе и файловый ввод-вывод
  • Управление сроком жизни процессапотока
  • Низкоуровневое управление памятью
  • Доступ к драйверам особых устройств

Когда использовать strace?

В теории, strace используется с любыми программами в пользовательском пространстве, ведь любая программа в пользовательском пространстве должна делать системные вызовы. Он эффективнее работает с компилируемыми, низкоуровневыми программами, но и с высокоуровневыми языками вроде Python тоже работает, если получится продраться через дополнительный шум от среды исполнения и интерпретатора.

Во всем блеске strace проявляет себя во время отладки ПО, которое хорошо работает на одной машине, а на другой вдруг перестает работать, выдавая невнятные сообщения о файлах, разрешениях или неудачных попытках выполнить какие-то команды или еще что… Жаль, но не так хорошо он сочетается с высокоуровневыми проблемами типа ошибки проверки сертификата. Обычно тут требуется комбинация strace, иногда ltrace и инструментов более высокго уровня (вроде инструмента командной строки openssl для отладки сертификата).

Для примера берем работу на изолированном сервере, но трассировку системных вызовов зачастую можно выполнить и на более сложных платформах развертывания. Просто надо подобрать подходящий инструментарий.

Пример простой отладки

Скажем, хотите вы запустить потрясающее серверное приложение foo, а получается вот что:

$ foo
Error opening configuration file: No such file or directory

Очевидно, у него не получилось найти написанный вами конфигурационный файл. Так происходит, потому что иногда, когда менеджеры пакетов, компилируя приложение, переопределяют ожидаемое расположение файлов. И если следовать руководству по установке для одного дистрибутива, в другом находишь файлы совершенно не там, где ожидал. Решить проблему можно было бы за пару секунд, если бы сообщение об ошибке говорило, где следует искать конфигурационный файл, но ведь оно же не говорит. Так где искать?

Если есть доступ к исходному коду, можно прочесть его и все выяснить. Хороший запасной план, но не самое быстрое решение. Можно прибегнуть к пошаговому отладчику вроде gdb и посмотреть, что делает программа, но куда эффективнее использовать инструмент, который специально спроектирован показывать взаимодействие со средой: strace.

Вывод strace может показаться избыточным, но хорошие новости в том, что большую его часть можно смело игнорировать. Часто полезно использовать оператор -o, чтобы сохранять результаты трассировки в отдельный файл:

$ strace -o /tmp/trace foo
Error opening configuration file: No such file or directory
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL)                               = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25186, ...}) = 0
mmap(NULL, 25186, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2f12cf1000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "177ELF21133>1260A2"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2f12cef000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2f12b2e000
mprotect(0x7f2f12b50000, 1658880, PROT_NONE) = 0
mmap(0x7f2f12b50000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f2f12b50000
mmap(0x7f2f12c98000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7f2f12c98000
mmap(0x7f2f12ce5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f2f12ce5000
mmap(0x7f2f12ceb000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2f12ceb000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f2f12cf0500) = 0
mprotect(0x7f2f12ce5000, 16384, PROT_READ) = 0
mprotect(0x56363b08b000, 4096, PROT_READ) = 0
mprotect(0x7f2f12d1f000, 4096, PROT_READ) = 0
munmap(0x7f2f12cf1000, 25186)           = 0
openat(AT_FDCWD, "/etc/foo/config.json", O_RDONLY) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
brk(NULL)                               = 0x56363b3fb000
brk(0x56363b41c000)                     = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Error opening configuration file"..., 60) = 60
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Примерно вся первая страница вывода strace — это обычно низкоуровневая подготовка к запуску. (Много вызовов mmap, mprotect, brk для вещей типа обнаружения низкоуровневой памяти и отображение динамических библиотек.) Вообще-то, во время отладки выводы strace лучше читать с самого конца. Внизу будет вызов write, выводящий сообщение об ошибке. Смотрим выше, и видим первый ошибочный системный вызов — вызов openat, выдающий ошибку ENOENT («файл или каталог не найдены»), пытавшийся открыть /etc/foo/config.json. Вот, здесь и должен лежать конфигурационный файл.

Это был просто пример, но я бы сказал, что 90% времени, что я пользуюсь strace, ничего сильно сложнее этого выполнять и не приходится. Ниже — полное пошаговое руководство по отладке:

  • Расстроиться из-за невнятного сообщения о system-y ошибке от программы
  • Заново запустить программу со strace
  • Найти в результатах трассировки сообщение об ошибке
  • Идти выше, пока не уткнетесь в первый неудачный системный вызов

Весьма вероятно, что системный вызов в 4-м шаге покажет, что пошло не так.

Подсказки

Прежде чем показать пример более сложной отладки, открою вам несколько приемов для эффективного использования strace:

man — ваш друг

На многих *nix системах полный список системных вызовов к ядру можно получить, запустив man syscalls. Вы увидите вещи вроде brk(2), а значит, больше информации можно получить, запустив man 2 brk.

Небольшие грабли: man 2 fork показывает мне страницу для оболочки fork() в GNU libc, которая, оказывается, которая реализована с помощью вызова clone(). Семантика вызова fork остается той же, если написать программу, использующую fork(), и запустить трассировку — я не найду вызовов fork, вместо них будут clone(). Такие вот грабли только путают, если начать сравнивать исходник с выводом strace.

Используйте -о, чтобы сохранить вывод в файл

strace может сгенерировать обширный вывод, так что зачастую полезно хранить результаты трассировки в отдельных файлах (как в приведенном выше примере). А еще это помогает не спутать программный вывод с выводом strace в консоли.

Используйте -s, чтобы просмотреть больше данных аргумента

Вы наверняка заметили, что вторая половина сообщения об ошибке не показана в приведенном выше примере трассировки. Это потому, что strace по умолчанию показывает только первые 32 байта аргумента строки. Если хотите видеть больше, добавьте что-нибудь вроде -s 128 к вызову strace.

-у облегчает отслеживание файловсокетови проч.

«Все — файл» означает, что *nix системы выполняют все вводы-выводы, используя файловые дескрипторы, применимо ли именно к файлу или сети, или межпроцессным каналам. Это удобно для программирования, но мешает следить за тем, что происходит на самом деле, когда видите общие read и write в результатах трассировки системного вызова.

Добавив оператор -у, вы заставите strace аннотировать каждый файловый дескриптор в выводе с примечанием, на что он указывает.

Прикрепите к уже запущенному процессу с -p**

Как будет видно из приведенного ниже примера, иногда нужно производить трассировку программы, которая уже запущена. Если известно, что она запущена как процесс 1337 (скажем, из выводов ps), то можно осуществить трассировку ее вот так:

$ strace -p 1337
...system call trace output...

Возможно, вам нужны root-права.

Используйте -f, чтобы следить за дочерними процессами

strace по умолчанию трассирует всего один процесс. Если же этот процесс порождает дочерние процессы, то можно увидеть системный вызов для порождения дочернего процесса, но системные вызовы дочернего процесса не будут отображены.

Если считаете, что ошибка — в дочернем процессе, используйте оператор -f, это включит его трассировку. Минус этого в том, что вывод еще больше собьет вас с толку. Когда strace трассирует один процесс или одну ветку, он показывает единый поток событий вызовов. Когда он трассирует сразу несколько процессов, то, вы, возможно, увидите начало вызова, прерванного сообщением <unfinished …>, затем — кучку вызовов для других веток исполнения, и только потом — окончание первого с <… foocall resumed>. Или разделите все результаты трассировки по разным файлам, используя также оператор -ff (детали — в руководстве по strace).

Фильтруйте трассировку при помощи -e

Как видите, результат трассировки — реальная куча всех возможных системных вызовов. Флагом -e можно отфильтровать трассировку (см. руководство по strace). Главное преимущество в том, что запускать трассировку с фильтрацией быстрее, чем делать полную трассировку, а потом grep`ать. Если честно, то мне почти всегда пофиг.

Не все ошибки плохи

Простой и распространенный пример — программа, ищущая файл сразу в нескольких местах, вроде оболочки, ищущей, в которой корзинекаталоге содержится исполняемый файл:

$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
...

Эвристика типа «последний неудачный запрос перед сообщением об ошибке» хороша в поиске релевантных ошибок. Как бы там ни было, логично начинать с самого конца.

Понять системные вызовы хорошо помогают руководства по программированию на языке С

Стандартные вызовы к библиотекам С — не системные вызовы, но лишь тонкий поверхностный слой. Так что, если вы хоть немного понимаете, как и что делать в С, вам будет легче разобраться в результатах трассировки системного вызова. Например, у вас беда с отладкой вызовов к сетевым системам, просмотрите то же классическое «Руководство по сетевому программированию» Биджа.

Пример отладки посложнее

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

bcron — планировщик обработки задач, еще одна реализация демона *nix cron. Он установлен на сервере, но когда кто-то пытается редактировать расписание, происходит вот что:

# crontab -e -u logs
bcrontab: Fatal: Could not create temporary file

Ладненько, значит, bcron попытался написать некий файл, но у него не вышло, и он не признается почему. Расчехляем strace:

# strace -o /tmp/trace crontab -e -u logs
bcrontab: Fatal: Could not create temporary file
# cat /tmp/trace
...
openat(AT_FDCWD, "bcrontab.14779.1573691864.847933", O_RDONLY) = 3
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
read(3, "#Ansible: logsaggn20 14 * * * lo"..., 8192) = 150
read(3, "", 8192)                       = 0
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/bcron-spool"}, 110) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
write(3, "156:Slogs#Ansible: logsaggn20 1"..., 161) = 161
read(3, "32:ZCould not create temporary f"..., 8192) = 36
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
write(2, "bcrontab: Fatal: Could not creat"..., 49) = 49
unlink("bcrontab.14779.1573691864.847933") = 0
exit_group(111)                         = ?
+++ exited with 111 +++

Примерно в самом конце есть сообщение об ошибке write, но на этот раз кое-что отличается. Во-первых, нет релевантной ошибки системного вызова, которая обычно перед этим происходит. Во-вторых, видно, что где-то кто-то уже прочел сообщение об ошибке. Похоже на то, что настоящая проблема — где-то в другом месте, а bcrontab просто воспроизводит сообщение.

Если посмотреть на man 2 read, то можно увидеть, что первый аргумент (3) — это файловый дескриптор, который *nix и использует для всех обработок ввода-вывода. Как узнать, что представляет файловый дескриптор 3? В данном конкретном случае можно запустить strace с оператором -у (см. выше), и он автоматически расскажет, однако, чтобы вычислять подобные штуки, полезно знать, как читать и анализировать результаты трассировки.

Источником файлового дескриптора может быть один из многих системных вызовов (все зависит от того, для чего дескриптор — для консоли, сетевого сокета, собственно файла или чего-то иного), но как бы там ни было, вызовы мы ищем, возвращая 3 (т.е. ищем «= 3» в результатах трассировки). В этом результате их 2: openat в самом верху и socket в середине. openat открывает файл, но close(3) после этого покажет, что он закрывается снова. (Грабли: файловые дескрипторы могут использоваться заново, когда их открывают и закрывают). Вызов socket() подходит, поскольку он последний перед read(), и получается, что bcrontab работает с чем-то через сокет. Следующая строка показывает, что файловый дескриптор связан с unix domain socket по пути /var/run/bcron-spool.

Итак, надо найти процесс, привязанный к unix socket с другой стороны. Для этой цели есть парочка изящных трюков, и оба пригодятся для отладки серверных развертываний. Первый — использовать netstat или более новый ss (socket status). Обе команды показывают активные сетевые соединения системы и берут оператор -l для описания слушающих сокетов, а также оператор -p для отображения программ, подключенных к сокету в качестве клиента. (Полезных опций намного больше, но для этой задачи достаточно и этих двух.)

# ss -pl | grep /var/run/bcron-spool
u_str LISTEN 0   128   /var/run/bcron-spool 1466637   * 0   users:(("unixserver",pid=20629,fd=3))

Это говорит о том, что слушающий — это команда inixserver, работающая с ID процесса 20629. (И, по совпадению, она использует файловый дескриптор 3 в качестве сокета.)

Второй реально полезный инструмент для нахождения той же информации называется lsof. Он перечисляет все октрытые файлы (или файловые дескрипторы) в системе. Или же можно получить информацию об одном конкретном файле:

# lsof /var/run/bcron-spool
COMMAND   PID   USER  FD  TYPE  DEVICE              SIZE/OFF  NODE    NAME
unixserve 20629 cron  3u  unix  0x000000005ac4bd83  0t0       1466637 /var/run/bcron-spool type=STREAM

Процесс 20629 — это долгоживущий сервер, так что можно прикрепить к нему strace при помощи чего-то вроде strace -o /tmp/trace -p 20629. Если редактировать задание cron в другом терминале — получим вывод результатов трассировки с возникающей ошибкой. А вот и результат:

accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21181
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21181, si_uid=998, si_status=0, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 21181
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21200
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21200, si_uid=998, si_status=111, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 111}], WNOHANG|WSTOPPED, NULL) = 21200
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL

(Последний accept() не будет завершен при трассировке.) И снова, как ни жаль, но данный результат не содержит ошибки, которую мы ищем. Мы не видим ни одного сообщения, которые бы bcrontag посылал сокету или принимал от него. Вместо них сплошное управление процессом (clone, wait4, SIGCHLD и проч.) Этот процесс порождает дочерний процесс, который, как можно догадаться, и выполняет настоящую работу. И если надо поймать ее след, добавьте к вызову strace -f. Вот что мы найдем, поискав сообщение об ошибке в новом результате со strace -f -o /tmp/trace -p 20629:

21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

Вот, это уже кое-что. Процесс 21470 получает ошибку «отказано в доступе» при попытке создать файл по пути tmp/spool.21470.1573692319.854640 (относящийся к текущему рабочему каталогу). Если бы мы просто знали текущий рабочий каталог, мы бы знали и полный путь и смогли выяснили, почему процесс не может создать в нем свой временный файл. К несчастью, процесс уже вышел, поэтому не получится просто использовать lsof -p 21470 для того, чтобы найти текущий каталог, но можно поработать в обратную сторону — поискать системные вызовы PID 21470, меняющие каталог. (Если таких нет, PID 21470, должно быть, унаследовали их от родителя, и это уже через lsof -p не выяснить.) Этот системный вызов — chdir (что несложно выяснить при помощи современных сетевых поисковых движков). А вот и результат обратных поисков по результатам трассировки, до самого сервера PID 20629:

20629 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21470
...
21470 execve("/usr/sbin/bcron-spool", ["bcron-spool"], 0x55d2460807e0 /* 27 vars */) = 0
...
21470 chdir("/var/spool/cron")          = 0
...
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

(Если теряетесь, то вам, возможно, стоит прочесть мой предыдущий пост об управлении процессом *nix и оболочках.) Итак, сервер PID 20629 не получил разрешения создать файл по пути /var/spool/cron/tmp/spool.21470.1573692319.854640. Вероятнее всего, причиной тому — классические настройки разрешений файловой системы. Проверим:

# ls -ld /var/spool/cron/tmp/
drwxr-xr-x 2 root root 4096 Nov  6 05:33 /var/spool/cron/tmp/
# ps u -p 20629
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cron     20629  0.0  0.0   2276   752 ?        Ss   Nov14   0:00 unixserver -U /var/run/bcron-spool -- bcron-spool

Вот где собака зарыта! Сервер работает как пользовательский cron, но только у root есть разрешение записывать в каталог /var/spool/cron/tmp/. Простая команда chown cron /var/spool/cron/tmp/ заставит bcron работать правильно. (Если проблема заключалась не в этом, то следующий наиболее вероятный подозреваемый — модуль безопасности ядра типа SELinux или AppArmor, так что я бы проверил журнал сообщений ядра с помощью dmesg.)

Итого

Начинающему в результатах трассировки системных вызовов можно утонуть, но я, надеюсь, показал, что они — быстрый способ отладки целого класса распространенных проблем с развертыванием. Представьте, как пытаетесь отладить многопроцессный bcron, используя пошаговый отладчик.

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

Источник

I used all blobs from my device and from the global rom. On others roms it works well, only with the global it is not working. Here the logs:

01-27 11:34:03.243   522   522 E cutils-trace: Error opening trace file: No such file or directory (2)
01-27 11:34:03.243   517   517 E cutils-trace: Error opening trace file: No such file or directory (2)
01-27 11:34:03.256   517   517 W hwservicemanager: getTransport: Cannot find entry android.hidl.manager@1.0::IServiceManager/default in either framework or device manifest.
01-27 11:34:03.256   517   517 E SELinux : avc:  denied  { find } for interface=android.hardware.keymaster::IKeymasterDevice pid=522 scontext=u:r:recovery:s0 tcontext=u:object_r:hal_keymaster_hwservice:s0 tclass=hwservice_manager permissive=1
01-27 11:34:03.257   517   517 W hwservicemanager: getTransport: Cannot find entry android.hardware.keymaster@4.0::IKeymasterDevice/default in either framework or device manifest.
01-27 11:34:03.258   522   522 I ServiceManagement: getService: Trying again for android.hardware.keymaster@3.0::IKeymasterDevice/default...
01-27 11:34:04.258   522   522 W ServiceManagement: Waited one second for android.hardware.keymaster@3.0::IKeymasterDevice/default. Waiting another...
01-27 11:34:06.258   522   522 I chatty  : uid=0(root) /sbin/recovery identical 2 lines
01-27 11:34:07.258   522   522 W ServiceManagement: Waited one second for android.hardware.keymaster@3.0::IKeymasterDevice/default. Waiting another...
01-27 11:34:08.090   573   575 I adbd    : initializing functionfs
01-27 11:34:08.090   573   575 I adbd    : opening control endpoint /dev/usb-ffs/adb/ep0
01-27 11:34:08.092   573   575 I adbd    : functionfs successfully initialized
01-27 11:34:08.092   573   575 I adbd    : registering usb transport
01-27 11:34:08.092   573   577 E cutils-trace: Error opening trace file: No such file or directory (2)
01-27 11:34:08.258   522   522 W ServiceManagement: Waited one second for android.hardware.keymaster@3.0::IKeymasterDevice/default. Waiting another...

Starting TWRP 3.2.3-0-2315e859 on Mon Apr 13 01:02:20 1970
 (pid 521)
BOARD_HAS_NO_REAL_SDCARD := true
RECOVERY_SDCARD_ON_DATA := true
I:Lun file '/sys/class/android_usb/android0/f_mass_storage/lun0/file' does not exist, USB storage mode disabled
TW_INCLUDE_CRYPTO := true
I:TW_BRIGHTNESS_PATH := /sys/class/backlight/panel0-backlight/brightness
I:Found brightness file at '/sys/class/backlight/panel0-backlight/brightness'
I:TWFunc::Set_Brightness: Setting brightness control to 420
I:LANG: en
Starting the UI...
setting DRM_FORMAT_BGRA8888 and GGL_PIXEL_FORMAT_BGRA_8888
setting DRM_FORMAT_ARGB8888 and GGL_PIXEL_FORMAT_RGBA_8888
setting DRM_FORMAT_ARGB8888 and GGL_PIXEL_FORMAT_RGBA_8888
Using drm graphics.
I:TWFunc::Set_Brightness: Setting brightness control to 420
I:Loading package: splash (/twres/splash.xml)
I:Load XML directly
I:PageManager::LoadFileToBuffer loading filename: '/twres/splash.xml' directly
I:Checking resolution...
I:Scaling theme width 1.000000x and height 1.170833x, offsets x: 0 y: 0 w: 0 h: 0
I:Loading resources...
I:Loading variables...
I:Loading mouse cursor...
I:Loading pages...
I:Loading page splash
I:Switching packages (splash)
=> Linking mtab
=> Processing /etc/recovery.fstab
I:Reading /etc/recovery.fstab
I:Processing '/boot'
I:Processing '/cache'
I:Processing '/recovery'
I:Processing '/system'
I:Processing '/vendor'
I:Processing '/system_image'
I:Processing '/vendor_image'
I:Processing '/data'
I:FBE contents 'ice', filenames 'aes-256-cts'
I:Processing '/firmware'
I:Created '/firmware' folder.
I:Processing '/cust'
I:Created '/cust' folder.
I:Processing '/misc'
I:Processing '/modem'
I:Processing '/bluetooth'
I:Processing '/dsp'
I:Processing '/efs1'
I:Processing '/efs2'
I:Processing '/efsc'
I:Processing '/efsg'
I:Processing '/persist'
I:Created '/persist' folder.
I:TWFunc::Fixup_Time: Pre-fix date and time: 1970-04-13--01-02-20
I:TWFunc::Fixup_Time: Setting time offset from file /sys/class/rtc/rtc0/since_epoch
I:TWFunc::Fixup_Time: will attempt to use the ats files now.
I:TWFunc::Fixup_Time: Setting time offset from file /persist/time/ats_2, offset 1539800375167
I:TWFunc::Fixup_Time: Date and time corrected: 2019-01-27--19-21-56
I:Processing '/usb_otg'
I:Created '/usb_otg' folder.
I:Done processing fstab files
I:Setting up '/data' as data/media emulated storage.
I:mount -o bind '/data/media' '/sdcard' process ended with RC=0
I:mount -o bind '/data/media/0' '/sdcard' process ended with RC=0
I:File Based Encryption is present
e4crypt_initialize_global_de
calling retrieveAndInstallKey
Key exists, using: /data/unencrypted/key
Источник

Xdebug allows you to log all function calls, including parameters and
return values to a file in different formats.

Those so-called «function traces» can be a help for when you are new to an
application or when you are trying to figure out what exactly is going on when
your application is running. The function traces can optionally also show the
values of variables passed to the functions and methods, and also return
values. In the default traces those two elements are not available.

Output Formats #

There are three output formats. One is meant as a human readable trace, another
one is more suited for computer programs as it is easier to parse, and the last
one uses HTML for formatting the trace. You can switch between the
different formats with the xdebug.trace_format setting. There are a few settings
that control which information is written to the trace files. There are
settings for including variable assignments (xdebug.collect_assignments) and for
including return values (xdebug.collect_return) for example. The example below
shows what effect the different settings have for the human readable function
traces.

The Script


<?php
$str = "Xdebug";
function ret_ord( $c )
{
    return ord( $c );
}

foreach ( 

str_split( $str ) as $char )
{
    echo $char, ": ", ret_ord( $char ), "n";
}
?>


The Results

A typical output without the xdebug.collect_return or
xdebug.collect_assignments features turned on is the following trace:

TRACE START [2007-05-06 14:37:16]
    0.0003     114112   -> {main}() ../trace.php:0
    0.0004     114272     -> str_split('Xdebug') ../trace.php:8
    0.0007     117424     -> ret_ord($c = 'X') ../trace.php:10
    0.0007     117584       -> ord('X') ../trace.php:5
    0.0009     117584     -> ret_ord($c = 'd') ../trace.php:10
    0.0009     117584       -> ord('d') ../trace.php:5
    0.0010     117584     -> ret_ord($c = 'e') ../trace.php:10
    0.0011     117584       -> ord('e') ../trace.php:5
    0.0012     117584     -> ret_ord($c = 'b') ../trace.php:10
    0.0013     117584       -> ord('b') ../trace.php:5
    0.0014     117584     -> ret_ord($c = 'u') ../trace.php:10
    0.0014     117584       -> ord('u') ../trace.php:5
    0.0016     117584     -> ret_ord($c = 'g') ../trace.php:10
    0.0016     117584       -> ord('g') ../trace.php:5
    0.0019      41152
TRACE END   [2007-05-06 14:37:16]

There are a number of settings that affect the output of trace files.

To show the return values of all function and method calls,
turn on the xdebug.collect_return and xdebug.collect_assignments settings. 

TRACE START [2007-05-06 14:37:35]
    0.0003     114112   -> {main}() ../trace.php:0
    0.0004     114272     -> str_split('Xdebug') ../trace.php:8
                          >=> array (0 => 'X', 1 => 'd', 2 => 'e', 3 => 'b', 4 => 'u', 5 => 'g')
    0.0007     117424     -> ret_ord($c = 'X') ../trace.php:10
    0.0007     117584       -> ord('X') ../trace.php:5
                            >=> 88
                          >=> 88
    0.0009     117584     -> ret_ord($c = 'd') ../trace.php:10
    0.0009     117584       -> ord('d') ../trace.php:5
                            >=> 100
                          >=> 100
    0.0011     117584     -> ret_ord($c = 'e') ../trace.php:10
    0.0011     117584       -> ord('e') ../trace.php:5
                            >=> 101
                          >=> 101
    0.0013     117584     -> ret_ord($c = 'b') ../trace.php:10
    0.0013     117584       -> ord('b') ../trace.php:5
                            >=> 98
                          >=> 98
    0.0015     117584     -> ret_ord($c = 'u') ../trace.php:10
    0.0016     117584       -> ord('u') ../trace.php:5
                            >=> 117
                          >=> 117
    0.0017     117584     -> ret_ord($c = 'g') ../trace.php:10
    0.0018     117584       -> ord('g') ../trace.php:5
                            >=> 103
                          >=> 103
                        >=> 1
    0.0021      41152
TRACE END   [2007-05-06 14:37:35]

The default format is meant for consumption by humans. It is also possible to
generate a tab separated trace by setting xdebug.trace_format to 1.

The Xdebug source distribution has a script
that can be used to run some minimal analyses on these files. 

Version: 3.0.3
TRACE START [2007-05-06 18:29:01]
1	0	0	0.010870	114112	{main}	1	../trace.php	0
2	1	0	0.032009	114272	str_split	0	../trace.php	8
2	1	1	0.032073	116632
2	2	0	0.033505	117424	ret_ord	1	../trace.php	10
3	3	0	0.033531	117584	ord	0	../trace.php	5
3	3	1	0.033551	117584
2	2	1	0.033567	117584
2	4	0	0.033718	117584	ret_ord	1	../trace.php	10
3	5	0	0.033740	117584	ord	0	../trace.php	5
3	5	1	0.033758	117584
2	4	1	0.033770	117584
2	6	0	0.033914	117584	ret_ord	1	../trace.php	10
3	7	0	0.033936	117584	ord	0	../trace.php	5
3	7	1	0.033953	117584
2	6	1	0.033965	117584
2	8	0	0.034108	117584	ret_ord	1	../trace.php	10
3	9	0	0.034130	117584	ord	0	../trace.php	5
3	9	1	0.034147	117584
2	8	1	0.034160	117584
2	10	0	0.034302	117584	ret_ord	1	../trace.php	10
3	11	0	0.034325	117584	ord	0	../trace.php	5
3	11	1	0.034342	117584
2	10	1	0.034354	117584
2	12	0	0.034497	117584	ret_ord	1	../trace.php	10
3	13	0	0.034519	117584	ord	0	../trace.php	5
3	13	1	0.034536	117584
2	12	1	0.034549	117584
1	0	1	0.034636	117584
TRACE END   [2007-05-06 18:29:01]

VIM syntax file #

Xdebug ships with a VIM syntax file that syntax highlights the trace files:
xt.vim. In order to make VIM recognise this new format you need to perform the
following steps:

  1. Copy the xt.vim file to ~/.vim/syntax
  2. Edit, or create, ~/.vim/filetype.vim and add the following lines: 
    augroup filetypedetect
au BufNewFile,BufRead *.xt  setf xt
augroup END

With those settings made an opened trace file looks like: 

TRACE START [2007-05-15 20:06:02]
    0.0003     115208   -> {main}() ../trace.php:0
    0.0004     115368     -> str_split() ../trace.php:8
    0.0006     118520     -> ret_ord() ../trace.php:10
    0.0007     118680       -> ord() ../trace.php:5
    0.0008     118680     -> ret_ord() ../trace.php:10
    0.0009     118680       -> ord() ../trace.php:5
    0.0010     118680     -> ret_ord() ../trace.php:10
    0.0010     118680       -> ord() ../trace.php:5
    0.0012     118680     -> ret_ord() ../trace.php:10
    0.0012     118680       -> ord() ../trace.php:5
    0.0014     118680     -> ret_ord() ../trace.php:10
    0.0014     118680       -> ord() ../trace.php:5
    0.0016     118680     -> ret_ord() ../trace.php:10
    0.0016     118680       -> ord() ../trace.php:5
    0.0019      54880
TRACE END   [2007-05-15 20:06:02]

Folding also sorta works so you can use zc and zo to fold away
parts of the trace files.

Related Settings and Functions #

  • boolean xdebug.collect_assignments = false
  • boolean xdebug.collect_return = false
  • string xdebug.log =
  • integer xdebug.log_level = 7
  • string xdebug.mode = develop
  • string xdebug.output_dir = /tmp
  • string xdebug.start_with_request = default
  • integer xdebug.trace_format = 0
  • integer xdebug.trace_options = 0
  • string xdebug.trace_output_name = trace.%c
  • string xdebug.trigger_value = «»
  • boolean xdebug.use_compression = true
  • integer xdebug.var_display_max_children = 128
  • integer xdebug.var_display_max_data = 512
  • integer xdebug.var_display_max_depth = 3
  • xdebug_get_tracefile_name() : mixed
  • xdebug_info() : mixed
  • xdebug_start_trace() : ?string
  • xdebug_stop_trace() : false|string

Settings #

boolean xdebug.collect_assignments = false #

This setting, defaulting to 0, controls whether Xdebug should add
variable assignments to function traces. Assign-by-var (=&)
assignments are included too.

boolean xdebug.collect_return = false #

This setting, defaulting to 0, controls whether Xdebug should write the
return value of function calls to the trace files.

string xdebug.log = #

Configures Xdebug’s log file.

Xdebug will log to this file all file creations issues, Step Debugging
connection attempts, failures, and debug communication.

Enable this functionality by setting the value to a absolute path. Make sure
that the system user that PHP runs at (such as www-data if you are
running with Apache) can create and write to the file.

The file is opened in append-mode,
and will therefore not be overwritten by default. There is no concurrency
protection available.

The log file will include any attempt that Xdebug
makes to connect to an IDE:

[2693358] Log opened at 2020-09-02 07:19:09.616195
[2693358] [Step Debug] INFO: Connecting to configured address/port: localhost:9003.
[2693358] [Step Debug] ERR: Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port).
[2693358] [Profiler] ERR: File '/foo/cachegrind.out.2693358' could not be opened.
[2693358] [Profiler] WARN: /foo: No such file or directory
[2693358] [Tracing] ERR: File '/foo/trace.1485761369' could not be opened.
[2693358] [Tracing] WARN: /foo: No such file or directory
[2693358] Log closed at 2020-09-02 07:19:09.617510

It includes the opening time (2020-09-02 07:19:09.616195), the
IP/Hostname and port Xdebug is trying to connect to
(localhost:9003), and whether it succeeded (Connected to
client). The number in brackets ([2693358]) is the
Process ID.

It includes:

[2693358]
process ID in brackets
2020-09-02 07:19:09.616195
opening time

For Step Debugging:

INFO: Connecting to configured address/port: localhost:9003.
ERR: Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port).

For Profiling:

ERR: File '/foo/cachegrind.out.2693358' could not be opened.
WARN: /foo: No such file or directory

For Function Trace:

ERR: File '/foo/trace.1485761369' could not be opened.
WARN: /foo: No such file or directory

All warnings and errors are described on the Description of errors page, with
detailed instructions on how to resolve the problem, if possible. All errors are always logged through
PHP’s internal logging mechanism (configured with error_log
in php.ini). All warnings and errors also show up in the
diagnostics log that you can view by calling xdebug_info().

Step Debugger Communication

The debugging log can also log the communication between Xdebug and an IDE.
This communication is in XML, and starts with the <init XML
element:

<init
    xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
    fileuri="file:///home/httpd/www.xdebug.org/html/router.php"
    language="PHP" xdebug:language_version="7.4.11-dev"
    protocol_version="1.0" appid="2693358" idekey="XDEBUG_ECLIPSE">
        <engine version="3.0.0-dev"><![CDATA[Xdebug]]></engine>
        <author><![CDATA[Derick Rethans]]></author>
        <url><![CDATA[https://xdebug.org]]></url>
        <copyright><![CDATA[Copyright (c) 2002-2020 by Derick Rethans]]></copyright>
</init>

The fileuri attribute lists the entry point of your
application, which can be useful to compare to breakpoint_set
commands to see if path mappings are set-up correctly.

Beyond the <init element, you will find the configuration of
features:

<- feature_set -i 4 -n extended_properties -v 1
-> <response
       xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
       command="feature_set" transaction_id="4" feature="extended_properties" success="1">
   </response>

And continuation commands:

<- step_into -i 9
-> <response
       xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
       command="step_into" transaction_id="9"
       status="break" reason="ok">
           <xdebug:message filename="file:///home/httpd/www.xdebug.org/html/router.php" lineno="3">
           </xdebug:message>
   </response>

You can read about DBGP — A common debugger protocol specification at its dedicated documation page.

The xdebug.log_level setting controls how much information is
logged.

Many Linux distributions now use systemd, which
implements private tmp directories. This means that when PHP
is run through a web server or as PHP-FPM, the /tmp directory is
prefixed with something akin to: 

/tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg

This setting can additionally be configured through the
XDEBUG_CONFIG
environment variable.

integer xdebug.log_level = 7 #

Configures which logging messages should be added to the log file.

The log file is configured with the xdebug.log setting.

The following levels are supported:

Level Name Example
0 Criticals Errors in the configuration
1 Errors Connection errors
3 Warnings Connection warnings
5 Communication Protocol messages
7 Information Information while connecting
10 Debug Breakpoint resolving information

Criticals, errors, and warnings always show up in the
diagnostics log that you can view by calling xdebug_info().

Criticals and errors are additionally logged through
PHP’s internal logging mechanism (configured with error_log
in php.ini).

This setting can additionally be configured through the
XDEBUG_CONFIG
environment variable.

string xdebug.mode = develop #

This setting controls which Xdebug features are enabled.

This setting can only be set in php.ini or
files like 99-xdebug.ini that are read when a PHP process starts
(directly, or through php-fpm), but not in .htaccess and
.user.ini files, which are read per-request.

The following values are accepted:

off
Nothing is enabled. Xdebug does no work besides checking whether
functionality is enabled. Use this setting if you want close to 0
overhead.
develop
Enables Development Helpers including the overloaded var_dump().
coverage
Enables Code Coverage Analysis to generate code coverage reports, mainly in
combination with
PHPUnit.
debug
Enables Step Debugging. This can be used to step through your code while it
is running, and analyse values of variables.
gcstats
Enables Garbage Collection Statistics to collect statistics about PHP’s Garbage
Collection Mechanism.
profile
Enables Profiling, with which you can analyse performance bottlenecks
with tools like KCacheGrind.
trace
Enables the Function Trace feature, which allows you record every function
call, including arguments, variable assignment, and return value that is made
during a request to a file.

You can enable multiple modes at the same time by comma separating their
identifiers as value to xdebug.mode: xdebug.mode=develop,trace.

XDEBUG_MODE environment variable

You can also set Xdebug’s mode by setting the XDEBUG_MODE
environment variable on the command-line; this will take precedence over the
xdebug.mode setting, but will not change the value of the xdebug.mode
setting.

Some web servers have a configuration option to
prevent environment variables from being propagated to PHP and Xdebug.

For example, PHP-FPM has a clear_env
configuration setting that is on by default, which you will
need to turn off if you want to use XDEBUG_MODE.

Make sure that your web server does not clean the environment, or specifically
allows the XDEBUG_MODE environment variable to be passed on.

string xdebug.output_dir = /tmp #

The directory where Xdebug will write tracing, profiling, and garbage
collection statistics to. This directory needs to be writable for the system
user with which PHP is running.

This setting can be changed in php.ini, .htaccess
(and equivalent files), and within a PHP file with ini_set().

In some cases (when profiling, or when
xdebug.start_with_request=yes with tracing), Xdebug
creates the file before the script runs. In that case, changes made through
ini_set() will not be taken into account.

This setting can additionally be configured through the
XDEBUG_CONFIG
environment variable.

string xdebug.start_with_request = default #

A Function Trace, Garbage Collection Statistics, Profiling, or Step Debugging
can be activated at the start of a PHP request. Whether this happens depends on
the value of this setting:

yes

The functionality starts when the PHP request starts, and before any PHP
code is run.

For example xdebug.mode=trace and
xdebug.start_with_request=yes starts a Function Trace for the
whole request.

no

The functionality does not get activated when the request starts.

You can still start a Function Trace with xdebug_start_trace(),
Step Debugging with xdebug_break(), or Garbage Collection Statistics with xdebug_start_gcstats().

trigger

The functionality only gets activated when a specific trigger is present
when the request starts.

The name of the trigger is XDEBUG_TRIGGER, and Xdebug checks
for its presence in either $_ENV (environment variable),
$_GET or $_POST variable, or $_COOKIE
(HTTP cookie name).

There is a legacy fallback to a functionality specific trigger name:
XDEBUG_PROFILE (for Profiling), XDEBUG_TRACE
(for a Function Trace), and XDEBUG_SESSION (for
Step Debugging).

There is another legacy trigger. If you set the XDEBUG_CONFIG
environment variable to any value, then Xdebug will also get activated.

Debug session management for Step Debugging is also
available through XDEBUG_SESSION_START.

With xdebug.trigger_value you can control which specific trigger value will
activate the trigger. If xdebug.trigger_value is set to an empty
string, any value will be accepted.

default

The default value depends on xdebug.mode:

  • debug: trigger
  • gcstats: no
  • profile: yes
  • trace: trigger

integer xdebug.trace_format = 0 #

The format of the trace file.

Value Description
0 shows a human readable indented trace file with:
time index, memory usage, memory delta,
level, function name,
function parameters,
filename and line number.
1 writes a computer readable format which has two
different records. There are different records for entering a stack frame, and
leaving a stack frame. The table below lists the fields in each type of record.
Fields are tab separated.
2 writes a trace formatted in (simple) HTML.

Fields for the computerized format:

Record type 1 2 3 4 5 6 7 8 9 10 11 12 — …
Entry level function # always ‘0’ time index memory usage function name user-defined (1) or internal function (0) name of the include or require file filename line number no. of arguments arguments (as many as specified in field 11) — tab separated
Exit level function # always ‘1’ time index memory usage empty
Return level function # always ‘R’ empty return value empty

See the introduction for Function Trace for a few examples.

integer xdebug.trace_options = 0 #

When set to ‘1’ the trace files will be appended to, instead of
being overwritten in subsequent requests.

string xdebug.trace_output_name = trace.%c #

This setting determines the name of the file that is used to dump
traces into. The setting specifies the format with format specifiers, very
similar to sprintf() and strftime(). There are several format specifiers
that can be used to format the file name. The ‘.xt’ extension is always added
automatically.

The possible format specifiers are:

Specifier Meaning Example Format Example Filename
%c crc32 of the current working directory trace.%c trace.1258863198.xt
%p pid trace.%p trace.5174.xt
%r random number trace.%r trace.072db0.xt
%s

script name 2

 cachegrind.out.%s cachegrind.out._home_httpd_html_test_xdebug_test_php
%t timestamp (seconds) trace.%t trace.1179434742.xt
%u timestamp (microseconds) trace.%u trace.1179434749_642382.xt
%H $_SERVER[‘HTTP_HOST’] trace.%H trace.kossu.xt
%R $_SERVER[‘REQUEST_URI’] trace.%R trace._test_xdebug_test_php_var=1_var2=2.xt
%U $_SERVER[‘UNIQUE_ID’] 3 trace.%U trace.TRX4n38AAAEAAB9gBFkAAAAB.xt
%S session_id (from $_COOKIE if set) trace.%S trace.c70c1ec2375af58f74b390bbdd2a679d.xt
%% literal % trace.%% trace.%%.xt

2 This one is only available for trace file names since Xdebug 2.6.

3 New in version 2.2. This one is set by Apache’s mod_unique_id module

string xdebug.trigger_value = «» #

This setting can be used when xdebug.start_with_request is set to
trigger, which is the default for Step Debugging and Function Trace.

In trigger mode, Xdebug will only start its
functionality when the XDEBUG_TRIGGER is set in the environment,
or when the XDEBUG_TRIGGER GET, POST, or COOKIE variable is
set.

The legacy names XDEBUG_SESSION (for Step Debugging),
XDEBUG_PROFILE (for Profiling), and XDEBUG_TRACE
(for Function Trace) can also be used instead of XDEBUG_TRIGGER.

Normally, Xdebug does not look at which value is actually used. If this
setting is set to a non-empty string, then Xdebug will only trigger if the
value matches the value of this setting.

With the following settings:

xdebug.mode=profile
xdebug.start_with_request=trigger
xdebug.trigger_value=StartProfileForMe

Xdebug’s profiler will only start when either the environment variable
XDEBUG_TRIGGER is set to StartProfileForMe, the GET
or POST variable XDEBUG_TRIGGER is set to
StartProfileForMe, or when the cookie XDEBUG_TRIGGER
has the value StartProfileForMe.

From Xdebug 3.1, it is possible to configure multiple values by using a
comma separated list. In that case, Xdebug will trigger if the supplied value
matches any of the entries that are configured through this setting:

xdebug.trigger_value=StartDebuggerForMe,StartDebuggerForYou

See also:

xdebug.start_with_request#trigger
For how the triggering mechanism works, and which environment and server variables Xdebug acts on.

boolean xdebug.use_compression = true #

Introduced in Xdebug >= 3.1

If enabled, the Function Trace and Profiling features will create GZip
compressed files as output. This reduces diskspace.

If GZip compression is not supported by Xdebug, because it was not compiled
in, then Xdebug will add a warning to its log and xdebug_info()
diagnostics section.

It is enabled by default if Xdebug has GZip support, and disable if Xdebug
does not have GZip support.

The QCacheGrind tool that you can use to visualise profiling information
does not support reading GZip compressed profile files, whereas KCacheGrind and
PhpStorm do. If you are a QCacheGrind user, you should set
xdebug.use_compression to false.

integer xdebug.var_display_max_children = 128 #

Controls the amount of array children and object’s properties are shown
when variables are displayed with either xdebug_var_dump(),
xdebug.show_local_vars or when making a Function Trace.

To disable any limitation, use -1 as value.

This setting does not have any influence on the number of children that is
send to the client through the Step Debugging feature.

integer xdebug.var_display_max_data = 512 #

Controls the maximum string length that is shown
when variables are displayed with either xdebug_var_dump(),
xdebug.show_local_vars or when making a Function Trace.

To disable any limitation, use -1 as value.

This setting does not have any influence on the number of children that is
send to the client through the Step Debugging feature.

integer xdebug.var_display_max_depth = 3 #

Controls how many nested levels of array elements and object properties are
when variables are displayed with either xdebug_var_dump(),
xdebug.show_local_vars or when making a Function Trace.

The maximum value you can select is 1023. You can also use -1 as
value to select this maximum number.

This setting does not have any influence on the number of children that is
send to the client through the Step Debugging feature.

Setting the value to a high number could potentially result in
PHP using up all the available memory, so use with caution.

Functions #

xdebug_get_tracefile_name()
: mixed
#

Returns the name of the function trace file

Returns the name of the file which is used to trace the output of this
script to, or null if tracing is not active. This is useful when
the trace was started automatically because xdebug.start_with_request was set to
yes.

xdebug_info( string $category = null )
: mixed
#

Show and retrieve diagnostic information

This function presents APIs to retrieve information about Xdebug itself. Which
information gets returned, or displayed, depends on which arguments, or none at
all, are given.

$category =

Without arguments, this function returns an HTML page which shows diagnostic
information. It is analogous to PHP’s phpinfo() function.

The HTML output includes which mode is active, what the settings are, and
diagnostic information in case there are problems with debugging connections,
opening of files, etc.

Each warning and error in the diagnostics log also links through to the
Description of errors documentation page.

$category = 'mode' (New in Xdebug 3.1)

The function returns an array of all the
enabled modes, whether through xdebug.mode or the
XDEBUG_MODE environment variable.

Example:


<?php
var_dump( xdebug_info( 'mode' ) );
?>

Returns:

array(3) {
  [0] =>
  string(5) "debug"
  [1] =>
  string(7) "develop"
  [2] =>
  string(5) "trace"
}

$category = 'extension-flags' (New in Xdebug 3.1)

The function returns an array of all the compile flags that were enabled when
running ./configure as part of Xdebug’s compilation process.

The only flag that is available, is the compression flag. If this
flag is enabled, then the xdebug.use_compression setting is available, and enabled by default.

Profiling and Function Trace will create GZip compressed files if the
xdebug.use_compression setting is turned on (the default).

Example:


<?php
var_dump( xdebug_info( 'extension-flags' ) );
?>

Returns:

array(1) {
  [0] =>
  string(11) "compression"
}

xdebug_start_trace( ?string $traceFile = null, int $options = 0 )
: ?string
#

Starts a new function trace

Start tracing function calls from this point to the file in the
$trace_file parameter. If no filename is given, then the trace file will
be placed in the directory as configured by the xdebug.output_dir setting.

In case a file name is given as first parameter, the name is relative
to the current working directory. This current working directory might be
different than you expect it to be, so please use an absolute path in case you
specify a file name. Use the PHP function getcwd() to figure out what the current
working directory is.

The name of the trace file is {$trace_file}.xt. If the trace was started at
the beginning of the request because xdebug.start_with_request is set to
yes, then the filename depends on the
xdebug.trace_output_name setting.

The options parameter is a bitfield;
currently there are three options:

The options parameter is a bitfield;
currently there are three options:

XDEBUG_TRACE_APPEND (1)
makes the trace file open in append mode rather than
overwrite mode
XDEBUG_TRACE_COMPUTERIZED (2)
creates a trace file with
the format as described under 1 «xdebug.trace_format».
XDEBUG_TRACE_HTML (4)
creates a trace file as an HTML table
XDEBUG_TRACE_NAKED_FILENAME (8)
Normally, Xdebug always adds «.xt» to the end of the filename that you
pass in as first argument to this function. With the
XDEBUG_TRACE_NAKED_FILENAME flag set, «.xt» is not added.

The settings xdebug.collect_assignments and xdebug.collect_return influence what
information is logged to the trace file and the setting xdebug.trace_format
influences the format of the trace file.

The full path and filename to which Xdebug traces is returned from this
function. This will be either the filename you pass in (potentially with «.xt»
added), or the auto generated filename if no filename has been passed in.

xdebug_stop_trace()
: false|string
#

Stops the current function trace

Stop tracing function calls and closes the trace file.

The function returns the filename of the file where the trace was written to.

Источник

Я думаю в этом проблема

Немного фона

Traceview — это графическое средство просмотра журналов выполнения, которые вы создаете с помощью класса Debug для регистрации информации трассировки в своем коде. Traceview может помочь вам отладить ваше приложение и профилировать его производительность. Включение этого создает .trace файл в корневой папке SD-карты, который затем может быть извлечен ADB и обработан файлом traceview bat для обработки. Он также может быть добавлен DDMS.

Это система, используемая внутри регистратора. В общем, если вы не используете traceview для извлечения файла трассировки, эта ошибка не должна вас беспокоить. Вы должны смотреть на ошибки/журналы, непосредственно связанные с вашим приложением.

Как мне включить это:

Есть два способа создания журналов трассировки:

  1. Включите класс Debug в свой код и вызовите его методы, такие как startMethodTracing() и stopMethodTracing(), чтобы начать и остановить запись информации о трассировке на диск. Этот параметр очень точен, потому что вы можете указать, где именно начинать и останавливать регистрацию данных трассировки в вашем коде.

  2. Используйте функцию профилирования методов DDMS для создания журналов трассировки. Этот вариант менее точен, поскольку вы не изменяете код, а указываете, когда начинать и останавливать регистрацию с помощью DDMS. Хотя у вас меньше контроля над тем, где именно начинается и где останавливается ведение журнала, этот параметр полезен, если у вас нет доступа к коду приложения или если вам не требуется точное время ведения журнала.

Но для вышеуказанного существуют следующие ограничения

Если вы используете класс Debug, ваше приложение должно иметь разрешение на запись во внешнее хранилище (WRITE_EXTERNAL_STORAGE).

Если вы используете DDMS: устройства Android 2.1 и более ранних версий должны иметь SD-карту, и ваше приложение должно иметь разрешение на запись на SD-карту. Для устройств Android 2.2 и более поздних версий SD-карта не требуется. Файлы журнала трассировки передаются непосредственно на ваш компьютер для разработки.

Таким образом, доступ к traceFile требует двух вещей:

1.) Разрешение на запись файла журнала трассировки, т.е. WRITE_EXTERNAL_STORAGE и READ_EXTERNAL_STORAGE для хорошей меры

2.) Эмулятор с прикрепленной SD-картой с достаточным пространством. В документе не сказано, предназначено ли это только для DDMS, но также и для отладки, поэтому я предполагаю, что это верно и для отладки через приложение.

Что мне делать с этой ошибкой:

Теперь ошибка, по сути, связана с отсутствием пути к SD-карте для создания файла трассировки или отсутствием разрешения на доступ к нему. Это старая ветка, но разработчик, стоящий за наградой, проверьте, соблюдаются ли два предварительных условия. Затем вы можете отправиться на поиски .trace файл в папке sdcard в вашем эмуляторе. Если он существует, он не должен доставлять вам эту проблему, если он не пытается создать его, добавив startMethodTracing в ваше приложение.
Я не уверен, почему он автоматически ищет этот файл, когда запускается регистратор. Я думаю, что когда происходит событие ошибки/журнала, регистратор внутренне пытается записать в файл трассировки и не находит его, и в этом случае он выдает ошибку .Изучив документацию, я не нашел слишком много ссылок на то, почему это включается автоматически. Но в целом это не влияет на вас напрямую, вы должны проверять логи/ошибки приложений напрямую. Кроме того, для устройств Android 2.2 и более поздних версий не требуется SD-карта для ведения журнала трассировки DDMS. Файлы журнала трассировки передаются непосредственно на ваш компьютер для разработки.

Дополнительная информация о Traceview:

Копирование файлов трассировки на хост-компьютер

После запуска приложения и создания системой файлов трассировки .trace на устройстве или эмуляторе вы должны скопировать эти файлы на компьютер для разработки. Вы можете использовать adb pull для копирования файлов. Вот пример, показывающий, как скопировать пример файла calc.trace из расположения по умолчанию на эмуляторе в каталог /tmp на хост-компьютере эмулятора:

adb pull /sdcard/calc.trace /tmp Просмотр файлов трассировки в Traceview Чтобы запустить Traceview и просмотреть файлы трассировки, введите traceview . Например, чтобы запустить Traceview для файлов примеров, скопированных в предыдущем разделе, используйте:

traceview /tmp/calc Примечание. Если вы пытаетесь просмотреть журналы трассировки приложения, созданного с включенным ProGuard (сборка в режиме выпуска), имена некоторых методов и членов могут быть запутаны. Вы можете использовать файл Mapping.txt Proguard, чтобы выяснить исходные незашифрованные имена. Дополнительные сведения об этом файле см. в документации Proguard.

Я думаю, что любой другой ответ относительно позиционирования oncreate заявлений или удаления uses-sdk не связаны, но это Android и я могу ошибаться. Было бы полезно перенаправить этот вопрос инженеру Android или опубликовать его как ошибку.

Больше в Документы

Источник

Это происходит из-за того, что вы не установили minSdkVersion или targetSdkVersion на своем компьютере. Я тестировал прямо сейчас.

Например, если у вас есть эти строки в вашем Manifest.xml:

<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="17" />

И вы установили на свой компьютер только API17, он сообщит вам об ошибке. Если вы хотите протестировать его, попробуйте установить другую версию API (в данном случае API 8).

Тем не менее, это не важная ошибка. Это не значит, что ваше приложение неправильное.

Извините за выражение моего лица. Английский не мой язык. До свидания!

Я думаю в этом проблема

Немного предыстории

Traceview — это графическое средство просмотра журналов выполнения, которые вы создаете с помощью класса Debug для регистрации информации трассировки в вашем коде. Traceview может помочь вам отладить ваше приложение и профилировать его производительность. Включение этого параметра создает файл .trace в корневой папке SDCard, который затем может быть извлечен ADB и обработан файлом bat traceview для обработки. Он также может быть добавлен DDMS.

Это система, используемая самим регистратором. В общем, если вы не используете traceview для извлечения файла трассировки, эта ошибка не должна вас беспокоить. Вы должны смотреть на ошибки / журналы, непосредственно связанные с вашим приложением.

Как мне его включить:

Есть два способа создания журналов трассировки:

  1. Включите класс Debug в свой код и вызовите его методы, такие как startMethodTracing() и stopMethodTracing() , чтобы начать и остановить запись информации трассировки на диск. Этот параметр очень точен, потому что вы можете точно указать, где начинать и прекращать регистрацию данных трассировки в вашем коде.

  2. Используйте функцию профилирования методов DDMS для создания журналов трассировки. Этот параметр менее точен, поскольку вы не изменяете код, а скорее указываете, когда начинать и останавливать ведение журнала с помощью DDMS. Хотя у вас меньше контроля над тем, где именно начинается и заканчивается ведение журнала, этот параметр полезен, если у вас нет доступа к коду приложения или если вам не требуется точное время ведения журнала.

Но для указанных выше ограничений существуют следующие ограничения.

Если вы используете класс Debug, ваше приложение должно иметь разрешение на запись во внешнее хранилище ( WRITE_EXTERNAL_STORAGE ).

Если вы используете DDMS: устройства Android 2.1 и более ранних версий должны иметь SD-карту, а ваше приложение должно иметь разрешение на запись на SD-карту. Для устройств Android 2.2 и более поздних версий не требуется SD-карта. Файлы журнала трассировки передаются прямо на ваш компьютер для разработки.

Таким образом, по сути, для доступа к traceFile требуются две вещи

1.) Разрешение на запись файла журнала трассировки, т.е. WRITE_EXTERNAL_STORAGE и READ_EXTERNAL_STORAGE для хорошей оценки.

2.) Эмулятор с прикрепленной SDCard с достаточным пространством. В документе не говорится, относится ли это только к DDMS, но также и к отладке, поэтому я предполагаю, что это также верно для отладки через приложение.

Что мне делать с этой ошибкой:

Теперь ошибка, по сути, связана с отсутствием пути к SD-карте для создания файла трассировки или отсутствием разрешения на доступ к нему. Это старый поток, но разработчик, стоящий за наградой, должен проверить, соответствуют ли два предварительных условия. Затем вы можете найти файл .trace в папке SDCard в вашем эмуляторе. Если он существует, это не должно вызывать у вас этой проблемы, если он не пытается создать его, добавив startMethodTracing в ваше приложение.
Я не уверен, почему он автоматически ищет этот файл, когда срабатывает регистратор. Я думаю, когда происходит событие ошибки / журнала, регистратор внутренне пытается записать в файл трассировки и не находит его, и в этом случае он выдает ошибку .Просмотрев документацию, я не нашел слишком много ссылок на то, почему это включается автоматически. Но в целом это не влияет на вас напрямую, вам следует напрямую проверять логи / ошибки приложения. Кроме того, помимо Android 2.2 и более поздних версий устройствам не требуется SD-карта для ведения журнала трассировки DDMS. Файлы журнала трассировки передаются прямо на ваш компьютер для разработки.

Дополнительная информация о Traceview:

Копирование файлов трассировки на хост-машину

После того, как ваше приложение будет запущено и система создаст ваши файлы трассировки .trace на устройстве или в эмуляторе, вы должны скопировать эти файлы на свой компьютер для разработки. Вы можете использовать adb pull для копирования файлов. Вот пример, который показывает, как скопировать примерный файл calc.trace из местоположения по умолчанию на эмуляторе в каталог / tmp на хост-машине эмулятора:

adb pull /sdcard/calc.trace / tmp Просмотр файлов трассировки в Traceview Чтобы запустить Traceview и просмотреть файлы трассировки, введите traceview. Например, чтобы запустить Traceview для файлов примеров, скопированных в предыдущем разделе, используйте:

traceview / tmp / calc Примечание. Если вы пытаетесь просмотреть журналы трассировки приложения, созданного с включенным ProGuard (сборка в режиме выпуска), некоторые имена методов и членов могут быть запутаны. Вы можете использовать файл Proguard mapping.txt, чтобы выяснить исходные не запутанные имена. Для получения дополнительной информации об этом файле см. Документацию Proguard.

Я думаю, что любой другой ответ относительно позиционирования операторов oncreate или удаления uses-sdk не имеет отношения, но это Android, и я могу ошибаться. Было бы полезно перенаправить этот вопрос инженеру Android или опубликовать его как ошибку

Подробнее в документации

Попробуйте удалить uses-sdk части формы AndroidManifest.xml файла. у меня это сработало!

Не используйте виртуальное устройство Android со слишком низкой конфигурацией. Пусть будет средним.

Напишите весь свой код под этими двумя строками: —

    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

У меня это сработало без повторной установки.

Я не хотел все переустанавливать, потому что у меня установлено так много версий SDK, и моя среда разработки настроена правильно. На повторную настройку уходит слишком много времени.

Для меня сработало удаление, а затем воссоздание виртуального устройства Android с обязательным вводом значения для размера SD-карты (я использовал 200 МБ).

screenshot of the AVD creation screen

Дополнительная информация:

Хотя вышеупомянутая проблема временно устраняет проблему, она повторяется. Я просто попробовал свое приложение в Android Studio и увидел это в журнале вывода, чего раньше не замечал в Eclipse:

"/Applications/Android Studio.app/sdk/tools/emulator" -avd AVD_for_Nexus_S_by_Google -netspeed full -netdelay none

WARNING: Data partition already in use. Changes will not persist!
WARNING: SD Card image already in use: /Users/[user]/.android/avd/AVD_for_Nexus_S_by_Google.avd/sdcard.img
ko:Snapshot storage already in use: /Users/[user]/.android/avd/AVD_for_Nexus_S_by_Google.avd/snapshots.img

Я подозреваю, что изменения в журнале не сохраняются на SD-карту, поэтому, когда LogCat пытается получить доступ к журналам, их там нет, что вызывает сообщение об ошибке. Удаление AVD и его воссоздание удаляют файлы, и следующий запуск — это новый запуск, позволяющий LogCat получить доступ к виртуальной SD-карте.

У вас не будет доступа к вашей реальной SD-карте в эмуляторе. Вам нужно будет выполнить шаги, описанные в этом руководстве, чтобы направить ваш эмулятор в каталог в вашей среде разработки, выступающий в качестве SD-карты.

На самом деле проблема в том, что либо /sys/kernel/debug не смонтировано, либо работающее ядро ​​не имеет скомпилированных трассировщиков ftrace, поэтому /sys/kernel/debug/tracing недоступен. Это код, выдающий ошибку ( platform_frameworks_native/libs/utils/Trace.cpp ):

void Tracer::init() {
    Mutex::Autolock lock(sMutex);

    if (!sIsReady) {
        add_sysprop_change_callback(changeCallback, 0);

        const char* const traceFileName =
                "/sys/kernel/debug/tracing/trace_marker";
        sTraceFD = open(traceFileName, O_WRONLY);
        if (sTraceFD == -1) {
            ALOGE("error opening trace file: %s (%d)", strerror(errno), errno);
            sEnabledTags = 0;   // no tracing can occur
        } else {
            loadSystemProperty();
        }

        android_atomic_release_store(1, &sIsReady);
    }
}

Сообщение журнала определенно могло бы быть немного более информативным.

Источник

D@n

1 / 1 / 3

Регистрация: 01.03.2013

Сообщений: 22

1

10.03.2014, 23:56. Показов 2381. Ответов 1

Метки нет (Все метки)

Наткнулся на исходники эмулятора nes, после выбора файла эмуляции .nes, возникает ошибка «error opening trace file no such file or directory (2)»
log

Кликните здесь для просмотра всего текста

03-10 19:35:04.254: I/dalvikvm(2228): Turning on JNI app bug workarounds for target SDK version 8…
03-10 19:35:04.262: E/Trace(2228): error opening trace file: No such file or directory (2)
03-10 19:35:04.270: D/AndroidRuntime(2228): Shutting down VM
03-10 19:35:04.270: W/dalvikvm(2228): threadid=1: thread exiting with uncaught exception (group=0xa624f288)
03-10 19:35:04.270: E/AndroidRuntime(2228): FATAL EXCEPTION: main
03-10 19:35:04.270: E/AndroidRuntime(2228): java.lang.UnsatisfiedLinkError: Couldn’t load emu: findLibrary returned null
03-10 19:35:04.270: E/AndroidRuntime(2228): at java.lang.Runtime.loadLibrary(Runtime.java:365)
03-10 19:35:04.270: E/AndroidRuntime(2228): at java.lang.System.loadLibrary(System.java:535)
03-10 19:35:04.270: E/AndroidRuntime(2228): at com.androidemu.Emulator.createInstance(Emulator.ja va:42)
03-10 19:35:04.270: E/AndroidRuntime(2228): at com.androidemu.nes.EmulatorActivity.onCreate(Emula torActivity.java:127)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.Activity.performCreate(Activity.java:5 008)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.Instrumentation.callActivityOnCreate(I nstrumentation.java:1079)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.ActivityThread.performLaunchActivity(A ctivityThread.java:2023)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.ActivityThread.handleLaunchActivity(Ac tivityThread.java:2084)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.ActivityThread.access$600(ActivityThre ad.java:130)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.ActivityThread$H.handleMessage(Activit yThread.java:1195)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.os.Handler.dispatchMessage(Handler.java:99 )
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.os.Looper.loop(Looper.java:137)
03-10 19:35:04.270: E/AndroidRuntime(2228): at android.app.ActivityThread.main(ActivityThread.jav a:4745)
03-10 19:35:04.270: E/AndroidRuntime(2228): at java.lang.reflect.Method.invokeNative(Native Method)
03-10 19:35:04.270: E/AndroidRuntime(2228): at java.lang.reflect.Method.invoke(Method.java:511)
03-10 19:35:04.270: E/AndroidRuntime(2228): at com.android.internal.os.ZygoteInit$MethodAndArgsCa ller.run(ZygoteInit.java:786)
03-10 19:35:04.270: E/AndroidRuntime(2228): at com.android.internal.os.ZygoteInit.main(ZygoteInit .java:553)
03-10 19:35:04.270: E/AndroidRuntime(2228): at dalvik.system.NativeStart.main(Native Method)

Manifest

Кликните здесь для просмотра всего текста

Java 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.androidemu.nes"
        android:versionCode="61"
        android:versionName="2.5"
        android:installLocation="preferExternal">
 
    <uses-sdk android:minSdkVersion="8" />
   
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
    
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.BLUETOOTH" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.VIBRATE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
 
    <application android:label="@string/app_label"
            android:icon="@drawable/app_icon">
 
        <activity android:name="MainActivity"
                android:configChanges="orientation|keyboardHidden">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
 
        <activity-alias android:name="CreateShortcuts"
                android:targetActivity="MainActivity"
                android:label="@string/launcher_shortcut_name">
            <intent-filter>
                <action android:name="android.intent.action.CREATE_SHORTCUT" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity-alias>
 
        <activity android:name="FileChooser" />
        <activity android:name="StateSlotsActivity"
                android:theme="@android:style/Theme.Dialog" />
        <activity android:name="KeyProfilesActivity"/>
        <activity android:name="HelpActivity" />
        <activity android:name="DeviceListActivity"
                android:theme="@android:style/Theme.Dialog"
                android:configChanges="orientation|keyboardHidden" />
 
        <activity android:name="CheatsActivity" android:process=":emulator"/>
        <activity android:name="EmulatorSettings" android:process=":emulator"/>
 
        <activity android:name="EmulatorActivity"
                android:process=":emulator"
                android:launchMode="singleTask"
                android:configChanges="orientation|keyboardHidden">
            <intent-filter>
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:scheme="file" />
                <data android:mimeType="application/zip" />
                <data android:mimeType="application/octet-stream" />
            </intent-filter>
        </activity>
 
        <service android:name="EmulatorService" android:process=":emulator"/>
 
    </application>
</manifest>

Исходники Nesoid.rar

google не помогает)), а я причин возникновения ошибки попросту не вижу, мало опыта, нужна помощь

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь



0

374 / 361 / 52

Регистрация: 02.10.2009

Сообщений: 712

Записей в блоге: 4

11.03.2014, 00:25

2

Причина проста, никто не потрудился собрать исходники из папки neslib. Собственно, по этой причине findLibrary и возвращает null, библиотеки то нету.



0
Источник

Понравилась статья? Поделить с друзьями:
  • Transport loopywriter run returning connection error desc transport is closing
  • Transport level error while connecting to general error 0x502
  • Transport level error while connecting kaspersky
  • Transport level error in process of connection to 13291 kaspersky 13
  • Transport level error in process of connection to 13291 connection refused