redhog
Arch triggers memory bug (in rsvg?)
glass-renderer core dumps after writing
malloc(): memory corruption (fast)
a few 100 times.
Traceback with pdb from core dump:
#0 0x00007f0c3f9fe4dc in () at /usr/lib/libc.so.6
#1 0x00007f0c3f9ae998 in raise () at /usr/lib/libc.so.6
#2 0x00007f0c3f99853d in abort () at /usr/lib/libc.so.6
#3 0x00007f0c3f9f267e in () at /usr/lib/libc.so.6
#4 0x00007f0c3fa0826c in () at /usr/lib/libc.so.6
#5 0x00007f0c3fa0b6dc in () at /usr/lib/libc.so.6
#6 0x00007f0c3fa0d2a6 in calloc () at /usr/lib/libc.so.6
#7 0x00007f0c40183052 in g_malloc0 () at /usr/lib/libglib-2.0.so.0
#8 0x00007f0c40288d00 in g_param_spec_pool_list () at /usr/lib/libgobject-2.0.so.0
#9 0x00007f0c40288f05 in g_object_class_list_properties () at /usr/lib/libgobject-2.0.so.0
#10 0x00007f0c409ca6ea in () at /usr/lib/librsvg-2.so.2
#11 0x00007f0c4076c1a0 in () at /usr/lib/librsvg-2.so.2
#12 0x00007f0c4079efb1 in rsvg_handle_new_with_flags () at /usr/lib/librsvg-2.so.2
#13 0x00007f0c4079fb1b in rsvg_handle_new_from_stream_sync () at /usr/lib/librsvg-2.so.2
#14 0x00007f0c407a00db in rsvg_handle_new_from_data () at /usr/lib/librsvg-2.so.2
#15 0x000055c88ac2b150 in property_svg_load (prop=0x55c88c38e0a0) at property_svg.c:157
#16 0x000055c88ac252d3 in property_load_parse (data=0x55c88c38e0a0, reply=0x55c88c38e9a0, error=0x0) at property.c:59
#17 0x000055c88ac235c7 in xcb_cookies_handle () at mainloop.c:112
#18 0x000055c88ac2381b in mainloop_run () at mainloop.c:152
#19 0x000055c88ac35b45 in main () at wm.c:376
Not sure if this is a bug in my code, or in librsvg==2:2.54.4-1 (Working version: 2.40.20-2ubuntu0.2 on amd4), but I can't see anything strange w the parameters to the call to rsvg_handle_new_from_data() from my code using pdb...
How do I debug glass-renderer? Could you share a screenshot? It would help to know whether we see the same thing on Arch or not. Same version of librsvg here.
Could you also share what packages are installed? pacman -Q > arch_packages.txt
So the debugging I did was to start the container with
DOCKEROS=arch DOCKERCOMMAND=/bin/bash make run-in-docker cd /InfiniteGlass make run 2>&1 | tee log
Then when it starts to spew errors, I closed the Xephyr window, and had a look at the logfile called "log", and then did
gdb build/env/bin/glass-renderer core
You should also be able to do
make GLASS_DEBUGGER=gdb run
from inside the container, but it seems a bit broken at the moment.
You might want to pull latest version (I fixed some of the gdb problems)
Thank you! I will take a look. You should perhaps tag your commits with the corresponding issue numbers. Just add a comment with the issue number, such as #92. It will be automatically added to this thread.
Also (new version again):
make GLASS_DEBUGGER=gdb GLASS_GHOSTS_OPTIONS=--no-restart-components run
will make things a bit saner...
Also (new version again):
make GLASS_DEBUGGER=gdb GLASS_GHOSTS_OPTIONS=--no-restart-components run
will make things a bit saner...
What about having a make run-and-debug at this point? :)
Hm, I can add that :)
I've just been adding more and more environment variables that turn on/off individual functions for now, but some stuff is pretty obv you want together, like, why'd you want restarts of components that crash, if you're debugging them? That just makes your gdb session confusing :P
Could even wrap this and run in docker, so you have debug in docker as one command
Are you still using it as your daily driver?
I would be delighted if you would have some time to spare and help to figure out what is holding me up with InfiniteGlass. It hasn't worked on my machine in a long time.
I'm going on a interrail trip across Europe in a week, but I could definitely spend some time with you after that, but that's in August...
I'm going on a interrail trip across Europe in a week, but I could definitely spend some time with you after that, but that's in August...
Sounds excellent to me! I'd just like that you show me around, your workflow, answer a few questions and so on.
I always have this feeling that I'm close enough to contribute but alas... My suspicion has always been that if I run it as my daily driver, then I will have time to figure it out. Or at least no choice.
Hope you will enjoy your vacation. Looking forward to hearing from you! (Do you have a discord or something else that you use these days? Something with screen sharing)
Following on this issue and issues #88 and #94. One thing you had suggested in the past is to set no_splash mode. It does get over the blank screen but crashes anyway. This happens on both Arch Linux and Rocky Linux. Feel free to split this up into another issue if necessary.
https://github.com/redhog/InfiniteGlass/assets/8844578/7978d1fa-e9e6-4093-ad86-cdf00bb3da7e
Starting renderer without debugger
NEW CONN <glass_ghosts.session.Server object at 0x7f1364e45310>
NEW CONN DONE <glass_ghosts.session.Server object at 0x7f1364e45310> 139721273871616 {139721273871616: <glass_ghosts.session.Server.Connection object at 0x7f1364e58d00>} 94432633752752 139721273871616
Found XInput version 2.0
(process:1376081): librsvg-WARNING **: 20:24:04.005: cannot render on a cairo_t with a failure status (status="invalid value (typically too big) for the size of the input (surface, pattern, etc.)")
free(): invalid pointer
Starting renderer without debugger
malloc_consolidate(): invalid chunk size
Starting renderer without debugger
malloc_consolidate(): invalid chunk size
...
I have been stress testing rsvg_handle_new_from_data() but nothing leads to the malloc(): memory corruption. The tests included one large SVG, a 1GB generated SVG, excessive calls to rsvg_handle_new_from_data() and even ran through valgrind. librsvg doesn't seem to be the problem.
It seems that property_svg_load() in glass-renderer/property_svg.c fails at some point. It does load a few SVGs but it crashes right there. I wasn't quick enough to catch it and print out values (and src) in gdb before SIGABRT. Perhaps a faulty SVG?
group.fl.svg and tv.fl.svg are causing the issue.
The issue preventing splash mode is caused by image.fl.svg.
Replacing them fixed the problem. There is a need to sanitize the SVGs on the fly or validate them beforehand.
Loading and saving the SVG on https://jakearchibald.github.io/svgomg/ is working. Probably doable on Inkscape as well using clean up or optimize.
Wow, so librsvg crashes if the data (svg file) is bad? Wow.
Absolutely unexpected! How does GNOME even handle this?
By the way, excellent documentation and information on the issue tracker. It was helpful to debug this.
Doing due diligence here. The following program is actually not crashing from the faulty SVG files.
svg2png_from_file.c:
#include <cairo.h>
#include <librsvg/rsvg.h>
#include <glib.h>
#include <glib/gstdio.h>
int main(int argc, char **argv) {
if (argc != 2) {
g_printerr("Usage: %s <SVG file>\n", argv[0]);
return 1;
}
RsvgHandle *rsvg;
RsvgDimensionData dimensions;
cairo_surface_t *surface;
cairo_t *cr;
GError *error = NULL;
gchar *svg_data;
gsize length;
// Initialize librsvg
rsvg_init();
// Read SVG data from file
if (!g_file_get_contents(argv[1], &svg_data, &length, &error)) {
g_printerr("Error reading file: %s\n", error->message);
return 1;
}
// Load SVG from string data
rsvg = rsvg_handle_new_from_data((const guint8 *)svg_data, length, &error);
if (!rsvg) {
g_free(svg_data);
g_printerr("Error loading SVG data: %s\n", error->message);
return 1;
}
// Get SVG dimensions
rsvg_handle_get_dimensions(rsvg, &dimensions);
// Create cairo surface and context
surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, dimensions.width, dimensions.height);
cr = cairo_create(surface);
// Render SVG onto the cairo context
rsvg_handle_render_cairo(rsvg, cr);
// Save the cairo surface to a PNG file
cairo_surface_write_to_png(surface, "output_from_file.png");
// Cleanup
cairo_destroy(cr);
cairo_surface_destroy(surface);
g_object_unref(rsvg);
g_free(svg_data);
// Shutdown librsvg
rsvg_term();
return 0;
}
This just might have finally been solved, see https://github.com/redhog/InfiniteGlass/commit/ddd9e37ae96fbafd04375a76de5f76928601025f
Please test, and it this fixes it on other distros as well, we can finally close this.