You are here: Home » Topic » 1528 – segmentation fault when ‘plugin_dir’ incorrectly set

1528 – segmentation fault when ‘plugin_dir’ incorrectly set

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Nightlies Feedback 1528 – segmentation fault when ‘plugin_dir’ incorrectly set

This topic contains 3 replies, has 2 voices, and was last updated by  aeon_flux 10 years, 3 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #1291

    skellert
    Participant

    I haven’t upgraded to the latest nightly for maybe 12 months…. I compiled and installed 1528 today and was greeted with a segmentation fault when I ran it.

    The problem was that my /etc/mt-daapd.conf included the following line:

    plugin_dir = /usr/lib

    I recall encountering a problem way back with this, and I think I fixed it by explicitly providing the path to each library file. In any case, the problem went away when I made plugin_dir point to /usr/lib/mt-daapd – which is where the new library files were anyway.

    I’m guessing that mt-daapd is trying to load *every* file in the configured library directory – ie hundreds of them when my conf file was broken and pointing to the wrong plugin_dir.

    Yes – I know the segmentation fault was because of my configuration error. Probably even stupid configuration errors should get flagged with something more meaningful than a segmentation fault! šŸ˜‰

    I haven’t gone looking at the source code so I’m not sure of the best way to fix it. Do you assume a max / static number of library files? (… and if so, is there a test you can add to see whether the directory contains more than this number of loadable modules?)

    Stefan

    #10111

    rpedde
    Participant

    @skellert wrote:

    I haven’t upgraded to the latest nightly for maybe 12 months…. I compiled and installed 1528 today and was greeted with a segmentation fault when I ran it.

    The problem was that my /etc/mt-daapd.conf included the following line:

    plugin_dir = /usr/lib

    I recall encountering a problem way back with this, and I think I fixed it by explicitly providing the path to each library file. In any case, the problem went away when I made plugin_dir point to /usr/lib/mt-daapd – which is where the new library files were anyway.

    I’m guessing that mt-daapd is trying to load *every* file in the configured library directory – ie hundreds of them when my conf file was broken and pointing to the wrong plugin_dir.

    Yes – I know the segmentation fault was because of my configuration error. Probably even stupid configuration errors should get flagged with something more meaningful than a segmentation fault! šŸ˜‰

    I haven’t gone looking at the source code so I’m not sure of the best way to fix it. Do you assume a max / static number of library files? (… and if so, is there a test you can add to see whether the directory contains more than this number of loadable modules?)

    Stefan

    No, I just walk through and see if they export the symbols I expect. What platform is this? Seems like I tried to replicate it once before and couldn’t, so I’m wondering if it’s platform dependant, or if there is some library you have that exports a function called “plugin_info”, which is what I’m checking for. Maybe I need to export some magic number or something to verify that it’s really a mt-daapd plugin.

    — Ron

    #10112

    skellert
    Participant

    Ron, I’ve experienced the problem both on FC5 and FC6. (My development system is FC6, the stable fileserver is FC5).

    I shall send you a directory listing of the offending directory.

    Stefan

    #10113

    aeon_flux

    I had the same problem on Fedora 7 (installed with mt-daapd-0.2.4-2.fc6.mf.i386.rpm)
    Could not find what the problem was, at first I thought that the filenames or files where corrupt. and giving the error “Segmentation fault”

    The strange thing was that it wasn’t hanging on the same file.

    As a test I removed the file /var/cache/mt-daapd/songs.gdb and run mt-daapd -d9 -f again… It is still running…

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.