Activity log for bug #1689344

Date Who What changed Old value New value Message
2017-05-08 16:22:51 Brian Murray bug added bug
2017-05-08 16:24:35 Brian Murray bug task added gdb (Ubuntu)
2017-05-08 18:21:24 Launchpad Janitor branch linked lp:~ubuntu-core-dev/ubuntu/artful/apport/ubuntu
2017-05-08 22:00:48 Launchpad Janitor apport (Ubuntu): status New Fix Released
2017-05-09 21:06:31 Brian Murray affects gdb (Ubuntu) glib2.0 (Ubuntu)
2017-05-11 00:54:12 Brian Murray nominated for series Ubuntu Yakkety
2017-05-11 00:54:12 Brian Murray bug task added glib2.0 (Ubuntu Yakkety)
2017-05-11 00:54:12 Brian Murray bug task added apport (Ubuntu Yakkety)
2017-05-11 00:54:43 Brian Murray nominated for series Ubuntu Zesty
2017-05-11 00:54:43 Brian Murray bug task added glib2.0 (Ubuntu Zesty)
2017-05-11 00:54:43 Brian Murray bug task added apport (Ubuntu Zesty)
2017-05-11 01:20:46 Brian Murray apport (Ubuntu Yakkety): status New In Progress
2017-05-11 01:20:49 Brian Murray apport (Ubuntu Yakkety): assignee Brian Murray (brian-murray)
2017-05-11 01:20:54 Brian Murray apport (Ubuntu Zesty): status New In Progress
2017-05-11 01:21:00 Brian Murray apport (Ubuntu Zesty): assignee Brian Murray (brian-murray)
2017-05-12 16:56:11 Brian Murray description apport's test test_add_gdb_info_abort_glib has been failing for a bit, since zesty(?), now. Digging into this matter I discovered that using gdb to "print __glib_assert_msg" is resulting in different behavior. With the generated binary, it used to return the following: $2 = 0x7fadc0 "ERROR:<stdin>:2:main: assertion failed (1 < 0): (1 < 0)" However, now I am seeing: (gdb) print __glib_assert_msg $1 = 1332592064 (gdb) print (char*) __glib_assert_msg $2 = 0x4f6dbdc0 <error: Cannot access memory at address 0x4f6dbdc0> This seems to be a regression in gdb itself, I've added an apport task though to track the disabling of the autopkgtest which utilizes this command. [Impact] apport's test, test_add_gdb_info_abort_glib is failing due to a change somewhere in glib2.0, how its built, or gdb. The test shall be disabled while the matter is investigated. [Test Case] Run the autopkgtest and observe the failure. With the version of the package in proposed the test will not be run. [Regression Potential] We are just disabling a broken test so there is none. apport's test test_add_gdb_info_abort_glib has been failing for a bit, since zesty(?), now. Digging into this matter I discovered that using gdb to "print __glib_assert_msg" is resulting in different behavior. With the generated binary, it used to return the following: $2 = 0x7fadc0 "ERROR:<stdin>:2:main: assertion failed (1 < 0): (1 < 0)" However, now I am seeing: (gdb) print __glib_assert_msg $1 = 1332592064 (gdb) print (char*) __glib_assert_msg $2 = 0x4f6dbdc0 <error: Cannot access memory at address 0x4f6dbdc0> This seems to be a regression in gdb itself, I've added an apport task though to track the disabling of the autopkgtest which utilizes this command.
2017-05-12 17:48:58 Łukasz Zemczak apport (Ubuntu Zesty): status In Progress Fix Committed
2017-05-12 17:49:00 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2017-05-12 17:49:04 Łukasz Zemczak bug added subscriber SRU Verification
2017-05-12 17:49:06 Łukasz Zemczak tags verification-needed
2017-05-12 18:01:55 Łukasz Zemczak apport (Ubuntu Yakkety): status In Progress Fix Committed
2017-05-15 22:09:35 Brian Murray tags verification-needed verification-done
2017-05-22 15:31:39 Launchpad Janitor apport (Ubuntu Zesty): status Fix Committed Fix Released
2017-05-22 15:31:49 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2017-05-22 15:42:15 Launchpad Janitor apport (Ubuntu Yakkety): status Fix Committed Fix Released
2020-04-08 13:20:47 nassim glib2.0 (Ubuntu): assignee nassim (moujane)
2020-04-08 19:17:22 Sebastien Bacher glib2.0 (Ubuntu): assignee nassim (moujane)