[librsvg: 4/45] More details on the design doc for observability
- From: Marge Bot <marge-bot src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [librsvg: 4/45] More details on the design doc for observability
- Date: Wed, 24 Aug 2022 01:56:36 +0000 (UTC)
commit 4a4351cfde1bc4b8af7937a2f8d776ec7a9a43f0
Author: Federico Mena Quintero <federico gnome org>
Date: Wed May 11 17:54:19 2022 -0500
More details on the design doc for observability
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/731>
devel-docs/api-observability.md | 137 +++++++++++++++++++++++++---------------
1 file changed, 87 insertions(+), 50 deletions(-)
---
diff --git a/devel-docs/api-observability.md b/devel-docs/api-observability.md
index 2bb5a923c..cd0ca91a4 100644
--- a/devel-docs/api-observability.md
+++ b/devel-docs/api-observability.md
@@ -41,6 +41,12 @@ Know exactly what an application did with librsvg:
* "What SVG?" - be careful and explicit about exfiltrating SVG data to the logs.
+* Basic platform stuff? Is the platform triple enough? Distro ID?
+
+* Versions of dependencies.
+
+* Version of librsvg itself.
+
Internals of the library:
* Regular debug tracing. We may have options to enable/disable
@@ -50,82 +56,110 @@ Internals of the library:
* Log all points where an error is detected/generated, even if it will
be discarded later (e.g. invalid CSS values are silently ignored,
per the spec).
+
+## Enabling logging
-## Stuff to log
+It may be useful to be able to enable logging in various ways:
+* Programmatically, for when one has control of the source code of the
+ problematic application. Enable logging at the problem spot, for
+ the SVG you know that exhibits the problem, and be done with it.
+ This can probably be at the individual `RsvgHandle` level, not
+ globally. For global logging within a single process, see the next
+ point.
+
+* For a single process which one can easily launch via the command
+ line; e.g. with an environment variable. This works well for
+ non-sandboxed applications. Something like
+ `RSVG_LOG_CONFIG=my_log_config.toml`.
+
+* With a configuration file, a la `~/.config/librsvg.toml`. Many
+ programs use librsvg and you don't want logs for all of them; allow
+ the configuration file to specify a process name, or maybe other
+ ways of determining when to log. For session programs like
+ gnome-shell, you can't easily set an environment variable to enable
+ logging - hence, a configuration file that only turns on logging
+ from the gnome-shell process.
+
+All of the above should be well documented, and then we can deprecate `RSVG_LOG`.
+## Which SVG caused a crash?
-Log cr state at entry.
+Every once in a while, a bug report comes in like "$application
+crashed in librsvg". The application renders many SVGs, often
+indirectly via gdk-pixbuf, and it is hard to know exactly which SVG
+caused the problem. Think of gnome-shell or gnome-software.
-Log name/base_uri of rendered document.
+For applications that call librsvg directly, if they pass the filename
+or a GFile then it is not hard to find out the source SVG.
-Can we know if it is a gresource? Or a byte buffer? Did it come from gdk-pixbuf?
+But for those that feed bytes into librsvg, including those that use
+it indirectly via gdk-pixbuf, librsvg has no knowledge of the
+filename. We need to use the base_uri then, or see if the pixbuf
+loader can be modified to propagate this information (is it even
+available from the GdkPixbufLoader machinery?).
-## Invocation
+If all else fails, we can have an exfiltration mechanism. How can we
+avoid logging *all* the SVG data that gnome-shell renders, for
+example? Configure the logger to skip the first N SVGs, and hope that
+the order is deterministic? We can't really "log only if there is a
+crash during rendering".
-RSVG_LOG=1 is easy for specific processes or rsvg-convert
+Log only the checksums of SVGs or data lengths, and use that to find
+which SVG caused the crash? I.e. have the user use a two-step process
+to find a crash: get a log (written synchronously) of all SVG
+checksums/lengths, and then reconfigure the logger to only exfiltrate
+the last one that got logged - presumably that one caused the crash.
-Login processes like gnome-shell need a config file. ~/.config/librsvg.toml:
+## Which dynamically-created SVG caused a problem?
- [logging]
- enabled=true # make this the default if the file exists?
- process=gnome-shell # mandatory - don't want to log all processes - warn to g_log if key is
not set
- output=/home/federico/rsvg.log # if missing, log to g_log only
+Consider a bug like
+https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5415 where an
+application dynamically generates an SVG and feeds it to librsvg.
+That bug was not a crash; it was about incorrect values returned from
+an librsvg API function. For those cases it may be useful to be able
+to exfiltrate an SVG and its stylesheets only if it matches a
+user-provided substring.
-/home/federico/rsvg.log - json doesn't have comments; put this in a string somehow:
- ******************************************************************************
- * This log file exists because you enabled logging in ~/.config/librsvg.toml *
- * for the "gnome-shell" process. *
- * *
- * If you want to disable this kind of log, please turn it off in that file *
- * or delete that file entirely. *
- ******************************************************************************
-
- ******************************************************************************
- * This log file exists because you enabled logging with *
- * RSVG_LOG_CONFIG=config.toml for the "single-process-name" process. *
- * *
- * If you want to disable this kind of log, FIXME */
- ******************************************************************************
+## Global configuration
-** To-do list [0/1]
+`$(XDG_CONFIG_HOME)/librsvg.toml` - for startup-like processes like
+gnome-shell, for which it is hard to set an environment variable:
-- [ ] Audit code for GIO errors; log there.
+## Per-process configuration
-- [ ] Audit code for Cairo calls that yield errors; log there.
+`RSVG_LOG_CONFIG=my_log_config.toml my_process`
-- [ ] Log the entire ancestry of the element that caused the error? Is that an insta-reproducer?
-** Ideas
-*** Log API calls?
+## Programmatic API
-Is this useful? Not all the entry points; most cases are new_from_whatever() / render().
+FIXME
-Better, log the filename, or the base_uri for a stream, or optionally exfiltrate the SVG in case of a
resource or raw data.
-*** What to log
+## Configuration format
-Entry point at rendering: state of the Cairo context, surface type, starting transform, etc.
+```toml
+[logging]
+enabled=true
+process=gnome-shell # mandatory for global config - don't want to log all processes - warn to
g_log if key is not set
+output=/home/username/rsvg.log # if missing, log to g_log only - or use a output_to_g_log=true instead?
+```
-Versions of dependencies - pango, cairo, etc. Distro name / Windows / MacOS?
-*** Limit to a process
+## API logging
-For global configuration (see below), put the process name in the configuration file.
+Log cr state at entry, surface type, starting transform.
-For single-process config, use RSVG_LOG_CONFIG=filename.toml env var
+Log name/base_uri of rendered document.
+Can we know if it is a gresource? Or a byte buffer? Did it come from gdk-pixbuf?
-*** Configuration and log format
+## Log contents
-~/.config/librsvg.toml - global configuration
- [logging]
- enabled=true
- process=gnome-shell # mandatory - don't want to log all processes
- output=/home/federico/rsvg.log
+/home/username/rsvg.log - json doesn't have comments; put one of these in a string somehow:
-/home/federico/rsvg.log - json doesn't have comments; put this in a string somehow:
+```
******************************************************************************
* This log file exists because you enabled logging in ~/.config/librsvg.toml *
* for the "gnome-shell" process. *
@@ -140,9 +174,12 @@ For single-process config, use RSVG_LOG_CONFIG=filename.toml env var
* *
* If you want to disable this kind of log, FIXME */
******************************************************************************
+```
-Output JSON, so it can nest <g> and such?
+** To-do list [0/1]
-Add a replayer? This would effectively be "paint the render tree".
-Just replay the user's provided log file, reproduce the bug.
+- [ ] Audit code for GIO errors; log there.
+- [ ] Audit code for Cairo calls that yield errors; log there.
+
+- [ ] Log the entire ancestry of the element that caused the error? Is that an insta-reproducer?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]