> @Zixing, thank you for the patch, could you give some explanation about your understanding of the issue and how is the patch addressing the problem?
I could not reproduce the issue because I encountered another problem (unable to launch `debconf-communicate`) while reproducing the issue described in this bug report. So, instead, I analyzed the re-tracer output: The code tried to access the `error` variable (a NULL address according to the stack trace). Unfortunately, the `status` variable was "<optimized out>", but we can still try to recover its value. There is also an unfortunate design problem with the reporter bot. It does not disassemble the code segment before the program counter (%pc register), so we must disassemble the binary ourselves to hopefully see where the return value went. 0x00007ffff7f72292 <+242>: mov -0x438(%rbp),%rdx 0x00007ffff7f72299 <+249>: lea -0x440(%rbp),%rcx 0x00007ffff7f722a0 <+256>: call 0x7ffff7f64ad0 <g_io_channel_write_chars@plt> [0]0x00007ffff7f722a5 <+261>: cmp $0x1,%eax [1]0x00007ffff7f722a8 <+264>: jne 0x7ffff7f72300 <pk_client_helper_copy_stdout_cb+352> 0x00007ffff7f722aa <+266>: mov -0x440(%rbp),%r8 0x00007ffff7f722b1 <+273>: mov -0x438(%rbp),%rcx 0x00007ffff7f722b8 <+280>: cmp %rcx,%r8 0x00007ffff7f722bb <+283>: je 0x7ffff7f722e0 <pk_client_helper_copy_stdout_cb+320> 0x00007ffff7f722bd <+285>: lea 0x2aa0c(%rip),%rdx # 0x7ffff7f9ccd0 0x00007ffff7f722c4 <+292>: mov $0x10,%esi 0x00007ffff7f722c9 <+297>: mov %r14,%rdi 0x00007ffff7f722cc <+300>: xor %eax,%eax 0x00007ffff7f722ce <+302>: call 0x7ffff7f65570 <g_log@plt> 0x00007ffff7f722d3 <+307>: xor %ebx,%ebx 0x00007ffff7f722d5 <+309>: jmp 0x7ffff7f72228 <pk_client_helper_copy_stdout_cb+136> 0x00007ffff7f722da <+314>: nopw 0x0(%rax,%rax,1) 0x00007ffff7f722e0 <+320>: mov %r8,%rcx 0x00007ffff7f722e3 <+323>: lea 0x27ceb(%rip),%rdx # 0x7ffff7f99fd5 0x00007ffff7f722ea <+330>: mov %r14,%rdi 0x00007ffff7f722ed <+333>: xor %eax,%eax 0x00007ffff7f722ef <+335>: mov $0x80,%esi 0x00007ffff7f722f4 <+340>: call 0x7ffff7f65570 <g_log@plt> 0x00007ffff7f722f9 <+345>: jmp 0x7ffff7f72223 <pk_client_helper_copy_stdout_cb+131> 0x00007ffff7f722fe <+350>: xchg %ax,%ax [2]0x00007ffff7f72300 <+352>: mov -0x448(%rbp),%rax 0x00007ffff7f72307 <+359>: lea 0x27ca9(%rip),%rdx # 0x7ffff7f99fb7 0x00007ffff7f7230e <+366>: mov %r14,%rdi 0x00007ffff7f72311 <+369>: xor %ebx,%ebx 0x00007ffff7f72313 <+371>: mov $0x10,%esi => 0x00007ffff7f72318 <+376>: mov 0x8(%rax),%rcx 0x00007ffff7f7231c <+380>: xor %eax,%eax The comparison with G_IO_STATUS_NORMAL (with an integer value of `1`) is made in location [0]; we can be sure that the conditional jump at [1] did not happen, so the control flow must go straight down. The load that happened in [2] has overwritten our return value, so, indeed, we can't see it. However, we can still make an educated guess about what happened after the I/O write operation. You can look at https://docs.gtk.org/glib/enum.IOStatus.html; apparently, "EOF" and "AGAIN" are not handled in this case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2081604 Title: pk-debconf-helper crashed with SIGSEGV in pk_client_helper_copy_stdout_cb() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/2081604/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
