Description of problem:

I've seen abrt-applet 2.14.2-1.fc33 segmentation fault when booting the Fedora Rawhide KDE Plasma spin live image KDE-Live-x86_64-Rawhide-20200513.n.0.iso.
The abrt-applet crash appeared to happen when NetworkManager was starting an ethernet connection. The crash was shown in coredumpctl and the journal. The segmentation fault might've been due to an invalid pointer pp=0x30 in g_steal_pointer based on the coredumpctl gdb output. The command was /usr/bin/abrt-applet --gapplication-service , and it was run automatically during boot. I can give the gdb output after I reboot as the core file is now inaccessible due to other crashes. abrt-applet had the same crash when I selected Sleep from the Application menu, but the core files were truncated or unavailable.

I ran valgrind --log-file=valgrind-abrt-applet-2.txt /usr/bin/abrt-applet --gapplication-service & I selected Sleep from the Application menu.
The valgrind report showed an invalid read and segmentation fault in g_steal_pointer at gmem.h:206 at an address 0x30 which wasn't in the mapped region of the process.

==16480== Memcheck, a memory error detector
==16480== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16480== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==16480== Command: /usr/bin/abrt-applet --gapplication-service
==16480== Parent PID: 14720
==16480== 
--16480-- WARNING: unhandled amd64-linux syscall: 315
--16480-- You may be able to write your own handler.
--16480-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--16480-- Nevertheless we consider this a bug.  Please report
--16480-- it at http://valgrind.org/support/bug_reports.html.
==16480== Invalid read of size 8
==16480==    at 0x10EF9B: g_steal_pointer (gmem.h:206)
==16480==    by 0x10EF9B: process_deferred_queue (abrt-applet-application.c:87)
==16480==    by 0x4B7B47A: g_idle_dispatch (gmain.c:5755)
==16480==    by 0x4B7F7AE: g_main_dispatch (gmain.c:3309)
==16480==    by 0x4B7F7AE: g_main_context_dispatch (gmain.c:3974)
==16480==    by 0x4B7FB37: g_main_context_iterate.constprop.0 (gmain.c:4047)
==16480==    by 0x4B7FC02: g_main_context_iteration (gmain.c:4108)
==16480==    by 0x49D374C: g_application_run (gapplication.c:2559)
==16480==    by 0x10D45C: main (abrt-applet-main.c:24)
==16480==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==16480== 
==16480== 
==16480== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==16480==  Access not within mapped region at address 0x30
==16480==    at 0x10EF9B: g_steal_pointer (gmem.h:206)
==16480==    by 0x10EF9B: process_deferred_queue (abrt-applet-application.c:87)
==16480==    by 0x4B7B47A: g_idle_dispatch (gmain.c:5755)
==16480==    by 0x4B7F7AE: g_main_dispatch (gmain.c:3309)
==16480==    by 0x4B7F7AE: g_main_context_dispatch (gmain.c:3974)
==16480==    by 0x4B7FB37: g_main_context_iterate.constprop.0 (gmain.c:4047)
==16480==    by 0x4B7FC02: g_main_context_iteration (gmain.c:4108)
==16480==    by 0x49D374C: g_application_run (gapplication.c:2559)
==16480==    by 0x10D45C: main (abrt-applet-main.c:24)
==16480==  If you believe this happened as a result of a stack
==16480==  overflow in your program's main thread (unlikely but
==16480==  possible), you can try to increase the size of the
==16480==  main thread stack using the --main-stacksize= flag.
==16480==  The main thread stack size used in this run was 8388608.
==16480== 
==16480== HEAP SUMMARY:
==16480==     in use at exit: 371,277 bytes in 5,996 blocks
==16480==   total heap usage: 165,320 allocs, 159,324 frees, 14,618,743 bytes allocated
==16480== 
==16480== LEAK SUMMARY:
==16480==    definitely lost: 95 bytes in 2 blocks
==16480==    indirectly lost: 0 bytes in 0 blocks
==16480==      possibly lost: 3,960 bytes in 28 blocks
==16480==    still reachable: 340,794 bytes in 5,759 blocks
==16480==                       of which reachable via heuristic:
==16480==                         length64           : 2,160 bytes in 42 blocks
==16480==                         newarray           : 1,904 bytes in 39 blocks
==16480==         suppressed: 20 bytes in 1 blocks
==16480== Rerun with --leak-check=full to see details of leaked memory
==16480== 
==16480== For lists of detected and suppressed errors, rerun with: -s
==16480== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


Version-Release number of selected component (if applicable):
abrt-gui-2.14.2-1.fc33.x86_64
glib2-2.64.2-2.fc33.x86_64

How reproducible:
I've seen these abrt-applet crashes most of the time when booting or putting the system to sleep with abrt-gui-2.14.2-1.fc33.x86_64.

Steps to Reproduce:
1. boot the Fedora Rawhide KDE Plasma spin live image KDE-Live-x86_64-Rawhide-20200513.n.0.iso downloaded from https://koji.fedoraproject.org/koji/buildinfo?buildID=1506671 A network connection might be needed for the crash to occur
2. If the abrt-applet crash isn't shown in coredumpctl, select the Application menu > Leave / Power > Sleep
3.

Actual results:
abrt-applet 2.14.2-1.fc33 segmentation faulted in g_steal_pointer

Expected results:
No crashes would happen.

Additional info:
These abrt-applet crashes didn't appear with abrt-2.14.1-1.fc33 or earlier.