Bug 2166714

Would it be possible to collect a backtrace that includes C source line numbers? That, along with the media file that triggers the crash would help diagnose this.

Please see https://fedoraproject.org/wiki/StackTraces.

It also might be worth running dmapd from outside systemd, for example with "dmapd -f ..."

I did it via GDB:
https://fedoraproject.org/wiki/StackTraces#Obtaining_a_stack_trace_using_just_GDB
not sure if this helps enought:

Thread 2 (Thread 0x7ffff24f2640 (LWP 808677) "typefind:sink"):
#0  0x00007ffff7b0b27d in syscall () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff7e619d0 in g_cond_wait_until () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff7de0f11 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff7e3dd5a in g_thread_pool_thread_proxy.lto_priv () from /lib64/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff7e3b302 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff7a8cdcd in start_thread () from /lib64/libc.so.6
No symbol table info available.
#6  0x00007ffff7b12630 in clone3 () from /lib64/libc.so.6
No symbol table info available.

Thread 1 (Thread 0x7ffff6065d80 (LWP 808674) "dmapd"):
#0  0x00007ffff32e31f7 in _build_db_starting_at (builder=0x5555556e56a0, dir=dir@entry=0x5555556a3f70 "/mnt/d/audio/Prod", container_record=container_record@entry=0x5555556e56e0, error=error@entry=0x7fffffffe318) at /usr/src/debug/dmapd-0.0.91-1.fc36.x86_64/src/db-
builder-gdir.c:381
        path = 0x55555561ead0 "0\374qUUU"
        d = 0x5555556ecfb0
        ok = 0
        entry = <optimized out>
        __func__ = "_build_db_starting_at"
#1  0x00007ffff32e32ef in _handle_path (builder=0x5555556e56a0, path=path@entry=0x5555556a3f70 "/mnt/d/audio/Prod", container_record=container_record@entry=0x0, error=error@entry=0x7fffffffe318) at /usr/src/debug/dmapd-0.0.91-1.fc36.x86_64/src/db-builder-gdir.c:180
        record = 0x5555556e56e0
        ok = 0
        filename = 0x5555556eaf60 "Prod"
#2  0x00007ffff32e3182 in _build_db_starting_at (builder=0x5555556e56a0, dir=0x5555555ff3c0 "/mnt/d/audio", container_record=0x0, error=0x7fffffffe318) at /usr/src/debug/dmapd-0.0.91-1.fc36.x86_64/src/db-builder-gdir.c:373
        path = 0x5555556a3f70 "/mnt/d/audio/Prod"
        d = 0x5555555ffcf0
        ok = 1
        entry = <optimized out>
        __func__ = "_build_db_starting_at"
#3  0x0000555555559442 in _serve (protocol=protocol@entry=DAAP, factory=<optimized out>, share_def=share_def@entry=0x5555555ff4f0, error=error@entry=0x7fffffffe318) at /usr/src/debug/dmapd-0.0.91-1.fc36.x86_64/src/dmapd.c:464
        i = 0
        db = 0x5555556e5660
        rc = <optimized out>
        ok = <optimized out>
        share = 0x0
        container_db = 0x5555556cc2a0
        db_protocol_dir = 0x5555555d2810 "/var/cache/dmapd/Edna Audio/DAAP"
        __func__ = "_serve"
#4  0x00005555555587a7 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/dmapd-0.0.91-1.fc36.x86_64/src/dmapd.c:901
        factory = <optimized out>
        share_def = 0x5555555ff4f0
        list = 0x55555557ac50
        exitval = 0
        error = 0x0
        context = 0x55555557de00
        av_meta_reader = <optimized out>
        photo_meta_reader = 0x5555555a6010
        workers = {dacp_share = 0x0, av_render = 0x555555585b70}
Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled off'.

I am also not sure why this file should trigger this crash - it looks to me this is for some reason a very first file that is indexed. I'd like to point out, there is running a selinux that is sometimes causig a strange things, but I disabled it however the crash still occurs.

Created attachment 1941976 [details]
file that may crash the dmapd

Your segfault seems to occur as a result of line 381 in db-builder-gdir.c. This seems to mean that ok is FALSE, but that the pointer error holds NULL. I cannot find a way to cause this to happen. From what I see, all instances where ok is FALSE also result in setting error. Unfortunately, the media file you provided loads fine here.

I tried corrupting the file and also setting its permissions so that I could not read it. Neither triggered the segfault here.

Obviously, I am missing something.

If you are able to operate GDB or recompile with print statements, I recommend you poke around _handle_path, _build_db_starting_at, dmapd_db_lookup_id_by_location, dmapd_db_add_path, and dmapd_db_record_factory_create to see what returns ok == FALSE without setting error.

I just found a problem.

Are you using the "acceptable formats" feature ("dmapd -M ..." or "Acceptable-Formats")? If so, then dmapd will segfault due to the circumstances described above.

If able, please compile and test Git master after cloning with:

git clone https://www.flyn.org/git/dmapd

You can run ./autogen.sh to create the necessary Makefiles.

Otherwise, try avoiding the "acceptable formats" feature, and see if that makes the problem go away.

I will publish a new version of the package if your tests demonstrate that the problem is fixed.

Yes I am using

Acceptable-Formats=mp3;flac;ogg

Acually this machine is not intended to build, I tried to install several required devel things but ended up with that

checking for DMAPSHARING... no
configure: error: libdmapsharing not found.  Install libdmapsharing

even thou
Package libdmapsharing-devel-2.9.41-6.fc36.x86_64 is already installed.

Does the segfault go away if you avoid using "Acceptable-Formats" with the current dmapd package? That would be nearly as strong evidence that what I changed will fix your problem.

Yes, the segfault does not happen when acceptable formats is removed from the config.

FEDORA-2023-56a0a07091 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-56a0a07091

FEDORA-2023-0bcd61a0a7 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0bcd61a0a7

FEDORA-2023-9eb828d84f has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9eb828d84f

FEDORA-2023-56a0a07091 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-56a0a07091

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-0bcd61a0a7 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0bcd61a0a7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0bcd61a0a7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-9eb828d84f has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9eb828d84f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9eb828d84f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-56a0a07091 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-9eb828d84f has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-0bcd61a0a7 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.