6 ms·

Well that's the question, isn't it? Here's one scenario that might invoke UB: create a top level widget, call destroy() [1] on it, then use the widget. Does t

Well that's the question, isn't it? Here's one scenario that might invoke UB: create a top level widget, call destroy() [1] on it, then use the widget. Does that invoke UB? If not, why not - how does Rust's ownership model interact with the GTK one? [1] http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.destroy http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.des...

yorwba 9y ago
I tried to test this by modifying the example on http://gtk-rs.org http://gtk-rs.org so that the window would be destroyed immediately after creation. When I ran it under valgrind, there were lots of memory access violations. (Valgrind: "Go fix your program!") I thought that would settle the matter, but then I ran the unmodified code, and it generated essentially the same error messages. Filing a bug report right now.
- jcranmer 9y ago
  Looking at your bug report, the first few errors are in g_object code and have absolutely nothing to do with Rust, let alone gtk-rs. (It is known that jemalloc, Rust's allocator, doesn't play nicely with valgrind, but not even that is in play). Given that the stacks start with dbus, none of these errors are relevant to gtk-rs.
  - yorwba 9y ago
    I did not get any similar errors on other GTK apps I tested, so I'm relatively confident that it is at least somewhat related to the way gtk-rs does things. I do not seriously expect any Rust code to directly violate memory safety, but calling C code in GTK incorrectly can still have the same effect.
    - yorwba 9y ago
      For those still watching this thread: the memory accesses were correct, valgrind just couldn't handle the jemalloc allocator. Using the system allocator instead, even destroying the window before using it does not lead to invalid accesses.
      - alphaalpha101 9y ago
        Isn't it still undefined behaviour to do so, though?
        yorwba 9y ago
        Valgrind doesn't detect anything, so I guess GTK's reference counting does the right thing and doesn't prematurely free data still referenced somewhere else. It just doesn't show a window.

yorwba 9y ago

I tried to test this by modifying the example on http://gtk-rs.org http://gtk-rs.org so that the window would be destroyed immediately after creation. When I ran it under valgrind, there were lots of memory access violations. (Valgrind: "Go fix your program!") I thought that would settle the matter, but then I ran the unmodified code, and it generated essentially the same error messages. Filing a bug report right now.

jcranmer 9y ago
Looking at your bug report, the first few errors are in g_object code and have absolutely nothing to do with Rust, let alone gtk-rs. (It is known that jemalloc, Rust's allocator, doesn't play nicely with valgrind, but not even that is in play). Given that the stacks start with dbus, none of these errors are relevant to gtk-rs.
- yorwba 9y ago
  I did not get any similar errors on other GTK apps I tested, so I'm relatively confident that it is at least somewhat related to the way gtk-rs does things. I do not seriously expect any Rust code to directly violate memory safety, but calling C code in GTK incorrectly can still have the same effect.
  - yorwba 9y ago
    For those still watching this thread: the memory accesses were correct, valgrind just couldn't handle the jemalloc allocator. Using the system allocator instead, even destroying the window before using it does not lead to invalid accesses.
    - alphaalpha101 9y ago
      Isn't it still undefined behaviour to do so, though?
      - yorwba 9y ago
        Valgrind doesn't detect anything, so I guess GTK's reference counting does the right thing and doesn't prematurely free data still referenced somewhere else. It just doesn't show a window.