Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bad weak ref #31

Open
matthiasclasen opened this issue Nov 4, 2017 · 0 comments
Open

bad weak ref #31

matthiasclasen opened this issue Nov 4, 2017 · 0 comments

Comments

@matthiasclasen
Copy link

When i close the simple-grid example, I get:

$ valgrind ./build/examples/simple-grid
==28422== Memcheck, a memory error detector
==28422== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==28422== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==28422== Command: ./build/examples/simple-grid
==28422==
==28422== Invalid write of size 8
==28422== at 0x62EAFE5: g_nullify_pointer (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x602C41E: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602EE5B: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x5178ABB: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x51C3C3D: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x6028650: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x603B651: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x6043D04: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x604466E: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53E05AF: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x602EE5B: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53EC958: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== Address 0x12f18d10 is 368 bytes inside a block of size 464 free'd
==28422== at 0x4C2ED18: free (vg_replace_malloc.c:530)
==28422== by 0x62BC4AD: g_free (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D44EF: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x604D2A2: g_type_free_instance (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x4E43AED: emeus_constraint_layout_forall (emeus-constraint-layout.c:854)
==28422== by 0x51C3C3D: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x4E41EC1: emeus_constraint_layout_destroy (emeus-constraint-layout.c:239)
==28422== by 0x6028650: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x603B651: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x6043D04: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x604466E: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53E05AF: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== Block was alloc'd at
==28422== at 0x4C2DB6B: malloc (vg_replace_malloc.c:299)
==28422== by 0x62BC398: g_malloc (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D3F75: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D4408: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x604CFA0: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602DDB7: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602FC2F: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602FFA8: g_object_new (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x4E46C6C: emeus_constraint_layout_child_new (emeus-constraint-layout.c:2242)
==28422== by 0x4E458C9: emeus_constraint_layout_pack (emeus-constraint-layout.c:1716)
==28422== by 0x40144A: build_grid (simple-grid.c:64)
==28422== by 0x401A7D: emeus_test_application_window_init (simple-grid.c:2

Taking out the

g_object_add_weak_pointer (G_OBJECT (layout), (gpointer*) &layout_child->solver);

in emeus_constraint_layout_pack makes this go away. I assume the children are already gone by the time the weak refs get cleaned up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant