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

Possible memory leak in ruby-gnome2 gtk2 3.2.7 #1230

Closed
tsutsui opened this Issue Jul 1, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@tsutsui

tsutsui commented Jul 1, 2018

After ruby-gnome2 3.2.7 updates, memory usage of mikutter increased significantly.

I've measured VSZ (virtual size in Kbytes) of ps(1)'s output using two VirtualBox VMs which run mikutter with the same environments/settings (NetBSD/i386 8.0_RC1 + pkgsrc etc.) except ruby-gnome2 versions (3.2.5 vs 3.2.7). The result shows memory usage of 3.2.7 contiguously increased per every tweet:
mikutter-ruby-gnome2-3 2 5-7-vmtest
mikutter-3 7 2-ruby-gnome2-3 2 5-7-memory-usage

Note mikutter requires the following ruby-gnome2 gems as dependencies:
atk
cairo-gobject
gdk_pixbuf2
gio2
glib2
gobject-introspection
gtk2
pango

More details are in the following mikutter's redmine ticket:
https://dev.mikutter.hachune.net/issues/1260#note-8

@kou

This comment has been minimized.

Show comment
Hide comment
@kou

kou Jul 1, 2018

Member

Thanks for your report.
Can you try to use git bisect to find a related commit?

Member

kou commented Jul 1, 2018

Thanks for your report.
Can you try to use git bisect to find a related commit?

@tsutsui

This comment has been minimized.

Show comment
Hide comment
@tsutsui

tsutsui Jul 1, 2018

