On Mon, Feb 11, 2019 at 06:44:47AM -0500, Frediano Ziglio wrote: > > > Hi > > > On Fri, Feb 8, 2019 at 12:35 PM Victor Toso <victortoso@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Feb 08, 2019 at 06:11:29AM -0500, Frediano Ziglio wrote: > > > > > > > > > > > > New functions and macros have been added in glib 2.38 to better > > > > > > handle > > > > > > this case. > > > > > > > > > > > > https://gitlab.gnome.org/GNOME/glib/blob/c8de2b11bbbf5705ee20bf68d0c11e455b441312/NEWS > > > > > > > > > > > > G_TYPE_INSTANCE_GET_PRIVATE will be deprecated in GLib 2.58. > > > > > > > > > > > > https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits > > > > > > > > > > > > Signed-off-by: Eduardo Lima (Etrunko) <etrunko@xxxxxxxxxx> > > > > > > Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx> > > > > > > > > > > Patch is good for me. Can I ack it? > > > > > > > > Go on :) > > > > > > > > > > After this commit, when starting qemu, I get a SEGV: > > > > > > $ x86_64-softmmu/qemu-system-x86_64 -spice disable-ticketing > > > AddressSanitizer:DEADLYSIGNAL > > > ================================================================= > > > ==28227==ERROR: AddressSanitizer: SEGV on unknown address > > > 0x00009fff8000 (pc 0x560c519c1c5f bp 0x7ffd40613660 sp 0x7ffd40613650 > > > T0) > > > ==28227==The signal is caused by a READ memory access. > > > #0 0x560c519c1c5e in timer_remove > > > /home/elmarco/src/qemu/ui/spice-core.c:78 > > > #1 0x7f89520c27d7 in adapter_timer_remove > > > (/usr/local/lib/libspice-server.so.1+0x5c7d7) > > > #2 0x7f89520cf033 in reds_core_timer_remove > > > (/usr/local/lib/libspice-server.so.1+0x69033) > > > #3 0x7f8952076ed5 in red_char_device_init_device_instance > > > (/usr/local/lib/libspice-server.so.1+0x10ed5) > > > #4 0x7f895207731a in red_char_device_on_sin_changed > > > (/usr/local/lib/libspice-server.so.1+0x1131a) > > > #5 0x7f895310b3dc in g_closure_invoke > > > (/lib64/libgobject-2.0.so.0+0x113dc) > > > #6 0x7f895311e982 (/lib64/libgobject-2.0.so.0+0x24982) > > > #7 0x7f8953127aa9 in g_signal_emit_valist > > > (/lib64/libgobject-2.0.so.0+0x2daa9) > > > #8 0x7f89531280a2 in g_signal_emit (/lib64/libgobject-2.0.so.0+0x2e0a2) > > > #9 0x7f895310fe53 (/lib64/libgobject-2.0.so.0+0x15e53) > > > #10 0x7f895310f78d (/lib64/libgobject-2.0.so.0+0x1578d) > > > #11 0x7f89531113a0 (/lib64/libgobject-2.0.so.0+0x173a0) > > > #12 0x7f8953112fdd in g_object_new_valist > > > (/lib64/libgobject-2.0.so.0+0x18fdd) > > > #13 0x7f895311333c in g_object_new (/lib64/libgobject-2.0.so.0+0x1933c) > > > #14 0x7f89520cfc05 in red_char_device_vdi_port_new > > > (/usr/local/lib/libspice-server.so.1+0x69c05) > > > #15 0x7f89520cc70e in do_spice_init > > > (/usr/local/lib/libspice-server.so.1+0x6670e) > > > #16 0x7f89520cd168 in spice_server_init > > > (/usr/local/lib/libspice-server.so.1+0x67168) > > > #17 0x560c519c5d69 in qemu_spice_init > > > /home/elmarco/src/qemu/ui/spice-core.c:792 > > > #18 0x560c50ecbc17 in main /home/elmarco/src/qemu/vl.c:4323 > > > #19 0x7f8951037412 in __libc_start_main (/lib64/libc.so.6+0x24412) > > > > > > > > > > Tried to reproduce without success. > > I enabled sanitizer in spice-server and run the command with stock (packaged) > > Qemu, > > no issues. > > Normal tests have no issues too. > > From timer_remove (spice-core.c) code looks like a corruption of "timer" > > pointer, > > if I read correctly faulty address is 0x00009fff8000 which does not tell me > > much at > > the moment. > > I don't understand why GObject is emitting a signal here but I cannot see any > > issue, maximum the signal is sent before reds pointer is set but there's a > > check > > for it in red_char_device_on_sin_changed. > > Could be that write_to_dev_timer is not initialized to NULL by GObject? > > Everything > > should be initialized by 0 by GObject. Can you try to manually initialize to > > NULL > > in red_char_device_init? > > I see you are using your own version of Qemu. Can you try the stock one? > > Which commit of Qemu are you trying? > > > > We found the issue, GLIB_VERSION_MAX_ALLOWED must be >= GLIB_VERSION_2_38 due > to some GLib macros (I had to dig into the headers, maybe we could send a > patch to GLib to detect the issue?). > An autoreconf solved the issue. > Should we put some check in our code or are we just expected to run autoreconf > more "reliably" ? For what it's worth, I do not understand what the problem was, so it's hard to comment on whether we need better checks or not ;) Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel