Bug 2157980

Summary: abrt refuse to report backtrace involving invalid function pointer
Product: [Fedora] Fedora Reporter: Yann Droneaud <yann>
Component: libreportAssignee: abrt <abrt-devel-list>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: abrt-devel-list, abrt-sig, mgrabovs, michal.toman
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
coredump (zstd compressed)
none
backtrace none

Description Yann Droneaud 2023-01-03 19:54:11 UTC
Created attachment 1935546 [details]
coredump (zstd compressed)

While diagnosing a crash in dleyna-renderer

    $ abrt-cli report .......
    <...>
    ('report_uReport' completed successfully)
    Generating backtrace
    Backtrace is generated and saved, 36514 bytes
    Backtrace parsing failed for .
   15:0: Function call in the frame header misses mandatory "at file.c:xy" section
    Looking for similar problems in bugzilla
    Reporting is disabled because the generated backtrace has low informational value.

Generated backtrace shows NULL pointer was used

    $ cat backtrace
    : No such file or directory.
    [New LWP 138679]
    [New LWP 138685]
    [New LWP 138681]
    [New LWP 138708]
    [New LWP 138684]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".
    Core was generated by `/usr/libexec/dleyna-renderer-service'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x0000000000000000 in ?? ()
    [Current thread is 1 (Thread 0x7f35748e4840 (LWP 138679))]

    Thread 1 (Thread 0x7f35748e4840 (LWP 138679)):
    #0  0x0000000000000000 in  ()
    #1  0x00007f35757e5a8a in g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=0x5623f12aa000, hash_table=0x5623f12cd810<error reading variable: Cannot access memory at address 0x4>) at ../glib/ghash.c:474
            node_hash = <optimized out>
            hash_value = <optimized out>
            have_tombstone = 0
            step = 0
            node_index = <optimized out>
            first_tombstone = 0
            node_hash = <optimized out>
            __func__ = "g_hash_table_lookup"
    #2  g_hash_table_lookup (hash_table=0x5623f12cd810<error reading variable: Cannot access memory at address 0x4>, key=key@entry=0x5623f12aa000) at ../glib/ghash.c:1540
            node_hash = <optimized out>
            __func__ = "g_hash_table_lookup"
    #3  0x00007f35758fbb3f in prv_server_available_cb (cp=<optimized out>, proxy=proxy@entry=0x5623f129ba20 [GUPnPDeviceProxy], user_data=0x5623f12a8c60) at ../libdleyna/renderer/upnp.c:174
            upnp = 0x5623f12a8c60
            udn = 0x5623f12aa000 "uuid:6b58de40-d510-373e-12a6-7da4a8e9514b"
            device = <optimized out>
            ip_address = 0x5623f12ca540 "192.168.0.151"
            context = <optimized out>
            queue_id = <optimized out>
            i = <optimized out>
            priv_t = 0x7f35640197e0
    <...>

Through the debugger it's obvious it's the result of a call through a NULL function pointer

    $ coredumpctl debug ......
    <...>
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".
    Core was generated by `/usr/libexec/dleyna-renderer-service'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x0000000000000000 in ?? ()
    [Current thread is 1 (Thread 0x7f35748e4840 (LWP 138679))]
    (gdb) bt
    #0  0x0000000000000000 in  ()
    #1  0x00007f35757e5a8a in g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=0x5623f12aa000, hash_table=0x5623f12cd810<error reading variable: Cannot access memory at address 0x4>) at ../glib/ghash.c:474
    #2  g_hash_table_lookup (hash_table=0x5623f12cd810<error reading variable: Cannot access memory at address 0x4>, key=key@entry=0x5623f12aa000) at ../glib/ghash.c:1540
    <...>
    (gdb) frame 1
    #1  0x00007f35757e5a8a in g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=0x5623f12aa000, hash_table=0x5623f12cd810<error reading variable: Cannot access memory at address 0x4>) at ../glib/ghash.c:474
    474	  hash_value = hash_table->hash_func (key);


I think the backtrace has information value and should be reported by abrt.

Comment 1 Yann Droneaud 2023-01-03 19:55:34 UTC
Created attachment 1935547 [details]
backtrace

Comment 2 Ben Cotton 2023-02-07 15:04:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 3 Fedora Release Engineering 2023-08-16 07:06:28 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.