It is a bit hard to prepare all necessary gems from each bisect revision (and it's a bit difficult to check VSZ usage in short priod), but anyway I've tested it manually:

# bad: [0123e43d335801332f11567e69941446c403d21d] Add 3.2.7 entry
# good: [911d1dd973f751c6412b00ee24fca8f331f932b5] gtk3 test: disable with old GObject Introspection
git bisect start '3.2.7' '3.2.5'
# bad: [dbcf923b3c7d20ccb25c7aacd50b166886f3b5c9] Fix a typo
git bisect bad dbcf923b3c7d20ccb25c7aacd50b166886f3b5c9
# good: [ab8b175ab910d00a1a574277a071c59e4cd8a8b6] action-namespace sample : add @kou modifications
git bisect good ab8b175ab910d00a1a574277a071c59e4cd8a8b6
# good: [1171092b51aa67e2772e46aecfab3306177c0b59] Merge pull request #1186 from kojix2/pr4
git bisect good 1171092b51aa67e2772e46aecfab3306177c0b59
# good: [8b66ab88e7473f74878fdbcdd5ab0a9c134153fc] pango: support auto Pango::Attribute conversion
git bisect good 8b66ab88e7473f74878fdbcdd5ab0a9c134153fc
# bad: [b965c45c182cb7cc66528366b61454567d9bbdbb] Merge pull request #1191 from shiro615/add-rubyish-method-name
git bisect bad b965c45c182cb7cc66528366b61454567d9bbdbb
# bad: [f113870b82037ff7ea6d1f96038c2165b0b6d6ee] glib2: add rbg_gc_guard() and rbg_gc_unguard()
git bisect bad f113870b82037ff7ea6d1f96038c2165b0b6d6ee
# bad: [2e1ce20ac6dceb151abb8978114e3a368676c051] gi: support getting flags field value
git bisect bad 2e1ce20ac6dceb151abb8978114e3a368676c051

I.e.

The possible commit is either 438be7c or 2e1ce20 ? (but I'm afraid there were some botch in my tests)
Note using pango gem built from the good rev and other gems from the bad rev solves the problem (i.e. no VSZ increase on receiving each tweet on mikutter).

tsutsui commented Jul 1, 2018

It is a bit hard to prepare all necessary gems from each bisect revision (and it's a bit difficult to check VSZ usage in short priod), but anyway I've tested it manually:

# bad: [0123e43d335801332f11567e69941446c403d21d] Add 3.2.7 entry
# good: [911d1dd973f751c6412b00ee24fca8f331f932b5] gtk3 test: disable with old GObject Introspection
git bisect start '3.2.7' '3.2.5'
# bad: [dbcf923b3c7d20ccb25c7aacd50b166886f3b5c9] Fix a typo
git bisect bad dbcf923b3c7d20ccb25c7aacd50b166886f3b5c9
# good: [ab8b175ab910d00a1a574277a071c59e4cd8a8b6] action-namespace sample : add @kou modifications
git bisect good ab8b175ab910d00a1a574277a071c59e4cd8a8b6
# good: [1171092b51aa67e2772e46aecfab3306177c0b59] Merge pull request #1186 from kojix2/pr4
git bisect good 1171092b51aa67e2772e46aecfab3306177c0b59
# good: [8b66ab88e7473f74878fdbcdd5ab0a9c134153fc] pango: support auto Pango::Attribute conversion
git bisect good 8b66ab88e7473f74878fdbcdd5ab0a9c134153fc
# bad: [b965c45c182cb7cc66528366b61454567d9bbdbb] Merge pull request #1191 from shiro615/add-rubyish-method-name
git bisect bad b965c45c182cb7cc66528366b61454567d9bbdbb
# bad: [f113870b82037ff7ea6d1f96038c2165b0b6d6ee] glib2: add rbg_gc_guard() and rbg_gc_unguard()
git bisect bad f113870b82037ff7ea6d1f96038c2165b0b6d6ee
# bad: [2e1ce20ac6dceb151abb8978114e3a368676c051] gi: support getting flags field value
git bisect bad 2e1ce20ac6dceb151abb8978114e3a368676c051

I.e.

The possible commit is either 438be7c or 2e1ce20 ? (but I'm afraid there were some botch in my tests)
Note using pango gem built from the good rev and other gems from the bad rev solves the problem (i.e. no VSZ increase on receiving each tweet on mikutter).

@tsutsui

This comment has been minimized.

Show comment
Hide comment
@tsutsui

tsutsui Jul 2, 2018

3.2.7 + reverting 438be7c seems to fix the leak.

tsutsui commented Jul 2, 2018

3.2.7 + reverting 438be7c seems to fix the leak.

@kou

This comment has been minimized.

Show comment
Hide comment
@kou

kou Jul 3, 2018

Member

Thanks.
It's useful information.

The following script reproduces this case.

#!/usr/bin/env ruby

require "pango"

i = 0
loop do
  i += 1
  context = Pango::Context.new
  context.set_shape_renderer do
  end
  GC.start
  if (i % 10).zero?
    p(ObjectSpace.each_object(Pango::Context) {})
  end
end
Member

kou commented Jul 3, 2018

Thanks.
It's useful information.

The following script reproduces this case.

#!/usr/bin/env ruby

require "pango"

i = 0
loop do
  i += 1
  context = Pango::Context.new
  context.set_shape_renderer do
  end
  GC.start
  if (i % 10).zero?
    p(ObjectSpace.each_object(Pango::Context) {})
  end
end

@kou kou closed this in 8816bbd Jul 3, 2018

@kou

This comment has been minimized.

Show comment
Hide comment
@kou

kou Jul 3, 2018

Member

Can you try 8816bbd ?

Member

kou commented Jul 3, 2018

Can you try 8816bbd ?

@tsutsui

This comment has been minimized.

Show comment
Hide comment
@tsutsui

tsutsui Jul 3, 2018

I've tried 3.2.7 + 8816bbd but it causes coredump of the ruby binary by an assertion "object allocation during garbage collection phase" like #1162.
I'll post a new issue for it.

tsutsui commented Jul 3, 2018

I've tried 3.2.7 + 8816bbd but it causes coredump of the ruby binary by an assertion "object allocation during garbage collection phase" like #1162.
I'll post a new issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment