Creating DSO list for all types of crashes
by Matej Habrnal
Reason
------
CuCos developers need to get involved packages in crashes but not only rpm but
rubygem and so on as well.
Current state
-------------
ABRT creates DSO list (dynamically loaded libraries or modules) only for CCpp
xorg, and Python2 type of problems. In CCpp and xorg type it's created by
following steps: in post-create envet is run abrt-action-list-dsos tool with
parameter maps (/proc/$PID/maps), respectively, with backtrace and the tool
generate dso list by calling '$ rpm -rf $PATH' on every given path from maps,
respectively, backtrace.
The resulting dso_list file then looks like following (path, package, vendor,
install time):
""
/usr/lib64/libc-2.23.so glibc-2.23.1-7.fc24.x86_64 (Fedora Project) 1463385519
/usr/lib64/libwillcrash.so.0.0.0 will-crash-0.10-2.fc24.x86_64 (Fedora Project) 1461672440
/usr/lib64/ld-2.23.so glibc-2.23.1-7.fc24.x86_64 (Fedora Project) 1463385519
/usr/bin/will_segfault will-crash-0.10-2.fc24.x86_64 (Fedora Project) 1461672440
""
In Python type the dso_file is created from backtrace right in
abrt_exception_handler.py, it means in time the exception was caught. Every
path from backtrace is run with 'rpm -rf $PATH' and look like following
(package):
""
will-crash-0.10-2.fc24.x86_64
""
DSO list is not generated for other types.
Goal
----
Unify generating of DSO files and add support for all types of crashes (Python3,
java, ruby etc.). Allow easily add a new crash type, ideally propose some API
in order to use it in plugins like ruby.
Move current dso_list generating from post-create event and python hook to make
post-create faster.
Proposed solution
-----------------
Split curren dso_list generating into three parts and extend it by adding new
crash types.
First step
~~~~~~~~~~
First part should generate simple dso_list which contains only path
to linked libraries or modules. This part should be placed in satyr because
satyr can handle backtraces.
Will be used JSON format, because the file will be
loaded and parsed in each step and it's easy to do that with JSON file. Satyr
also creates JSON structure of dso_list while it creates uReport. So it should
make uReport creating faster as well.
All path will be stored as file_name and each file_name has its own type
element. The type element says if there is detail information related to the
path, it means if information about package which ships the path is known.
In the first step all type elements are set to undefined value.
Example:
Basic dso_file generated by satyr:
{
"packages": [ { "file_name": "/usr/lib64/libc-2.23.so"
, "type": "undefined"
}
, { "file_name": "/some/java/file"
, "type": "undefined"
}
, { "file_name": "/usr/lib64/ld-2.23.so"
, "type": "undefined"
} ]
}
Second step
~~~~~~~~~~~
The second part will be placed in ABRT and its main purpose will be getting more
information (package which ships the path, its vendor and time of installation
etc.) about paths from dso_list which is made by part one.
For main types of packages as rpm, deb etc. there will be some mechanisms to get
the information (e.g. rpm -qf $PATH for paths shipped by rpm package).
ABRT will go through all file_names from dso_list and will try all mechanisms to all
given file_names and compete them.
ABRT updates the dso_file so the file now contains some package with
full information and some packages are unchanged. In the case package contains
full information, ABRT stores type of mechanism which
gets the information into type element, it ensures third step cannot try to get
them.
Package containing only file_name and type with value undefined will handle the
part three.
ABRT could handle following types in part two:
rpm
ruby
pip
Example:
dso_file content after second step:
"packages": [ { "file_name": "/usr/lib64/libc-2.23.so"
, "type": "rpm"
, "name": "glibc"
, "epoch": 0
, "version": "2.23.1"
, "release": "7.fc24"
, "architecture": "x86_64"
, "install_time": 1463385519
}
, { "file_name": "/some/java/file"
, "type": "undefined"
}
, { "file_name": "/usr/lib64/ld-2.23.so"
, "type": "rpm"
, "name": "glibc"
, "epoch": 0
, "version": "2.23.1"
, "release": "7.fc24"
, "architecture": "x86_64"
, "install_time": 1463385519
}
} ]
Third step
~~~~~~~~~~
Step three should complete the dso_list. Mechanism for special types (e.g.
Java), will be shipped with plugins which process those crashes (e.g.
abrt-java-conector). The plugins should handle completing the dso_list on its
own.
Example:
dso_file content after third step:
"packages": [ { "file_name": "/usr/lib64/libc-2.23.so"
, "type": "rpm"
, "name": "glibc"
, "epoch": 0
, "version": "2.23.1"
, "release": "7.fc24"
, "architecture": "x86_64"
, "install_time": 1463385519
}
, { "file_name": "/some/java/file"
, "type": "java"
, "name": "java_name"
, "epoch": 0
, "version": "2.23.1"
, "release": "7.fc24"
, "architecture": "x86_64"
, "install_time": 1463385519
}
, { "file_name": "/usr/lib64/ld-2.23.so"
, "type": "rpm"
, "name": "glibc"
, "epoch": 0
, "version": "2.23.1"
, "release": "7.fc24"
, "architecture": "x86_64"
, "install_time": 1463385519
}
} ]
This is just the first idea. Feel free to propose some improvements or ideas.
Regards
Matej
ABRT team
8 years
- 1
- 0
- ← Newer
- 1
- Older →